Community Build Radio Firmware

**ralphy** · 2020-02-13, 14:05

Community Build Radio Firmware

Carrying on the radio firmware build discussion from the Bass Amp Problem thread.

Originally posted by mrw

Will do. But expect patchy responses as I have some family matters to deal with over the next few weeks.
I'll load it onto one of my Radios. Certainly worth checking.

No worries. Thanks.

Originally posted by mrw

I have Squeezeplay 7.8.0 running without ogg/flac (i.e. on the 7.7.3 r16676 binaries) on one of my Radios. Needs a 'hack' to Jive.lua to report itself to LMS as 7.8.0 r_whatever because the version is baked into the jive binary, and one or two (I think) of the 7.7.3 -> 7.8.0 patches need this to work. (Update context-menu styles to use icons for playlist control actions. and Task B0020: Player control over UDP). I'd be surprised if the lua enhancements were the cause of higher cpu usage, but I haven't checked. I'll try and look at that.

I had the same issue as I'd committed my changed to git in the 7.7 branch and it increased the revision number. I used bvi to modified the version strings in the jive binary to match the original firmware version.

I'm still testing the 7.7 aac decoder changes on my one radio, so I haven't explored the possible performance degradation I perceived. But I'd agree that the lua changes do seem unlikely to be the cause. Or that there is really a difference.

Originally posted by mrw

One point: I think it advisable that you merge the 7.7 tree into 7.8 to catch that last "baby only" patch, if you haven't already. (Baby only - ignore firmware older than SR to SB migration firmware (7.7.3 r16667)). I suspect that it is there to prevent a "converted to LMS Smart Radio" from inadvertently downgrading to an earlier firmware that doesn't recognize the Smart Radio hardware (revision 8 ?).

No. I hadn't noticed that that change was missing from the 7.8 branch. I've forked the logitech squeezeos repo and will merge 7.7 and continue all further development on 7.8 as the 7.7 changes are available in the source tarball from a few days ago and were really only to confirm the aac changes were doable.

**mrw** · 2020-02-13, 14:58

Originally posted by ralphy

No worries. Thanks.

I found a moment. In poky/build/conf/local.conf I have:

Code:

+#MACHINE ?= "jive"
+MACHINE ?= "baby"

and

Code:

+#TMPDIR = "${OEROOT}/build/tmp-${MACHINE}"
+TMPDIR = "/opt/parabuild/etc/build/b97620co/a/u/t/o/poky/build/tmp-${MACHINE}"

I cannot remember whether I did that manually, or when using one of the poky/parabuild scripts.

Originally posted by ralphy

I had the same issue as I'd committed my changed to git in the 7.7 branch and it increased the revision number.

My lua script hack to Jive.lua is this:

Code:

-- Fix Squeezeplay version to 7.8.0
_G["jive"].JIVE_VERSION = "7.8.0 r16677"

-- stuff we use
local math          = require("math")
local os            = require("os")
local coroutine     = require("coroutine")
etc

By prepending at this point it seems to execute early enough to influence all lua scripts. I don't think the binary accesses it other than to print a start up message. Perhaps a useful hack to have in the tool box.

**ralphy** · 2020-02-13, 15:15

That's much easier. Thanks for the build path change.

I haven't been able to find the commit for Baby only - ignore firmware older than SR to SB migration firmware (7.7.3 r16667).

Merging 7.7 into 7.8 committed no changes.

**mrw** · 2020-02-13, 16:41

I'm not sure what you're not seeing.

Git commit:

https://github.com/Logitech/squeezeplay/commit/cca1bba4abeb3fef2b7c4a48a4e4da8fc255666d

Screenshot of github with 7.7 branch in view attached.

Attached Files

Screenshot 2020-02-13 at 16.38.22.png (159.2 KB, 7684 views)

**ralphy** · 2020-02-13, 17:01

Because I was looking in the squeezeos repository not squeezeplay. Thanks!

**ralphy** · 2020-02-16, 15:50

Success running a 7.8.0 build on my radio and so far the results have been positive.

To be able to make trackable updates to the various subsystems, I've moved to forks of the logitech repositories. I removed the aac and random album menu patches from the squeezeos squeezeplay recipe and committed them to the logitech squeezeplay fork, where they really belong.

