[pulseaudio-discuss] pulseaudio (V5) incorrect rate detection on usb sound card with raspberry

[Alexander E. Patrakov]

28.10.2014 16:39, mailing lists wrote:
> Hello Tanu,
>
>> I'm not sure if you mentioned this already before (sorry for not
>> bothering to check), but is the PA version the same between the
>> machines? If not, then something may have been fixed in PA, but in any
>> case it seems more likely to me that there was some change in the kernel
>> driver or alsa-lib that fixed the issue that makes PulseAudio conclude
>> that the sound card doesn't support 44100 Hz.
>
> raspbian comes with PA 2, but I did compiled PA 5, just to discard this type of problems, you can see the output here and yes both test are with PA 5:
>
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-October/022015.html
>
> I don't think there is a kernel driver or alsa-lib bug because other software like the Music Player Daemon haven't problem using the alsa device with only 10% of cpu usage (mp3 decoding), but with mpd Pulseaudio output or any other program (local or remote) cpu is 100% ... you known music is 44100 and PA detects a 48000 sound card so it needs resampling.
>
> That I don't understand is how PA determines sound card capabilities....

The theory is very simple. It probes at startup whether the configured 
sample rate and the alternate sample rate (both can be seen in 
/etc/pulse/daemon.conf) are supported. If none is supported, PulseAudio 
picks a somewhat-random rate that is supported by the card. The result 
of this step is either one or two rates that are known to be supported.

So, the first step in debugging should be to see whether daemon.conf 
files are identical.

When a new stream appears, PulseAudio attempts to open the sound device 
(sink) and chooses a sample rate. Of course, if either the device or its 
monitor is already used, then the sample rate cannot be changed, end of 
story. If the device is not already open, then PulseAudio tries to make 
sure that the resampler has less work to do. Namely, if both the stream 
and one of the two detected known-supported rates are from the 
"divisible by 11025 Hz" family, this kind of rate is used (i.e. if 44100 
Hz is supported, then a 22050 Hz stream would be resampled to 44100 Hz, 
even if 48000 Hz is also supported). The same rule is then applied to 
the "divisible by 4000 Hz" family of sample rates. If none of the 
family-rules work, the default sample rate is tried. Of course, "tried" 
and "used" is not the same - the device may have its own constraints, 
e.g. require identical rates for capture and playback. In any case, the 
final say in the sample rate choice is with the hardware.

All this logic is properly logged in the "pulseaudio -vvv" output. So it 
would be nice if you provide these logs via some pastebin service.

As for resampling that eats 100% of your CPU, that's a misconfiguration 
(which is unfortunately too common on non-x86 CPUs). First, you should 
build speex with fixed-point support if you are not on x86-family CPU. 
Redundant float <-> fixed conversions, not the actual resampling 
process, is what eats CPU time on non-x86. Then, you should set the 
resampler to speex-fixed-1 (or to speex-fixed-3 just for a benchmark) in 
/etc/pulse/daemon.conf.

As for "why resampling at all" - this may be related to 
module-echo-cancel. Its stream always works at 32 kHz natively, so the 
rules above would select 48 kHz if this is supported by the card. Then, 
if some music appears before module-echo-cancel corks its stream due to 
timeout, it will also get resampled to 48 kHz.

-- 
Alexander E. Patrakov