Unable to replicate with SP r3856 - Windows XP - SqueezeCenter 7.3.3 r34731

Please re-test with that version.

(In reply to comment #1)
> Unable to replicate with SP r3856 - Windows XP - SqueezeCenter 7.3.3 r34731
> 
> Please re-test with that version.
> 

Forget the above, wrong update to the wrong bug
------------------------------------------------

I was able to replicate this issue with SqueezeCenter 7.3.3 r34731 & SqueezePlay r3856

Happens on all Live365 stations

Also, the stations attempt to rebuffer alot

Does not happen on other Internet Radio services

http://media-ice.musicradio.com/ChillMP3low.m3u

live365://http://www.live365.com/play/wumb919fast
These stations (and all live365 stations) have the issues

*** Bug 10891 has been marked as a duplicate of this bug. ***

I found that there are other radio stations that exhibit this problem. One example is KQED which I got to by going to Staff Picks by city San Francisco.

You can also see the problem if you tune the following url via squeezecenter:
http://bayradio.com/ksfo.m3u

This is easily reproduced, play any live365 stream with SqueezePlay.

These are marked as CAT, yet that milestone is over now.  Please re-target accordingly.

Testing with r7146 I get the SP device to reboot (no error log)

Once it has rebooted it will play just fine.

I cannot reproduce this at the moment. All the mentioned streams seem to play just fine.

I should have mentioned: ALSA, Linux x86_64

Updating hours

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.

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.

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()?

Bug 13884 gas been opened to tackle the Baby & Fab4 problem. This bug can revert to being used for its original purpose.

I have this problem with some MP3s in my library using Squeezebox server 7.5.0 and Squeezeplay 7.4r0 on Win XP.

Most of my MP3s are sampled at 44.1kHz. I have some that are sampled at 32kHhz and these play fast - these seems to be predictable behaviour. If I restart playing the track it plays at the right speed. Often, if the 32k track is followed by one sampled at 44.1kHz it plays slowly.

I do not have this problem with the Squeezebox Radio or Classic, as far as I am aware and I am not aware of it being an issue with Softqueeze either

I think this is only a bug in decode_portaudio:

In the callback there is this bit of code:

	reached_start_point = decode_check_start_point();
	if (reached_start_point && decode_audio->track_sample_rate != stream_sample_rate) {
		decode_audio->set_sample_rate = decode_audio->track_sample_rate;
	}

But this doesn't actually change the output stream samplerate, because that would require another call to decode_portaudio_openstream() I believe.  I didn't look at this very long but couldn't work out how to fix it, since you can't call this from within the callback.

Easy steps to reproduce the problem (at least on OSX):

Start a fresh instance of SqueezePlay.
Play this 24kHz station: http://www.opb.org/programs/streams/opb-radio.pls
Hear chipmunks.
Stop.
Restart the stream.
PA samplerate is now correct and stream plays normally.

 == Auto-comment from SVN commit #8813 to the jive repo by agrundman ==
 == http://svn.slimdevices.com/jive?view=revision&revision=8813 ==

Fixed bug 10801, the samplerate changing logic in portaudio was broken

This bug has now been fixed in a released version of the Squeezeplay firmware (SB Touch, SB Radio, and SB Controller).  If you are still seeing this bug, please make certain you are running firmware 9009 or higher, and re-open it.

Thanks!