The baby dsp module loads and works with the new firmware. The default buffer should be changed to 30ms (29991) and 3 periods instead of the current default 20/2, based on mrw's findings in the Bass Amp Problem thread.

As an extra safety net, I temporarily re-enabled the telnet daemon so you can connect to the radio using telnet as well and ssh, which is also enabled by default. I have not committed these 2 changes.

Rhapsody (Rhap) is another missing features in the community build verses stock as indicated by the capabilities squeezeplay publishes to LMS at startup. Spotify (spt,spdr,Spdirect=spotify) and Windows Media (wma,wmap,wmal) were previously noted. Ogg/flac (ogf) support has been flawless so far with the Radio Paradise flac stream, which I would expect as support has been in the touch firmware for ages.

Logitech 7.7.3-r16676.

Code:

Model=baby,ModelName=Squeezebox Radio,Firmware=7.7.3-r16676,[B]Rhap[/B],alc,[B]wma,wmap,wmal,[/B]aac,[B]spt,[/B]ogg,flc,aif,pcm,mp3,MaxSampleRate=48000,AccuratePlayPoints,[B]spdr,Spdirect=spotify,[/B]ImmediateCrossfade,test,Rtmp=2,Proxy=192.168.7.231:9001

Community 7.8.0-r16764

Code:

Model=baby,ModelName=Squeezebox Radio,Firmware=7.8.0r16764,alc,[B]aac,[/B]ogg,[B]ogf,[/B]flc,aif,pcm,mp3,MaxSampleRate=48000,AccuratePlayPoints,ImmediateCrossfade,test,Rtmp=2,Proxy=192.168.7.231:9001

Performance of the radio with 7.8 has been on par with the previous 7.7. It's unclear what I was experiencing previously with the 7.8 test jive binary running on a 7.7 firmware.

The openssh library 0.9.8g needs to be updated, but that requires a lot of qemu testing before flashing it to the radio.

The radio does support rolling back one firmware version;

1) Turn Radio off: Press & hold the power button till you see "Goodbye"
2) Turn back on: Press & hold REW and PWR buttons simultaneously.

I have not needed to resort to using it so far, thankfully.

More testing is required before I'd consider making the build available to everyone. I have not tried to downgrade the radio back to the stock firmware yet so I can't confirm it's even possible at the moment. But as long as you only flash the radio once, you should be able to revert to 7.7 using the roll back procedure.

**mrw** · 2020-02-16, 16:41

Originally posted by ralphy

The default buffer should be changed to 30ms (29991) and 3 periods instead of the current default 20/2, based on mrw's findings in the Bass Amp Problem thread.

But, perhaps, only if you need to. I think my 'buffer management' applet would install on this as is, but I'd need to check as I did incorporate some tests to ensure that it was running on a Radio.

Originally posted by ralphy

More testing is required before I'd consider making the build available to everyone. I have not tried to downgrade the radio back to the stock firmware yet so I can't confirm it's even possible at the moment. But as long as you only flash the radio once, you should be able to revert to 7.7 using the roll back procedure.

Looks very promising! It will be a while before I can personally pay much attention because of other commitments at present.

In terms of distribution, in an ideal fully open source world one might consider distributing a 'pukka' firmware package, and I think that is what you are indicating. But is that the world we are in ? I have zero knowledge of the subject, but the thought did occur to me.

Another possibility might be to distribute only the changed components, as a 'patch set', to be applied to the vanilla Logitech 7.7.3-r16676 firmware. I guess one might be following a well trodden path with this approach.

Perhaps with an 'applicator' applet to look after matters, rather than as a simple 'patch applet' patch.
But it's some time off, I suspect.

**ralphy** · 2020-02-17, 15:15

Originally posted by mrw

But, perhaps, only if you need to. I think my 'buffer management' applet would install on this as is, but I'd need to check as I did incorporate some tests to ensure that it was running on a Radio.

Your AlsaBufferSize applet works fine with 7.8. I just updated the ms buffersizes for 30 and 50 for now. I've tested 22050Hz mp3 files which play fine with 29991 ms setting.

