[Announce] Community Firmware for Squeezebox Radio/Touch/Controller and LMS 8

[mrw]

OK. One more thought. I have added a Cron job to reboot my Touch every 2 weeks. Will I need to redo it?

I think not. The cron table is, I think, stored in the ‘etc’ hierarchy, which is left untouched by firmware updates. And I think it takes a factory reset to wipe that.

[P Nelson]

Release 8.0.1_r16907 is now available via the plugin.

See the community firmware plugin changelog for details.

from the change log:

Update Fraunhofer FDK AAC Codec Library v2.0.3 and remove encoder support.

Due to my lack of technical knowledge, I am interpreting the above as it was updated and then removed. Of course, that conclusion does not any make sense. Please add some more information for those less knowledgeable on codecs and encoders. I also did not understand the implications of "Build failure mitigations: (Not included in firmware release)".

Thanks to everyone for the hard work it takes to keep this platform going. It is appreciated!

Paul

[Insomniacx]

Thank you 😃

Updated my 2 Sb radio and my 2 Sb Touch
/Patrik

[ralphy]

from the change log:

Update Fraunhofer FDK AAC Codec Library v2.0.3 and remove encoder support.

Due to my lack of technical knowledge, I am interpreting the above as it was updated and then removed. Of course, that conclusion does not any make sense. Please add some more information for those less knowledgeable on codecs and encoders. I also did not understand the implications of "Build failure mitigations: (Not included in firmware release)".

Thanks to everyone for the hard work it takes to keep this platform going. It is appreciated!

Paul

The encoder support is used to create AAC content and the firmware only decodes AAC streams/files, so it was never used.
Removing it frees a bit of memory which is tight on the controller and radio.

The build failure mitigation details have been removed from the change log. Unless you are building the firmware, it's irrelevant.

[Apesbrain]

Release 8.0.1_r16907 is now available via the plugin.

Thank you! Five SB devices updated this morning.

[garym]

Thanks!

Thanks for the work on this. Updated Radio, Touch, and Controller this morning.

[P Nelson]

Michael and Ralphy, thanks for explaining codec. I hope now get it. The encoding ability (which was never used in the hardware) was removed, but the decoding ACC was retained and updated.

Thanks again!

Paul

[seth_space]

updated three radios successful and the logitech touch.
But now the touch does not wants to switch off anymore,
Any thoughts?

[ralphy]

updated three radios successful and the logitech touch.
But now the touch does not wants to switch off anymore,
Any thoughts?

I've been running the firmware on my touch for a month and have not experienced this issue.

I'd suggest you first perform a factory reset on the touch.

[seth_space]

did a successful reset.
It seems the weather info broke the upgrade..

[Paytheprice]

Nice work. A Touch and four radios updated. On the Radios I had to reinstall the CustomClock in the Applet installer.

[expectingtofly]

I have had a couple of bugs raised on the BBC Sounds Plugin repository relating to audio stuttering : https://github.com/expectingtofly/LM...gin/issues/134

Both reports are using Squeezebox radio's with the community firmware. The BBC Streams are AAC 320kbs@48000, so quite high bitrate.
They have provided server logs to me that shows that there are no issues getting audio data out server side (in fact the opposite is true, with chunked audio data downloading and made available faster than average .). So it appears the problem is in the audio decoding on the radio.

As I have had 2 reports of this problem, I wonder if this has anything to do with the AAC decoding changes in the new version of the firmware?

[mrw]

I have had a couple of bugs raised on the BBC Sounds Plugin repository relating to audio stuttering : https://github.com/expectingtofly/LM...gin/issues/134

Both reports are using Squeezebox radio's with the community firmware. The BBC Streams are AAC 320kbs@48000, so quite high bitrate.
They have provided server logs to me that shows that there are no issues getting audio data out server side (in fact the opposite is true, with chunked audio data downloading and made available faster than average .). So it appears the problem is in the audio decoding on the radio.

As I have had 2 reports of this problem, I wonder if this has anything to do with the AAC decoding changes in the new version of the firmware?

I have two Radios running with the latest community firmware, and am a regular/prolific user of BBC Sounds. I have not noted any instances of audio stuttering on either Radio. But I’ll keep an ear open.

Perhaps worth noting that I do use the ‘native’ playback option, so any issue with the AAC decoding changes ought to show up.

[expectingtofly]

I have two Radios running with the latest community firmware, and am a regular/prolific user of BBC Sounds. I have not noted any instances of audio stuttering on either Radio. But I’ll keep an ear open.

Perhaps worth noting that I do use the ‘native’ playback option, so any issue with the AAC decoding changes ought to show up.

I should also add, I can't reproduce the problem either. I also have 2 radios on the latest firmware. But the 2 bug reports were very similar, including how they are set up server side. I suspect/guess the data is being available to the radios more readily in their setup and for some reason the radio is not finding an opportunity to decode from the input to the output buffer, causing the stuttering. I'll see if they are willing/able to get some debug information from the radio....

[ralphy]

I implemented the AAC decoder for squeezeplay and later the community firmware as Logitech never released the code as they used the closed source fdk-aac library in the official firmware.

I have spent some time investigating this issue but had to setup a local server that streams AAC 320Kbps at 48KHz as unfortunately the high rate BBC streams aren't available outside the UK.

What's happening is the aac decoder can't push enough decoded PCM data to the output buffer at the start of the high rate streams and jive_alsa throws an underrun error.

So far I have been able to mitigate this problem using this patch to Playback.lua on the radio. This change stopped the stuttering about 95% of the time with my test stream.

--- share/jive/jive/audio/Playback.lua.orig     1969-12-31 19:00:00.000000000 -0500
+++ share/jive/jive/audio/Playback.lua  2022-06-20 08:49:07.469506981 -0400
@@ -908,6 +908,11 @@
                        -- Even this may not be enough for files with large comments...
                        self.decodeThreshold = self.threshold

+               elseif self.mode == 'a' then
+                       -- For fdk-aac, we need to let the decoder fill the pcm output
+                       -- buffer, otherwise alsa immediately throws an underrun error.
+                       self.decodeThreshold = 40960
+
                elseif self.threshold > (254 * 1024) and (self.mode == 'f' or self.mode == 'p' or self.mode == 'l') then
                        -- For lossless (high bit-rate) formats, lets try to get a much bigger chunk so that
                        -- any server-side delay in streaming caused by playlist updates, etc., do not cause undue problems.

The BBC Sounds Stream throttling interval works around the problem but might also help find proper fix in the firmware, however the stuttering doesn't happen with the 96Kbps streams.

Any help would be appreciated.