Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 8 FirstFirst 12345 ... LastLast
Results 21 to 30 of 73
  1. #21
    Junior Member
    Join Date
    Feb 2014
    Posts
    17
    Hi,

    no reboot, only set a low bitrate radio i.e. 128 Bkit/s CBR on a preset, switch to that radio station and
    the squeezeplay audio.decode thread of the radio continues, until it happens again,.. at least that is my experience here,

    the radio is slow and also always tight on memory, my interpretation of the error in the log posted above simply is,
    that the audio.decode thread wanted to commit a number of pcm audio samples of a high bitrate stream with an
    alsa direct access mmap function call, but get's an error and than a fifo overrun occurs,

    if you switch than to a low bitrate radio you can see in the logs that the audio decode thread reinits the decode_start_handler:279 init decoder mp3
    and continues,..

    best wishes pbg4

  2. #22
    Senior Member agbagb's Avatar
    Join Date
    Aug 2006
    Posts
    367
    Quote Originally Posted by pbg4 View Post
    Hi,

    no reboot, only set a low bitrate radio i.e. 128 Bkit/s CBR on a preset, switch to that radio station and
    the squeezeplay audio.decode thread of the radio continues, until it happens again,.. at least that is my experience here,

    the radio is slow and also always tight on memory, my interpretation of the error in the log posted above simply is,
    that the audio.decode thread wanted to commit a number of pcm audio samples of a high bitrate stream with an
    alsa direct access mmap function call, but get's an error and than a fifo overrun occurs,

    if you switch than to a low bitrate radio you can see in the logs that the audio decode thread reinits the decode_start_handler:279 init decoder mp3
    and continues,..

    best wishes pbg4
    So it's at least possible that an occasional power-cycle may avert the problem ever occurring.... With a bit-rate switch being an easy way of fixing it if and when it does occur. I'm guessing that a lot of Radios are very, very rarely power-cycled at all. Almost the only time I use the power button on the radio itself is if I'm going away on a long trip and am doing a general power-down. I sometimes - but not often - use the power button on the remote or on LMS / OrangeSqueeze: but maybe that doesn't do a full reboot in the way that the physical button on the radio does.

    Anyway, thanks to all. When it happened - first ever time - I sort-of-assumed that something terminal had happened to a rather old piece of kit.
    AGB

    Logitech Media Server Version: 7.9.1 - 1522157629 @ Fri Mar 30 12:17:59 WEDT 2018
    Operating system: Windows 10
    Music Library: external SD, exFAT (FLAC music; mp3 voice)

    USA:
    LinkSys WRT54GS Router, WPA2
    1 x Touch, LAN (Firmware:7.7.3-r16676)
    Controller: 7.7.2-r9663

    France:
    Sagem Livebox 2FR, or Freebox
    3 x Touch, 2 wireless, 1 LAN. (Firmware:7.8.0-r16754)
    Controller: 7.7.1-r9557
    3 x SB Radios [2 wireless, 1 usually LAN]: 7.7.3-r16676

  3. #23
    Senior Member
    Join Date
    Feb 2011
    Location
    Cheshire, UK
    Posts
    4,102
    Quote Originally Posted by pbg4 View Post
    Hi,

    no reboot, only set a low bitrate radio i.e. 128 Bkit/s CBR on a preset, switch to that radio station and
    the squeezeplay audio.decode thread of the radio continues, until it happens again,.. at least that is my experience here,

    the radio is slow and also always tight on memory, my interpretation of the error in the log posted above simply is,
    that the audio.decode thread wanted to commit a number of pcm audio samples of a high bitrate stream with an
    alsa direct access mmap function call, but get's an error and than a fifo overrun occurs,

    if you switch than to a low bitrate radio you can see in the logs that the audio decode thread reinits the decode_start_handler:279 init decoder mp3
    and continues,..

    best wishes pbg4
    Thanks.
    What I was considering was setting a button to play a predefined playlist that contains a single very short 20 seconds or so low bitrate file of silence and then the radio station I actually want. (Now wondering if you can add a radio station to a playlist. Only one way to find out.)
    VB2.4 storage QNAP TS419p (NFS)
    Living Room - Joggler & SB3 -> Onkyo TS606 -> Celestion F20s
    Office - Pi3+Sreen -> Sony TAFE320 -> Celestion F10s / Pi2+DAC & SB3 -> Onkyo CRN755 -> Wharfedale Modus Cubes
    Dining Room -> SB Boom
    Kitchen -> UE Radio (upgraded to SB Radio)
    Bedroom (Bedside) - Pi2+DAC ->ToppingTP21 ->AKG Headphones
    Bedroom (TV) - SB Touch ->Sherwood AVR ->Mordaunt Short M10s
    Everything controlled by iPeng

  4. #24
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    399
    Quote Originally Posted by agbagb View Post
    Oh, that's interesting. And easy enough to do (not least as a few of my favorite BBC presets come in alternative formats, so I can just make sure I have some at one rate and some at the other: makes very little actual difference on the ear). Any idea on how that works, from both angles? How does the chip lose its bearings, and how does a rate-switch fix it?
    I don't know how/when the chip loses its bearings, if that's what's afoot. It would require some detailed output logging, for possibly several weeks, until the next time the problem is encountered. With no guarantee that the log will show anything useful. In my case, probably several weeks/months. So I haven't tried.

    Changing the sample rate generates something of a chip reset/re-program, in jive-alsa, to cater for the new sample rate, and seems to be enough to restore normal operation. It's been some long while since I looked at the code.

    Last time I looked was in connection with a Joggler (remember those?), whose on-board chip had a habit of failing after some hours of continuous playback. I was lucky enough to find an old reference on tinternet to some kind of overflow within said chip. Turned out to be easily detectable in jive-alsa once one knew what to look for (I don't recall that logging helped). Chip reset/re-program cured that. I seem to recall getting a corrective patch taken up in one of the Joggler jive-alsa distributions. But doesn't help this problem !

  5. #25
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    399
    Quote Originally Posted by agbagb View Post
    With a bit-rate switch being an easy way of fixing it if and when it does occur.
    Sample rate switch is my finding. Bit rate switch does not imply change of sample rate. Many "low bit rate" & "high bit rate" streams just use 44,100 sample rate.
    From memory, Jive-alsa is getting the decoded stream.

  6. #26
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,220
    Quote Originally Posted by mrw View Post
    I don't know how/when the chip loses its bearings, if that's what's afoot. It would require some detailed output logging, for possibly several weeks, until the next time the problem is encountered. With no guarantee that the log will show anything useful. In my case, probably several weeks/months. So I haven't tried.

    Changing the sample rate generates something of a chip reset/re-program, in jive-alsa, to cater for the new sample rate, and seems to be enough to restore normal operation. It's been some long while since I looked at the code.

    Last time I looked was in connection with a Joggler (remember those?), whose on-board chip had a habit of failing after some hours of continuous playback. I was lucky enough to find an old reference on tinternet to some kind of overflow within said chip. Turned out to be easily detectable in jive-alsa once one knew what to look for (I don't recall that logging helped). Chip reset/re-program cured that. I seem to recall getting a corrective patch taken up in one of the Joggler jive-alsa distributions. But doesn't help this problem !
    Here is the joggler squeezeplay patch that contains the fix for no audio after 5 hours of playback.
    It's actually a change in how jive-alsa handles/recovers from buggy alsa drivers, it's not specfic to the STAC9202 in the joggler. Hmmm.
    Ralphy

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

  7. #27
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    399
    Quote Originally Posted by ralphy View Post
    Here is the joggler squeezeplay patch that contains the fix for no audio after 5 hours of playback.
    It's actually a change in how jive-alsa handles/recovers from buggy alsa drivers, it's not specfic to the STAC9202 in the joggler. Hmmm.
    Well, that's my patch. (The bit that relates to decode_alsa_backend.c).

    I found my original patch, attached. There are a few additional notes in it, suggesting that it was not an overflow in the chip (as I seem to have mis-remembered) but in the alsa driver. I don't know how specific the alsa driver is to the chipset, and I have no record of the original source that put me on track.

    Note that only one channel disappears in our Radio, not both.

  8. #28
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,220
    I managed to create a squeezeos/poky build VM, something I've been wanting to do for a long time, for another project I had in mind. Turns out it was a lot easier than I thought.

    I've applied your patch and rebuilt jive_alsa for the radio and have been using it for the last two days without issue. Yesterday, I played a flac stream for nearly 9 hours before I needed to use the Radio for it's real purpose. I've never had the Bass amp problem on my Radio but it's a UE Radio and there have been several hardware revisions of the Radio, so perhaps not all are affected. We really don't know if the change will help but at least we can try to track it down. Perhaps updating jive_alsa to close the device after being idle for a time, like the -C option in squeezelite may be enough to avoid the problem.

    I created a Patch Installer package for the updated jive_alsa program, but the file is locked while squeezeplay is running and there's no way that I've found to run scripts as part of the patch. If you kill the jive_alsa process the watchdog timer kicks in reboots the Radio, so it will need to be an applet install like edo which I will do if we manage to track down the Bass amp issue.

    So for now, you'll have to ssh into the Radio and download, install the update manually. Ideally, you shouldn't be playing anything on the Radio while doing the update. The reboot at the end restarts the radio immediately so you'll loose your connection.
    Code:
    ssh -l root radio
    
    cd /usr
    
    wget http://ralph-irving.users.sourceforge.net/extensions/RadioJiveAlsa-1.0.tgz
    
    # backup the original, don't use copy as the file is in use.
    mv bin/jive_alsa bin/jive_alsa.bak
    
    tar xzf RadioJiveAlsa-1.0.tgz
    
    rm RadioJiveAlsa-1.0.tgz
    
    reboot

    Now that I can rebuild bits or the entire firmware, minus the private logitech parts I'm also able to run squeezelite on the radio...but that's off topic.
    Ralphy

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

  9. #29
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    399
    Quote Originally Posted by ralphy View Post
    I managed to create a squeezeos/poky build VM, something I've been wanting to do for a long time, for another project I had in mind. Turns out it was a lot easier than I thought.

    <snip>

    Now that I can rebuild bits or the entire firmware, minus the private logitech parts I'm also able to run squeezelite on the radio...but that's off topic.
    Well done ! In the fullness of time I'd be interested to browse any notes/do's/don'ts that you have prepared.

    Do you know if the private parts include the Alsa crossover component ? It seems to be installed here: /usr/lib/alsa-lib/libasound_module_pcm_babydsp.so. I couldn't locate an obvious source file.
    (Above edited: not a kernel module, as previously speculated).

    Edit: Answered my own question. Yes, it is private, as indicated by: https://github.com/Logitech/squeezeo...dsp-src_svn.bb

    I ask because I assume that this is the piece of the alsa playback chain that divides a (presumably mono by now) stream into bass & treble speaker components, and it's only the base that disappears. Just a wild speculation, really.

    Note to self: next time the problem occurs (if it does), plug a headphone in (which turns off the crossover) and see if anything can be discerned. Fortunately/unfortunately I don't seem to be meeting the problem any more.
    Last edited by mrw; 2018-11-18 at 12:14. Reason: Crossover component is private

  10. #30
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,220
    I see you discovered that the dsp bits are private.

    The biggest issue is that the Ubuntu 10.4.04 ssl libraries are dated and many sites no longer allow connections with the known unsecure ssl protocols. I used the i386 iso to create the VM.

    I had to rename the fakeroot_1.9.4.bb to fakeroot_1.9.5.bb and update the source url, change the source url in qemu_0.9.1.bb to a valid location and download libpng-1.2.43.tar.bz2 into the poky/sources folder because SF doesn't allow the old ssl protocols, before bitbake squeezeos-image ran to completion.

    I updated poky/build/conf/local.conf so bitbake uses all 4 cpus during the build/make process.

    BB_NUMBER_THREADS = "4"
    PARALLEL_MAKE = "-j 4"

    Then build the image.

    bitbake squeezeos-image

    Afterware, rebuilding just decode_alsa_backend.c is a bit special.

    Change the code once you find it!

    Code:
    /home/ralphy/source/squeezeos/poky/build/tmp-jive/work/armv5te-none-linux-gnueabi/squeezeplay-7.8+svnr0+49f41e48311ade3a4a879b4b27283036363724b5-r24/squeezeplay/src/audio/decode
    Recompile just the changes.

    bitbake -f -c compile squeezeplay

    Rebuild the image

    bitbake squeezeos-image

    Grab the file from the image at

    Code:
    /home/ralphy/source/squeezeos/poky/build/tmp-jive/rootfs/usr/bin
    Ralphy

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •