Home of the Squeezebox™ & Transporter® network music players.
Page 8 of 13 FirstFirst ... 678910 ... LastLast
Results 71 to 80 of 128
  1. #71
    Senior Member
    Join Date
    Jul 2006
    Location
    St Albans, United Kingdom
    Posts
    238
    So glad I found this thread!

    I bought a second-hand Radio off fleaBay last week to add to our home's collection of Boxen, and after setting it up the bass and mid-ranged dropped out after only about two minutes listening (it was just after switching from playing BBC Radio 2 to BBC 6 Music). Was all ready to fire off the disappointed message to the seller assuming they'd sold me a duffer, but then rebooted it and it's worked fine now for the last 24 hours. I was going to wait and see, assuming that it was hardware about to fail permanently, but now I know it's likely to be this same software issue, and that there's an Applet that will provide an easy workaround, I can be confident that it's going to be fine and I can keep the unit!

    Thanks guys!

  2. #72
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    753
    Quote Originally Posted by rickwookie View Post
    So glad I found this thread!
    The alternative to rebooting, should it strike again, is to switch to another stream (or music in your library) which broadcasts at a different sample rate[1]. So, if I get the issue (usually BBC, 48,000 samples/sec), I switch to Classic FM (44,100 samples/sec, at least at present), and normal service is resumed. I have Classic FM set up as a preset on the Radio.

    The current fix (Applet) has not been 100% for me, but does seem to have reduced the incidence. Another way of reducing the incidence would be to turn off the Radio's sound effects (i.e. the little beeps you get when pressing a button). I haven't tested that myself, but there's good evidence to support the suggestion.

    [1] Not easy to determine. LMS does not, in general, divulge this.

  3. #73
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    753

    Poky build

    Quote Originally Posted by ralphy View Post
    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 finally found some time for this, thank you for the encouragement to proceed, and the tips. I knew less than nothing of 'poky' the day before yesterday, now just nothing.

    But I have generated an 'almost bit perfect' build of jive_alsa. Meaning that I have recreated that which is shipped in the standard firmware (7.7.3 r16676), except for four differing checksum bytes in the (unused) .gnu_debuglink section of the binary. That is of no consequence.

    So I have confidence that I am using the build system sufficiently properly, and can experiment with a few possible patches.

    I've used Amazon EC2 to spin up a Ubuntu Lucid Lynx (10.04) instance, just the one core, so it takes about four hours once the sources are downloaded. I've not bothered with qemu.

    I had one or two trials/tribulations/puzzles on the way, partly ssl related, partly of my own making, and with a good sprinkling of ignorance thrown in. The somewhat dated SqueezeOS build instructions were very helpful. ( http://wiki.slimdevices.com/index.ph...d_Instructions ).

    I find that the sourceforge mirror sites are very inconsistent, some will accept the 'older' ssl connections, some won't, that so it can be a matter of pure luck as to whether a particular download succeeds.

  4. #74
    Junior Member
    Join Date
    Dec 2019
    Posts
    2
    Hi.

    My first post so apologies if I've missed something, not provided something, etc. Relatively non-technical too....

    I installed the applet and all seemed to be okay , but I recently tried to play an mp3 audio track with a sample rate of 22050Hz and it just refused to play with a buffer size of 30ms. In fact it crashed the player which became unresponsive and eventually rebooted.

    Track plays without the applet installed, with the applet installed and set to 20ms (default) and also when set to 40ms.

    Am I okay to just stick with 40ms, i.e. is it any worse than 30ms? Are there any downsides to 40ms compared to 30ms?

    The hardware is a squeezebox UE radio. Sounds effects are turned on.

    If I use audacity to make the track 44100Hz then all is well.

    Finally a big thank you for providing the applet and Merry Christmas all.

  5. #75
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    753
    Quote Originally Posted by pzyvbv View Post
    Hi.

    I installed the applet and all seemed to be okay , but I recently tried to play an mp3 audio track with a sample rate of 22050Hz and it just refused to play with a buffer size of 30ms. In fact it crashed the player which became unresponsive and eventually rebooted.

    Track plays without the applet installed, with the applet installed and set to 20ms (default) and also when set to 40ms.

    Am I okay to just stick with 40ms, i.e. is it any worse than 30ms? Are there any downsides to 40ms compared to 30ms?

    The hardware is a squeezebox UE radio. Sounds effects are turned on.
    Thank you for the feedback.

    I can think of no obvious reason forwhy a 30ms buffer size would create the difficulty with the 22050Hz MP3 track. But I haven't actually tried that combination, and may do so in due course. As far as I could see, the 'UE radio' playback system differs in no material respect to the 'Baby', which I have used for testing.

    I'm not aware of any issues with using 40ms, or any downsides to doing that. But I haven't used that setting extensively, so I can only suggest that you try it out. It occurred to me that it might lead to synchronization deficiencies between players, but I'm not sure.

    Since my last post, in July, I have carried out some further testing and trials.

    I am now of the view that the problem probably lies somewhere within the kernel audio drivers, and not within Squeezeplay's Crossover component, as I had first surmised.

    The immediate cause of the effect is somewhat mundane, and I don't know why I hadn't noticed it before. Basically the 'Tweeter/Left' and 'Woofer/Right' channels are simply being switched around. So the tweeter is fed with sound intended for the woofer, and vice versa. The effect can be easily discerned when listening to a heavily panned stereo track through headphones. (The Crossover is inactive in that circumstance).

    I have tried installing some later alsa libraries in the hope that there may be an issue therein. But to no good effect. There was no obvious reason to think that there would be, but it was worth trying.

    I can see that a (lightly) patched version of jive_alsa would also help mitigate matters further when a stream is just being started up. It has been on those occasions that I am conscious of experiencing the issue. But it is too rare an occurrence to be sure.

    Merry Christmas !

  6. #76
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    753
    Quote Originally Posted by pzyvbv View Post
    I installed the applet and all seemed to be okay , but I recently tried to play an mp3 audio track with a sample rate of 22050Hz and it just refused to play with a buffer size of 30ms. In fact it crashed the player which became unresponsive and eventually rebooted.

    Track plays without the applet installed, with the applet installed and set to 20ms (default) and also when set to 40ms.
    I have replicated your findings both with an mp3 and a flac file at 22050Hz. The problem seems to be that the alsa sub-system chokes on this particular combination, and fails to initialize. In consequence, jive_alsa fails and terminates. The watchdog notices that after a while, and reboots the machine. I've appended a relevant trace from squeezeplay's log below.

    I am a little surprised, as the buffer size of 30ms was the default used in the firmware prior to product launch, and before a "Real Time" linux was adopted. So one might have expected the issue to have been spotted during initial testing.

    My initial guess as to the underlying issue is that there may be an integer/rounding issue lurking within the alsa library. It would take some further investigation to establish that for certain.

    Reasoning:

    At a sample rate of 44,100, a 20ms buffer comprises, in total, 882 samples. 30ms comprises 1,323 samples, 40ms comprises 1,764 samples.
    At a sample rate of 22,050, a 20ms buffer comprises, in total, 441 samples. 30ms comprises 661.5 samples, 40ms comprises 882 samples.

    Note the fractional part. I would expect the alsa library to round down the buffer sizes to some suitably close integer. But it seems to have given up instead !
    Of course, the problem may be more intricate than my guess.

    Code:
    Jan 15 14:55:12 squeezeplay: INFO   audio.decode - decode_start_handler:279 init decoder flc
    Jan 15 14:55:12 squeezeplay: INFO   audio.decode - Playback.lua:476 connect 192.168.1.182:9000 GET /stream.mp3?player=00:04:20:29:a4:29 HTTP/1.0^M
    Jan 15 14:55:15 squeezeplay: _pcm_open:646 Unable to set  buffer time Invalid argument
    Jan 15 14:55:15 squeezeplay: pcm_close:536 snd_pcm_drain error: Input/output error
    Jan 15 14:55:15 squeezeplay: _pcm_open:646 Unable to set  buffer time Invalid argument
    Jan 15 14:55:15 squeezeplay: audio_thread_execute:830 Playback open failed: Invalid argument
    I'll have to see if there is some other reasonable combination that can work for all sample rates encountered, in place of 30ms.

  7. #77
    Junior Member
    Join Date
    Dec 2019
    Posts
    2
    Thanks mrw. That makes a lot of sense and explains why 40 works fine.

    I've been using 40ms since my last post and so far have had no problems.

    It is surprising the fractional part gives a problem. I'll have a look through my library and see what other sample rates I have to see if i can find one divisible by say 20 and 30 but not 40...

    I'll let you know if i find anything.

    Thanks for looking into this.

  8. #78
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    753
    Quote Originally Posted by mrw View Post
    I'll have to see if there is some other reasonable combination that can work for all sample rates encountered, in place of 30ms.
    Well, there is. For 30ms we can use 29991 instead of 30000. And for 50ms we can use 49990 instead of 50000.

    I have tested these with all sample rates known to me: 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000. The Radio doesn't handle sample rates greater than 48000. If I have missed any others, please let me know.

    ALSA configures itself identically when using these revised values, except that now it manages the 22050 sample rate streams as well. So there should be no downside to this change.

    But I'll be running these revised settings on my own Radios for a few weeks, to confirm that something else doesn't unexpectedly emerge. All being well, I shall issue an update to the Applet.

    Curiously, the Squeezebox Controller, which defaults to a buffer size of 30000, does manage to play out the 22050 sample rate stream. But I think it has different audio hardware, and it does appear to use an earlier kernel version of ALSA (1.0.14 vs 1.0.16, as reported by cat /proc/asound/version). User space alsa-lib is at version 1.0.18 on both devices.

    It seems likely to me that the problem probably lies somewhere within ALSA's "Automatic rate conversion plugin" ('plug' type plugin), which would be called into action on the Radio when presented with any stream not at either 44100 or 48000. The answer might be found by a combination of scrutinizing the source code and delving into some numerology. I don't think I shall be embarking on the search.

  9. #79
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,790
    Quote Originally Posted by mrw View Post
    I finally found some time for this, thank you for the encouragement to proceed, and the tips. I knew less than nothing of 'poky' the day before yesterday, now just nothing.

    But I have generated an 'almost bit perfect' build of jive_alsa. Meaning that I have recreated that which is shipped in the standard firmware (7.7.3 r16676), except for four differing checksum bytes in the (unused) .gnu_debuglink section of the binary. That is of no consequence.

    So I have confidence that I am using the build system sufficiently properly, and can experiment with a few possible patches.

    I've used Amazon EC2 to spin up a Ubuntu Lucid Lynx (10.04) instance, just the one core, so it takes about four hours once the sources are downloaded. I've not bothered with qemu.

    I had one or two trials/tribulations/puzzles on the way, partly ssl related, partly of my own making, and with a good sprinkling of ignorance thrown in. The somewhat dated SqueezeOS build instructions were very helpful. ( http://wiki.slimdevices.com/index.ph...d_Instructions ).

    I find that the sourceforge mirror sites are very inconsistent, some will accept the 'older' ssl connections, some won't, that so it can be a matter of pure luck as to whether a particular download succeeds.
    I've managed to build the radio firmware using a workaround for the private babydsp sources with these steps.

    Keep in mind that the squeezeplay in this firmware does not support the aac and wma decoders or the old spotify applet, as those are part of the private sources as well.

    Now I need to decide if I'm brave enough to load it on my radio! Perhaps a qemu test run first.
    Ralphy

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

  10. #80
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    753
    Quote Originally Posted by ralphy View Post
    I've managed to build the radio firmware using a workaround for the private babydsp sources with these steps.

    Keep in mind that the squeezeplay in this firmware does not support the aac and wma decoders or the old spotify applet, as those are part of the private sources as well.

    Now I need to decide if I'm brave enough to load it on my radio! Perhaps a qemu test run first.
    Thanks. I did something similar, I think. The whole exercise is packed up in an Amazon EBS snapshot, so I can't look right now.

    I recall that jive_alsa was "bit perfect" (subject to 4 debug hash bytes of no significance), and that libasound.so.2.0.0 was bit perfect (I was trying out a few later versions). I did have to define the original build directory, somewhere in the poky conf file, I think, to get the build tree the same - it is certainly baked into jive_alsa. Makes binary comparison somewhat easier.

    I never bothered to try out Squeezeplay itself, but my guess is that it is as bit perfect as it can be ! I haven't looked at capability reporting, that might need a tweak.

    I learned to defang the watchdog (comment out the check for squeezeplay in watchdog.conf), make sure that remote log in is set to on, and, when all is apparently lost, remove the battery to get a clean boot and restore original firmware.

    At present I am running a couple of tweaked jive_alsa's, one with a delayed start to allow buffers to fill at the start of a stream, and one with a replacement of XRUN errors by silence. This in the context of ameliorating XRUNS. Both seem to work fine.


    But, and here's the thing, I don't seem to be getting XRUNS any more ! I recently retried the earlier tests that we both ran last year, but seemed to get no errors. I'll try it again, in case I goofed. But perhaps some change in LMS has helped.
    EDIT: I goofed. I continue to get the same errors at much the same rate as in the earlier, February 2019, tests.


    It will be interesting to see how you get on. I note that you have an alternative aac decoder in your Squeezeplay builds.
    Last edited by mrw; 2020-02-07 at 03:30. Reason: Correction - Errors continue

Posting Permissions

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