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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
