Bugzilla – Bug 13884
Baby & Fab4 cannot play all sample-rates
Last modified: 2009-10-05 14:27:53 UTC
This is a copy from bug 10801 which was being misused for this problem. Here are the relevant comments from bug 10801. [reply] [-] Comment 12 Alan Young 2009-09-05 00:58:01 PDT Additional hours worked: 13.0 This is proving very hard to isolate. With the current default settings on Fab4 it works for sample rates of 8000, 12000, 16000, 22050, 24000, 32000, 44100, 48000, 88200, 96000 samples/s. Only 11025 out of the standard rates fails, and it fails, rather than sounding wrong. When it fails, the audio thread exits and eventually the watchdog will reboot the player. I tried increasing the buffer time from 20ms to 40ms. This enabled 11025 to play but at least one other rate (44100?) would not play in that cae. I'm looking at understanding the complex set of rules in the ALSA library that leads to this state. If the library is compiled - specifically just pcm_params.c - with RULES_DEBUG defined, then verbose debugging of the rules is emitted on stdout. This can be combined with defining the environment variable LIBASOUND_DEBUG=1 before starting SP. The rules in question are defined in the refine_rules[] array. I tried using various values (null, 1, -1) for the 'dir' parameter of snd_pcm_hw_params_set_period_time_near() without success. I also tried using a call to snd_pcm_hw_params_get_period_time_min() and using it's result to adjust the 'val' parameter calling snd_pcm_hw_params_set_period_time_near(), also without success. I would also note that we use snd_pcm_hw_params_set_rate_near() rather than snd_pcm_hw_params_set_rate() to set the sample rate, although since we set the 'dir' parameter to NULL it may mean the same. Finally, all this probably has nothing to do with the original bug report. All this testing is related to audio using ALSA on Fab4 and Baby. I think that the original report was for desktop-SP on Windows and using Portaudio. [reply] [-] Comment 13 Alan Young 2009-09-05 01:17:28 PDT With the current default settings on Baby it works for sample rates of 8000, 12000, 16000, 22050, 24000, 32000, 44100, 48000samples/s. Only 11025 out of the standard rates fails. The same as Fab4. [reply] [-] Comment 14 Alan Young 2009-09-06 01:34:45 PDT Additional hours worked: 8.0 I think that there is some problem with the recursive rules algorithm in alsa-lib:pcm_params.c. There seem to be certain cases of combinations of input parameters which, on the face of it, should be compatible but are not. The whole rules and decision-making process is complex, recursive, iterative and undocumented. Tracing the output of RULES_DEBUG I see that it has fixed the BUFFER_SIZE just before it tries to fix the PERIOD_TIME but after it has decided on what the PERIOD_TIME will actually be. The problem is that it can be that these two are then incompatible (if the odd cases). I tried setting the buffer-time instead of the period-time in decode_alsa_backend.c and this is looking promising. Richard, is there a particular reason you were using snd_pcm_hw_params_set_period_time_near() instead of snd_pcm_hw_params_set_buffer_time_near()?
Updating hours worked.
Use set_buffer_time instead of set_period_time is clearly not a complete solution as it is sensitive to the buffer_time requested. On Fab4, doubling the buffer_time to 40ms results in some (at least one) sample rate which will not play.
== Auto-comment from SVN commit #7427 to the jive repo by ayoung == == https://svn.slimdevices.com/jive?view=revision&revision=7427 == bug 13884: Baby & Fab4 cannot play all sample-rates Use snd_pcm_hw_params_set_buffer_time_near() instead of snd_pcm_hw_params_set_period_time_near() to facilitate playing all sample rates with a 20ms buffer time. Note: choosing a different buffer-time may result in some sample-rates not playing.
Confirmed that all relevant sample rates also play on Baby with this configuration and software.
Calling this done for now. Bug 13890 open for follow-up improvements.
heh, alan changed from set_buffer_time instead to set_period_time once to make it work. The buffer time has reduced since then, and that must have broken it.
heh, alan i changed from set_buffer_time instead to set_period_time once to make it work. The buffer time has reduced since then, and that must have broken it.
yes, it is very sensitive to the specific combination of parameters and the order in which they are set.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.