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

[slartibartfast]

Uptime ?
Meaning, might it have rebooted itself in the interim ? Just a wild thought.

Hmm only 11 hours so it would have rebooted this morning. I noticed the full brightness yesterday though. I will keep an eye on the uptime though to see if it is rebooting more often than the usual 22 day period.

Sent from my Pixel 3a using Tapatalk

[Mark Miksis]

If I recall correctly, the Controller has "on" and "off" states that are not entirely intuitive and not consistent with the behavior of the Touch and Radio. This may or may not be related to what you are seeing.

[sbp]

Problem with AAC from TIDAL on new Community Firmware

Hi Ralphy.

I have an issue with playing AAC from TIDAL using the new firmware on a Squeezebox Radio.
All tracks plays nicely on another Radio with the old firmware.
If I disable AAC in the file format - then the Radio with the new Community Firmware plays without stutter.

See description here: https://forums.slimdevices.com/showt...=1#post1002913

[expectingtofly]

Hi Ralphy.

I have an issue with playing AAC from TIDAL using the new firmware on a Squeezebox Radio.
All tracks plays nicely on another Radio with the old firmware.
If I disable AAC in the file format - then the Radio with the new Community Firmware plays without stutter.

See description here: https://forums.slimdevices.com/showt...=1#post1002913

I meant to raise this a few days ago also, I was going to do a bit of investigation. The new firmware has the same problems with the AAC streams on BBC Sounds. There is kind of a micro stutter and warble when playing AAC streams on the Squeezebox Radio, its as if there is some processing that is going on that is halting streaming.

[ralphy]

Hi Ralphy.

I have an issue with playing AAC from TIDAL using the new firmware on a Squeezebox Radio.
All tracks plays nicely on another Radio with the old firmware.
If I disable AAC in the file format - then the Radio with the new Community Firmware plays without stutter.

See description here: https://forums.slimdevices.com/showt...=1#post1002913

I meant to raise this a few days ago also, I was going to do a bit of investigation. The new firmware has the same problems with the AAC streams on BBC Sounds. There is kind of a micro stutter and warble when playing AAC streams on the Squeezebox Radio, its as if there is some processing that is going on that is halting streaming.

Could be high CPU usage at the start of the stream.

The AAC support in the community firmware is not the same as the Logitech firmware since the source code and decoder are not available.

What does LMS report as the bit rate and sample frequencies of the AAC stream(s) that exhibit this? So I can try to reproduce. I don't have tidal and the non uk bbc sounds streams are low bit rate.

[expectingtofly]

Could be high CPU usage at the start of the stream.

The AAC support in the community firmware is not the same as the Logitech firmware since the source code and decoder are not available.

What does LMS report as the bit rate and sample frequencies of the AAC stream(s) that exhibit this? So I can try to reproduce. I don't have tidal and the non uk bbc sounds streams are low bit rate.

UK BBC sounds stream is 320 kbps 48 khz

[sbp]

AAC is 320k CBR

Here is a log file with stuttering when I started the stream - then I paused the stream after a few seconds.

https://www.dropbox.com/t/AuMG9Zyzn3slIyjs

[mrw]

I meant to raise this a few days ago also, I was going to do a bit of investigation. The new firmware has the same problems with the AAC streams on BBC Sounds. There is kind of a micro stutter and warble when playing AAC streams on the Squeezebox Radio, its as if there is some processing that is going on that is halting streaming.

I've been using this firmware, or a variant, for some little time now and do not recognize the symptoms you describe. One of my Radios is constantly playing BBC AAC streams, either from BBC Sounds or BBC iPlayer, at 320k/48k.

Are you able to provide me with a stream that reliably reproduces the issue ? Or a set of actions, e.g. fast forwarding, that will trigger it ?

I do know that the stream that is being played on the Radio is an AAC stream provided by LMS. That is, I think, because the BBC stream URLs are all https, so LMS must fetch them. Please correct me/advise LMS settings that are needed if I am wrong.

I don't have Tidal, so can't test that.

On the "old firmware" Radio, are there any signs of ALSA underrun messages in the Radio's log ? (/var/log/messages). These are the specific errors that are pertinent:

Jan 27 16:26:45 squeezeplay: audio_thread_execute:862 underrun!!! (at least -2359940.244 ms long)
Jan 27 16:34:56 squeezeplay: audio_thread_execute:1025 xrun (snd_pcm_mmap_commit) err=-32
And sometimes this kernel message:
Jan 27 16:34:56 kernel: [ 3387.946675] ssi1_irq SISR 120 SIER 180100 fifo_errs=1

My reason for asking is that I am wondering if you are observing the "Bass amp problem" in a new guise.

https://forums.slimdevices.com/showthread.php?104141-Bass-amp-problem&p=981578&viewfull=1#post981578

[sbp]

In my TIDAL log file (se download link above) I often see this. Do you think that is the cause of the problems

[21-01-05 14:07:24.5057] Slim::Player::StreamingController::playerOutputUnderrun (2239) 00:04:20:2a:d8:53: decoder: 1552148 / output: 0
[21-01-05 14:07:24.5067] Slim::Player::StreamingController::_eventAction (272) 00:04:20:2a:d8:53: OutputUnderrun in PLAYING-STREAMING -> Slim::Player::StreamingController::_Rebuffer
[21-01-05 14:07:24.5073] Slim::Player::StreamingController::_setPlayingState (2377) new playing state BUFFERING
[21-01-05 14:07:24.5097] Slim::Player::StreamingController::_eventAction (302) 00:04:20:2a:d8:53: OutputUnderrun - new state BUFFERING-STREAMING
[21-01-05 14:07:24.5659] Slim::Player::StreamingController::_eventAction (272) 00:04:20:2a:d8:53: StatusHeartbeat in BUFFERING-STREAMING ->

