Announcement

Collapse
No announcement yet.

Community Build Radio Firmware

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Community Build Radio Firmware

    > The Radio's Wifi is something of a closed book to us, because the source
    > code (whatever it may hold) is "PRIVATE" - i.e. it requires access to
    > the private subversion repository to review and build. We have to use a
    > "binary only" poky recipe to populate the firmware image.


    Are you saying that the community firmware uses a "blob", whereas the
    original _might_ have built from the source? I'll have to poke around
    private repositories...
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

    #2
    Community Build Radio Firmware

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

    Originally posted by mrw View Post
    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 View Post
    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 View Post
    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.
    Last edited by ralphy; 2020-02-13, 16:21.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

    Comment


      #3
      Originally posted by ralphy View Post
      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 View Post
      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.

      Comment


        #4
        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.
        Ralphy

        1-Touch, 5-Classics, 3-Booms, 2-UE Radio
        Squeezebox client builds donations always appreciated.

        Comment


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

          Git commit:


          Screenshot of github with 7.7 branch in view attached.
          Attached Files

          Comment


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

            1-Touch, 5-Classics, 3-Booms, 2-UE Radio
            Squeezebox client builds donations always appreciated.

            Comment


              #7
              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.
              Last edited by ralphy; 2020-02-16, 17:07. Reason: Added squeezeplay repo url
              Ralphy

              1-Touch, 5-Classics, 3-Booms, 2-UE Radio
              Squeezebox client builds donations always appreciated.

              Comment


                #8
                Originally posted by ralphy View Post
                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 View Post
                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.

                Comment


                  #9
                  Originally posted by mrw View Post
                  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 View Post
                  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?
                  Ralphy

                  1-Touch, 5-Classics, 3-Booms, 2-UE Radio
                  Squeezebox client builds donations always appreciated.

                  Comment


                    #10
                    Originally posted by ralphy View Post
                    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 View Post
                    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 View Post
                    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 View Post
                    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.

                    Comment


                      #11
                      Originally posted by mrw View Post
                      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 View Post
                      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 View Post
                      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 View Post
                      Don't overlook linuxrc. I haven't looked, yet.
                      Thanks. Yes, there's a lot happening in that script.

                      Originally posted by mrw View Post
                      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.
                      Last edited by ralphy; 2020-02-18, 19:08.
                      Ralphy

                      1-Touch, 5-Classics, 3-Booms, 2-UE Radio
                      Squeezebox client builds donations always appreciated.

                      Comment


                        #12
                        Originally posted by ralphy View Post
                        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 ?

                        Comment


                          #13
                          Originally posted by mrw View Post
                          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.

                          Comment


                            #14
                            Originally posted by mrw View Post
                            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 View Post
                            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 View Post
                            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 View Post
                            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

                            1-Touch, 5-Classics, 3-Booms, 2-UE Radio
                            Squeezebox client builds donations always appreciated.

                            Comment


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

                              Code:
                              7.8.0 r16764
                              [email protected] 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.
                              Ralphy

                              1-Touch, 5-Classics, 3-Booms, 2-UE Radio
                              Squeezebox client builds donations always appreciated.

                              Comment

                              Working...
                              X