Thanks. A reasonable interpretation of Lexar vs SanDisk performance is that, as @yknivag suggested, the Lexar’s I/O is causing a bottleneck that, in turn, is throttling the CPU’s performance.
While plausible, it doesn’t explain why the performance characteristics of the same card on the B and B+ differ so much.
I have a workaround: ditch SHOUTcast and create pls/m3u playlists manually and play them:
326 osmc 20 0 583224 175624 53108 S **36.3** 48.5 61:12.55 kodi.bin
I think I’ve worked out what’s going on here. The MP3 stream version of this station has the lower CPU usage, the AAC version is causing the high CPU. I guess I was using one of each without realising. AAC decoding taxing?
Edit: For reference Chilltrax :: the world's chillout channel! MP3 version vs aacPlus 80kbps
Lexar cards are, in my experience, much slower than other brands. I’ve had this cause significant bottlenecks myself at times.
In this case it seems to be the AAC plus stream that is causing the high CPU usage. I’ve tested the same stream on both Pis to confirm
If CPU was high because of IO, you’d see high CPU for jbd2 kworkers
The high CPU was from kodi.bin. @jamieburchell thinks it’s as a result of an AAC encoded stream, though the data rate from Internet radio is very low, so maybe there’s something else going on.
Feel free to test the two streams yourself- the AAC plus stream playback results in ~95% CPU usage, the MP3 stream ~55%. Same on both Pi B and B+.
MP3 Playlist
http://server1.chilltrax.com:9000/listen.pls
AAC Plus Playlist
http://station.chilltrax.com:8000/listen.pls
I don’t doubt your findings but that doesn’t preclude the possibility that something is very inefficient with the AAC decoding. Recall that your Pi 2 was showing 108.9% CPU for an Internet radio station.
Should probably discount the Pi 2 as it has a different setup in terms of addons (including visualisations) and skin. I don’t think I can face butchering that Pi for testing 
Pi 2 kodi.bin
AAC plus stream: 110% CPU, 24.9% RAM
MP3 stream: 37% CPU, 24.7% RAM
Ok, that agrees with the figures in post #1. I’d be interested to know if the AAC decoder is part of Kodi or part of the add-on.
This is without using SHOUTcast at all - I put those Playlists in the userdata/playlists folder and played them directly from there. I think SHOUTcast was a red herring, it just facilitated the playback of the streams. Unfortunatley it doesn’t make clear which stream is which as they are named the same.
Thanks for clarifying. So part of Kodi.
I don’t know much about the AAC codec; I wonder if it’s significant that this is a “HE AAC plus” codec. Perhaps it requires more processing power to decode?
Do you think I should refer to this thread on the Kodi forum @sam_nazarko?
Hi to everyone,
Any news regarding this issue? I’m facing a similar problem with osmc installed on a rpi3. When listening to audio stream kodi.bin rises up to 100% cpu usage (in my case audio coding, mp3 or aac doesn’t matter). That leads to audio gaps and distortions.
Thanks