mrw wrote: > Or perhaps not. > > What is easy to overlook is "how stressed" the Radio seems to be when > decoding aac streams. I've never looked into it in any detail, but an > indication can be obtained by setting the 'audio.decode' logging level > on the Radio to debug. You'll see a line, each second, looking like: > Code: -------------------- > > Jan 7 15:01:52 squeezeplay: INFO audio.decode - Playback.lua:447 0.2%/66.0% -------------------- > > > The first number is the proportion of the stream buffer available to > be filled, i.e. by fetching from the server. The second number is the > proportion of the output buffer occupied by decoded samples waiting to > be played out. > > When playing aac streams, particularly high bit rate streams from the > BBC (R3 aac @ 320k), that first number generally seems to stay in the > 0%->2% range. This is true both with the 'old/stock' firmware and its > 'private' aac decoder, and with the 'new' firmware. SqueezePlay will > not fetch any audio stream data from the server (either LMS or a > remote server) while the decoder is running. > > Compare this with, say, a Touch (I don't have one, so I can't, but > would be interested to see the results), or an MP3 stream. > > I hypothesize that the fact that the stream buffer is being scarcely > filled adversely influences the Radio's resilience to stream > interruption and/or temporary glitches. > *EDIT:* Well, the "low" level of stream buffer fullness also seems to > be true for some MP3 streams as well. So perhaps not that much of an > issue, really. > > It's possible that matters might be improved by increasing the > 'decodeThreshold'. At present it seems to be set at 2,048 bytes, > meaning that the decoder will start as soon as 2,048 bytes are > available. But the stream buffer doesn't really seem have the chance > to fill. It might be worth experimenting to see if increasing it (for > aac streams) to a substantially larger number might help resilience. I > might give that a go at some point.
Yes, that is what I am finding. I have had a look at this today. I can make things better by optimising the BBC sounds operation as much as possible (waiting a bit longer before checking for meta data for the first time), but I can't eliminate the buffer underruns all together. Putting extra stress on the radio (for example when the BBC Sounds tells it that the meta data has updated, especially that the track duration has updated) seems to put it in a position where a buffer underrun is likely. It seems to cause a gap where it stops asking the server for more data (even though there is plenty of data available) triggering the underrun. This doesn't happen when a transcoded flac stream is provided. I do seem to have got to the stage where I can only trigger buffer underruns at the start of a stream though, so its probably only a minor inconvenience to the user. I'll include the changes in the next release. As you say, there may be configurations that can be made to the AAC decoder to make it better also. *BBC Sounds Plugin Wiki* : https://github.com/expectingtofly/LMS_BBC_Sounds_Plugin/wiki ------------------------------------------------------------------------ expectingtofly's Profile: http://forums.slimdevices.com/member.php?userid=63263 View this thread: http://forums.slimdevices.com/showthread.php?t=113479 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