[expectingtofly]

I've been using this firmware, or a variant, for some little time now and do not recognize the symptoms you describe. One of my Radios is constantly playing BBC AAC streams, either from BBC Sounds or BBC iPlayer, at 320k/48k.

Are you able to provide me with a stream that reliably reproduces the issue ? Or a set of actions, e.g. fast forwarding, that will trigger it ?

I do know that the stream that is being played on the Radio is an AAC stream provided by LMS. That is, I think, because the BBC stream URLs are all https, so LMS must fetch them. Please correct me/advise LMS settings that are needed if I am wrong.

I don't have Tidal, so can't test that.
[/url]

Interestingly, it happens repeatedly and reliably for me for all BBC Sounds streams (yes you are right LMS is fetching them, they are dash streams that are stitched together by the plugin.). There is a lot of stuttering at the start of the stream, and intermittent micro stuttering as the stream is playing, you would have noticed if it was happening for you.

The LMS that my radios are connecting to is on a very low powered raspberry pi model 1b, so I actually wondered if that is the problem. Ie, there quite a lot going on in the sysread of the plugin that is providing the aac stream to for the radios buffer, and I wondered if it was simply not completing the call quickly enough, even though there was plenty in the radios buffer, which had the effect of briefly blocking the community firmware processing, if you see what I mean. Anyway, that was just my speculation.

I'll install the firmware again and get you some logs.

[mrw]

The LMS that my radios are connecting to is on a very low powered raspberry pi model 1b, so I actually wondered if that is the problem.

I'm using a SheevaPlug, also quite low power...

[mrw]

In my TIDAL log file (se download link above) I often see this. Do you think that is the cause of the problems

[21-01-05 14:07:24.5057] Slim::Player::StreamingController::playerOutputUnderrun (2239) 00:04:20:2a:d8:53: decoder: 1552148 / output: 0
[21-01-05 14:07:24.5067] Slim::Player::StreamingController::_eventAction (272) 00:04:20:2a:d8:53: OutputUnderrun in PLAYING-STREAMING -> Slim::Player::StreamingController::_Rebuffer
[21-01-05 14:07:24.5073] Slim::Player::StreamingController::_setPlayingState (2377) new playing state BUFFERING
[21-01-05 14:07:24.5097] Slim::Player::StreamingController::_eventAction (302) 00:04:20:2a:d8:53: OutputUnderrun - new state BUFFERING-STREAMING
[21-01-05 14:07:24.5659] Slim::Player::StreamingController::_eventAction (272) 00:04:20:2a:d8:53: StatusHeartbeat in BUFFERING-STREAMING ->

Possibly. But why a problem with the "new" firmware but not the "old" firmware ?
Is there anything in the Radio's log that would throw any light ?

I notice that the player seems to be synced with something.

[slartibartfast]

I've been using this firmware, or a variant, for some little time now and do not recognize the symptoms you describe. One of my Radios is constantly playing BBC AAC streams, either from BBC Sounds or BBC iPlayer, at 320k/48k.

Are you able to provide me with a stream that reliably reproduces the issue ? Or a set of actions, e.g. fast forwarding, that will trigger it ?

I do know that the stream that is being played on the Radio is an AAC stream provided by LMS. That is, I think, because the BBC stream URLs are all https, so LMS must fetch them. Please correct me/advise LMS settings that are needed if I am wrong.

I don't have Tidal, so can't test that.

On the "old firmware" Radio, are there any signs of ALSA underrun messages in the Radio's log ? (/var/log/messages). These are the specific errors that are pertinent:

Jan 27 16:26:45 squeezeplay: audio_thread_execute:862 underrun!!! (at least -2359940.244 ms long)
Jan 27 16:34:56 squeezeplay: audio_thread_execute:1025 xrun (snd_pcm_mmap_commit) err=-32
And sometimes this kernel message:
Jan 27 16:34:56 kernel: [ 3387.946675] ssi1_irq SISR 120 SIER 180100 fifo_errs=1

My reason for asking is that I am wondering if you are observing the "Bass amp problem" in a new guise.
https://forums.slimdevices.com/showt...l=1#post981578

Didn't you turn off native AAC at some point? I think you said it made the Radio menu more responsive.

Sent from my Pixel 3a using Tapatalk

[mrw]

Didn't you turn off native AAC at some point? I think you said it made the Radio menu more responsive.

Well remembered ! Fortunately I did remember to check the point before commenting...

It does seem to make the menus more responsive, but for some reason, I forget what, I reverted back to "native AAC" quite a while ago. Probably to check the new firmware. So my observation is, indeed, "sound".

Someone very aptly described LMS as "having a lot of moving parts". This kind of attention to detail, and remembering those details, can be critical in diagnosing problems.

[slartibartfast]

Well remembered ! Fortunately I did remember to check the point before commenting...

It does seem to make the menus more responsive, but for some reason, I forget what, I reverted back to "native AAC" quite a while ago. Probably to check the new firmware. So my observation is, indeed, "sound".

Someone very aptly described LMS as "having a lot of moving parts". This kind of attention to detail, and remembering those details, can be critical in diagnosing problems.

I'll try switching mine back to native AAC to test [emoji3]

Sent from my Pixel 3a using Tapatalk