It does assert for the SqueezeboxBaby applet at load but it could be installed only with the squeezeplay-baby recipe. The touch with edo already has a similiar applet and the controller audio has other issues that require tweaking thread priority and was never officially supported, only released as a beta feature. I too thought it better to include your applet as part of the firmware update and leave the default values. Perhaps with 2 entries each for 30 and 50 using the exact and "tuned" ms values.

Originally posted by mrw

Looks very promising! It will be a while before I can personally pay much attention because of other commitments at present.

In terms of distribution, in an ideal fully open source world one might consider distributing a 'pukka' firmware package, and I think that is what you are indicating. But is that the world we are in ? I have zero knowledge of the subject, but the thought did occur to me.

Another possibility might be to distribute only the changed components, as a 'patch set', to be applied to the vanilla Logitech 7.7.3-r16676 firmware. I guess one might be following a well trodden path with this approach.

Perhaps with an 'applicator' applet to look after matters, rather than as a simple 'patch applet' patch.
But it's some time off, I suspect.

Yes, the touch enhanced digital output applet installs a new jive_alsa binary, applets and patches on the current firmware, updates the linux kernel too.
However, flashing a new firmware takes about 2 minutes and provided rolling back the firmware to stock is an option, would be an easier approach, depending if there are modified firmware distribution concerns or not.

There are lots of firmware version checks at startup, that I need to better understand.

Code:

Feb 16 09:40:37 squeezeplay: INFO   squeezebox.server - SlimServer.lua:375 Firmware URL: http://192.168.7.22:9000/firmware/baby_7.8.0_r16764.bin
Feb 16 09:40:37 squeezeplay: INFO   squeezebox.server - SlimServer.lua:327 Major: 7 Minor: 8 Patch: 0 Revision: 16764
Feb 16 09:40:37 squeezeplay: INFO   squeezebox.server - SlimServer.lua:382 Firmware version newer than SR to SB migration firmware - ok!
Feb 16 09:40:37 squeezeplay: INFO   squeezebox.server - SlimServer.lua:406 we're up to date - no firmware change
Feb 16 09:40:37 squeezeplay: INFO   squeezebox.server - SlimServer.lua:421 hebe2 firmware=http://192.168.7.22:9000/firmware/baby_7.8.0_r16764.bin force=false
Feb 16 09:40:41 squeezeplay: INFO   squeezebox.server - SlimServer.lua:375 Firmware URL: http://192.168.7.30:9000/firmware/baby_7.8.0_r16764.bin
Feb 16 09:40:41 squeezeplay: INFO   squeezebox.server - SlimServer.lua:327 Major: 7 Minor: 8 Patch: 0 Revision: 16764
Feb 16 09:40:41 squeezeplay: INFO   squeezebox.server - SlimServer.lua:382 Firmware version newer than SR to SB migration firmware - ok!
Feb 16 09:40:41 squeezeplay: INFO   squeezebox.server - SlimServer.lua:406 we're up to date - no firmware change
Feb 16 09:40:41 squeezeplay: INFO   squeezebox.server - SlimServer.lua:421 wandboard firmware=http://192.168.7.30:9000/firmware/baby_7.8.0_r16764.bin force=false
Feb 16 09:40:42 squeezeplay: INFO   squeezebox.server - SlimServer.lua:799 connected mysqueezebox.com
Feb 16 09:40:42 squeezeplay: INFO   squeezebox.server - SlimServer.lua:375 Firmware URL: http://update.slimdevices.com/update/firmware/7.7.3/baby_7.7.3_r16676.bin
Feb 16 09:40:42 squeezeplay: INFO   squeezebox.server - SlimServer.lua:327 Major: 7 Minor: 7 Patch: 3 Revision: 16676
Feb 16 09:40:42 squeezeplay: INFO   squeezebox.server - SlimServer.lua:382 Firmware version newer than SR to SB migration firmware - ok!
Feb 16 09:40:42 squeezeplay: INFO   squeezebox.server - SlimServer.lua:409 we don't downgrade, even if lower versioned firmware is of more recent revision - ignoring
Feb 16 09:40:42 squeezeplay: INFO   squeezebox.server - SlimServer.lua:421 mysqueezebox.com firmware=http://update.slimdevices.com/update/firmware/7.7.3/baby_7.7.3_r16676.bin force=false

