On 12/03/2012 07:07 AM, Arun Raghavan wrote: > > On Fri, 2012-11-30 at 09:59 +0100, David Henningsson wrote: >> Hi, >> >> I'm researching a bug where some set of USB speakers stopped working, >> probably in 2.x. The peculiar thing about this sound card is that seems >> to only work at a sample rate of 46875 Hz. >> >> So in 2.x, the probe fails with >> "E: [pulseaudio] alsa-sink.c: Failed to find any supported sample >> rates.", whereas in an earlier version, it would just happily work at >> 46875 Hz instead, as I understand it. >> >> So my first question is; why do we check all these rates, when we end up >> just alternating between default-sample-rate (44100 Hz) and >> alternate-sample-rate (48000 Hz) anyway? >> And second, can we try not to fail if we can't find any supported sample >> rates, so we can fix this regression? >> >> For reference, this is the bug (with pulse verbose logs in it): >> >> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1074783 > > This was added by: > > commit e67440e2208fb8182916493b57b75e91013510e7 > Author: Arun Raghavan <arun.raghavan at collabora.co.uk> > Date: Mon Oct 17 22:46:06 2011 +0530 > > alsa: Probe sink/source sample rates > > This probes sink and source sample rates and uses this information to > validate rate changes and check incoming passthrough formats. > > So yes, this is a regression. I'm attaching a patch that should fix > this. Thanks Arun. I have reviewed the patch and think it looks OK. I think we should take it for 3.0. For future releases we could consider other options, such as dropping the check altogether. Especially so if this contributes significantly to PulseAudio's startup time, which I guess shouldn't be ruled out. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
