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

[avr300]

Since I followed your instruction to enable the blue icon every time there has been a short disconnection the icon has been red so it probably isn't critical to have. Did blue mean connected to WiFi/network but not connected to LMS?

Sent from my Pixel 3a using Tapatalk

Yes, blue icon means connected to wifi but no connection to the selected LMS.

It works as expected in Version 8.0.1 r16824

[mherger]

> Yes, the current community firmware 8.0.1r16824 is available at
> https://sourceforge.net/projects/lms...les/squeezeos/.

Did you release a new build recently? A few of my devices offered
another update today.

--

Michael

[ralphy]

> Yes, the current community firmware 8.0.1r16824 is available at
> https://sourceforge.net/projects/lms...les/squeezeos/.

Did you release a new build recently? A few of my devices offered
another update today.

--

Michael

Yes. Martin and I fixed a few issues with the previous release. The changelog lists what's new.

I've only made the new release available for LMS 8.1.1 (nightly) and 8.2.0 (dev).

LMS 8.0.1 and 8.1.0 are still on the older build. I hope to encourage the community to keep their LMS up to date with at least the stable release of LMS.

I can update the older releases as well, if you'd prefer.

[slartibartfast]

Yes, blue icon means connected to wifi but no connection to the selected LMS.

It works as expected in Version 8.0.1 r16824

You just made me realise there was an update

Sent from my Pixel 3a using Tapatalk

[mherger]

> Yes. Martin and I fixed a few issues with the previous release. The
> 'changelog'
> (https://ralph_irving.gitlab.io/lms-c...changelog.html)
> lists what's new.

Oh, ok, cool!

--

Michael

[rfunk]

Ever since upgrading my bedroom Squeezebox Radio to this firmware, my 6am alarm starting an internet radio stream has sounded really bad. It's hard to describe, but it's rough and quiet, almost like maybe it's only playing half of each sample. If I switch to another station it sounds fine; then I switch back to the original one and this time it sounds fine. It also sounds fine if I reboot and manually start the problem station.

I'm running LMS 8.1.0, and the URL I'm trying to play is this: http://playerservices.streamtheworld.com/pls/WCBEFM.pls

[mrw]

Ever since upgrading my bedroom Squeezebox Radio to this firmware, my 6am alarm starting an internet radio stream has sounded really bad. It's hard to describe, but it's rough and quiet, almost like maybe it's only playing half of each sample.

I played out your station last night on one of my Radios (saved as a favourite). While it worked I did note difficulties with connecting.

So I set the station as an alarm both on an "old" firmware and a "new" firmware Radio, to go off this morning.

The "old" firmware was unable to connect, and played out the fall-back alarm track instead. Apparently it only allows 25 seconds before deciding that a station is "bad", and playing out the fall-back alarm.

The "new" firmware did connect, and played out fine for a few minutes. It apparently allows 60 seconds before deciding that a station is bad, so perhaps the extra time allowed it to successfully connect. After a few minutes the remote station must have given up, because the Radio switched to the fall-back alarm. I was not aware of any roughness in the sound quality while it was playing.

So, based on my very limited trial, I would say your radio station is unreliable, at least at present. If it has been consistently unreliable in the past, I would expect you to have been regularly subjected to the "fall-back" alarm, instead of the station. Has that been your experience ?

As regards the roughness of the sound that you heard, it is possible that this is a by-product of the combination of an unreliable stream and a change made to mitigate the effects of "bass drop out". Refer this post for a description: https://forums.slimdevices.com/showt...l=1#post981578

There is a small downside, in that any time that an under-run would have otherwise occurred, we will get a small, audible, click in the playback. I haven't particularly become aware of this in "real use".

It's quite possible that an unreliable server is causing a number of micro "under-runs" in the audio, leading to the effect you describe. I don't know, though, because I haven't personally encountered the issue in a year or so of using the modified firmware.

Perhaps the mitigation should be made a "switchable" option in the next release. My experience suggests that "on" should be the default. I'll give it some thought and, perhaps, make a proposal.

[rfunk]

Thanks for trying it out!

The "old" firmware was unable to connect, and played out the fall-back alarm track instead. Apparently it only allows 25 seconds before deciding that a station is "bad", and playing out the fall-back alarm.
...
So, based on my very limited trial, I would say your radio station is unreliable, at least at present. If it has been consistently unreliable in the past, I would expect you to have been regularly subjected to the "fall-back" alarm, instead of the station. Has that been your experience ?

That's certainly been a common experience for me previously, and I was happy to have that timeout increased, but most of the time it has worked.

As regards the roughness of the sound that you heard, it is possible that this is a by-product of the combination of an unreliable stream and a change made to mitigate the effects of "bass drop out". Refer this post for a description: https://forums.slimdevices.com/showt...l=1#post981578

It's quite possible that an unreliable server is causing a number of micro "under-runs" in the audio, leading to the effect you describe. I don't know, though, because I haven't personally encountered the issue in a year or so of using the modified firmware.

I'm not sure.... I wouldn't describe this as "a small click", but more like dropouts happening at a regular high frequency, happening every day but *only* when starting from the alarm function. (When I say "high frequency" that's to say many times per second as opposed to "occasionally".)

I noticed that this is a 22kHz stream, which at first made me wonder if there's some piece that is trying to play those 22kHz samples on a 44kHz clock, and doesn't have anything to play for every other slot. But of course that would be a 22kHz artifact, and this is more on the order of 10Hz. The buffer under-run problem is interesting, and makes me wonder what would happen with a much bigger buffer. Maybe I should try the Buffer Size applet. I'm also curious about the 22kHz problem that required updating that applet.

[rfunk]

Maybe I should try the Buffer Size applet. I'm also curious about the 22kHz problem that required updating that applet.

Well, I was going to experiment with the buffer size, but first the radio wanted to upgrade to the latest firmware (8.0.1-r16824). So I tested alarms with that, and everything sounded fine. Maybe the new firmware fixed the problem? I'll be interested in seeing what it sounds like Monday morning.

[mrw]

I'm not sure.... I wouldn't describe this as "a small click", but more like dropouts happening at a regular high frequency, happening every day but *only* when starting from the alarm function. (When I say "high frequency" that's to say many times per second as opposed to "occasionally".)

I noticed that this is a 22kHz stream, which at first made me wonder if there's some piece that is trying to play those 22kHz samples on a 44kHz clock, and doesn't have anything to play for every other slot. But of course that would be a 22kHz artifact, and this is more on the order of 10Hz. The buffer under-run problem is interesting, and makes me wonder what would happen with a much bigger buffer. Maybe I should try the Buffer Size applet. I'm also curious about the 22kHz problem that required updating that applet.

If this is the ALSA buffer under-run problem in a different guise, then:

A) you may be the only person in the world who knows what it sounds like, and
B) the Buffer Size Applet may very well help. (Although initial stream start up may still remain "at risk".)

I did notice a couple of tell-tail signs in the "old" firmware log. The "new" firmware will not log anything because there is never an ALSA buffer under-run. Just, perhaps, an audible click in its stead.

I will need to update the Applet's manifest to SqueezePlay version 8 before it will be made available through the Applet installer. (I had cautiously curtailed it to version 7). I'll try and get that done this evening.

The 22Khz sample rate failure was just weird. A thoroughly unexpected issue (read: bug) within the ALSA rate conversion plugin, which meant it rejected a 22kHz stream with a 30ms buffer. I found a simple work-around (specify a buffer of 29.999ms, or thereabouts).

Why only from the Alarm function ? I don't know. Possibly there is a slightly different start up sequence for the stream which makes it more susceptible to delays or problems on start up.

Let me know if increasing the buffer size to 30ms helps.