I will test this in time but for now I'm back to daily radio use activities to see how it performs and if any issues crop up. My previous firmware flash partition still has a stock firmware image I can hopefully revert to if needed.

How are your jive_alsa modification(s) working so far?

**mrw** · 2020-02-17, 18:17

Originally posted by ralphy

Your AlsaBufferSize applet works fine with 7.8. I just updated the ms buffersizes for 30 and 50 for now. I've tested 22050Hz mp3 files which play fine with 29991 ms setting.

I will be re-issuing it with the "new, tweaked" 30 and 50 buffer sizes. I'll have a look to see if one can prevent "double installation" where it has already been included in a firmware.

For what it's worth, 29,999 and 49,999 also work just fine, pointing to an integer rounding issue at this particular sample rate (22,050). Using 29,991 and 49,990 gives a bit of headroom.

I did some fairly extensive tests of what would work and what wouldn't work. In a nutshell, there are things that are simply adrift either in the (built-in) ALSA rate conversion plugin, and/or its interaction with the kernel driver(s). In principle it should be able to handle *all* conversions, but it most definitely can't ! I would be inclined not to include the "exact" values, my re-issued Applet will simply present them as 30 and 50. (The user really doesn't care). Unless, of course, revised firmware components eliminate the issue.

I can also remark that the "tweaked" values result in an initialization of exactly what it should have been (buffer sizes of precisely 10ms). I don't recommend that you investigate, but in debug mode, and by launching Squeezeplay from the command line, you'll see the ALSA lib's configurarion dumped onto STDOUT, or STDERR, I forget which.

Originally posted by ralphy

depending if there are modified firmware distribution concerns or not.

I was wondering about the status of, for example, the dsp component.

Originally posted by ralphy

There are lots of firmware version checks at startup, that I need to better understand.

LMS presents the existing firmware binary (7.7.3) as a "Forced" update. I discovered that, without the additional changes in 7.8, we would always be presented with an upgrade (to 7.7.3) if the Radio reports itself as 7.8.0. That probably underlies at least some of the changes (and logging traces) that you observed.

Don't overlook linuxrc. I haven't looked, yet.

Originally posted by ralphy

How are your jive_alsa modification(s) working so far?

So far, so good. But I have yet to test the specific Alarm issues that were addressed.

**ralphy** · 2020-02-18, 14:44

Originally posted by mrw

I will be re-issuing it with the "new, tweaked" 30 and 50 buffer sizes. I'll have a look to see if one can prevent "double installation" where it has already been included in a firmware.
For what it's worth, 29,999 and 49,999 also work just fine, pointing to an integer rounding issue at this particular sample rate (22,050). Using 29,991 and 49,990 gives a bit of headroom.

It doesn't make sense to have the applet in the firmware, if it means changes to support both cases. It's easy enough to install if needed. I won't include it unless you agree we should.

Originally posted by mrw

I was wondering about the status of, for example, the dsp component.

If it turns out that the dsp module stops distribution, then perhaps implementing something similiar with the caps and alsa equalizer pairing like we have in piCoreplayer could be an option.

Originally posted by mrw

LMS presents the existing firmware binary (7.7.3) as a "Forced" update. I discovered that, without the additional changes in 7.8, we would always be presented with an upgrade (to 7.7.3) if the Radio reports itself as 7.8.0. That probably underlies at least some of the changes (and logging traces) that you observed.

Provided the newer firmware resides in the cache/updates folder on the local lms server(s) the radio does not prompt to downgrade the firmware on switching between local servers. I haven't tried mysb.com with 7.8 yet.

Originally posted by mrw

Don't overlook linuxrc. I haven't looked, yet.

Thanks. Yes, there's a lot happening in that script.

Originally posted by mrw

So far, so good. But I have yet to test the specific Alarm issues that were addressed.

My radio alarm has worked the last two mornings, so at least what used to work still seems to be okay. I haven't tested the changes yet either.

**mrw** · 2020-02-20, 19:38

Originally posted by ralphy

If it turns out that the dsp module stops distribution, then perhaps implementing something similiar with the caps and alsa equalizer pairing like we have in piCoreplayer could be an option.

Possibly also the MSP firmware.

Random thoughts regarding the Crossover (dsp module):

Provides an ALSA control to switch on and off. This is used by Squeezeplay in the context of headphone jack activity to automatically disengage when headphones are plugged in, and engage (i.e. produce mono tweeter and woofer) when headphones are removed.

Equalization and crossover matched to the drivers and enclosure. Finding the curves ?

Presumably well optimized code implementing equalization/crossover - would the alternatives provide adequate efficiency ?

**mrw** · 2020-02-29, 13:49

Originally posted by mrw

Equalization and crossover matched to the drivers and enclosure. Finding the curves ?

I've found those.

By courtesy of the United States NSA, I used Ghidra nine or ten months ago to see what might be seen in the dsp plugin vis-à-vis the "bass drop out" issue[1]. On the way, I located the various filter co-efficients.

I have now matched these up to the relevant dsp "cook-book" algorithms (http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt) plus one other. Results agree to the penny, or, in two cases, to within a couple of quid[2].

[1] And found nothing that implicated the plugin.
[2] Which, I suspect, may stem from the use of single floats instead of double floats when the firmware was prepared.

**ralphy** · 2020-03-02, 14:03

Originally posted by mrw

Possibly also the MSP firmware.

Agreed. Although the msp430 firmware is available in the logitech squeezeos github repo, the license in the recipe is Confidential.

Originally posted by mrw

Provides an ALSA control to switch on and off. This is used by Squeezeplay in the context of headphone jack activity to automatically disengage when headphones are plugged in, and engage (i.e. produce mono tweeter and woofer) when headphones are removed.

Perhaps providing 2 EQ curves, one for the bass crossover and another "flat" for the headphone jack and switching between them in _setEndpoint would be enough? You can create multiple alsa equals devices with distinct settings. Eventually even an applet to change the headphone curve settings could be implemented.

Originally posted by mrw

Presumably well optimized code implementing equalization/crossover - would the alternatives provide adequate efficiency ?

So far, my only experience has been using alsaequals on a single arm processor with fpu. This would definitely need more research.

Originally posted by mrw

I've found those.
By courtesy of the United States NSA, I used Ghidra nine or ten months ago to see what might be seen in the dsp plugin vis-à-vis the "bass drop out" issue[1]. On the way, I located the various filter co-efficients.

I have now matched these up to the relevant dsp "cook-book" algorithms (http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt) plus one other. Results agree to the penny, or, in two cases, to within a couple of quid[2].

[1] And found nothing that implicated the plugin.
[2] Which, I suspect, may stem from the use of single floats instead of double floats when the firmware was prepared.

Amazing. Knowing that you have the settings, makes researching alsaequals performance on the radio a worthwhile next step.

**ralphy** · 2020-03-02, 14:29

The radio has now been running my 7.8.0 r16764 firmware for nearly 2 weeks without an issue.

Code:

7.8.0 r16764
root@poky Sat Feb 15 11:20:32 EST 2020
Base build revision:  ba2bffadb9f1c1b77eee1b1c08a7985eeb97e14e

09:05:49 up 13 days, 21:24, load average: 0.35, 0.26, 0.19

root       749     1 27 Feb17 ?        3-18:52:26 /usr/bin/jive
root       781   749  7 Feb17 ?        1-00:31:01 jive_alsa -d default -c dac -b 29991 -p 3 -s 16 -f 3

I have tweaked several scripts since then but have been testing those changes in qemu. Unfortunately the SqueezeBaby applet needs to be disabled in qemu for squeezeplay to start and there's no qemu audio device support available in the kernel. So jive_alsa fails to initialize but jive continues to run. Currently exploring options to provide audio for testing.

I'm working on updating ssl and dropbear now that I have a working qemu. I'd like to provide shared ssl libraries instead of the current static link so they could also be leveraged for local https connection support in the future.

Community Build Radio Firmware

Community Build Radio Firmware

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment