Community Build Radio Firmware

[ralphy]

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

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.

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.

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]

No worries. Thanks.

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

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

and

+#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.

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:

-- 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]

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]

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

Git commit:
https://github.com/Logitech/squeezep...e4da8fc255666d

Screenshot of github with 7.7 branch in view attached.

[ralphy]

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

[ralphy]

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.

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

Community 7.8.0-r16764

Model=baby,ModelName=Squeezebox Radio,Firmware=7.8.0r16764,alc,aac,ogg,ogf,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]

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.

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]

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.

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.

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]

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.

depending if there are modified firmware distribution concerns or not.

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

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.

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]

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.

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.

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.

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

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

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.