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

[Alexander E. Patrakov]

02.11.2014 18:11, Tanu Kaskinen wrote:
> On Tue, 2014-10-28 at 11:39 +0000, 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....
>>
>> any clue?
>
> If the same PulseAudio version works on a newer kernel but not on an
> older kernel, then that very strongly suggests that something was
> changed in the kernel that made it work. If MPD works also on the older
> kernel, then apparently PulseAudio and MPD do something differently.
> Feel free to compare the source code of MPD and PulseAudio to see if
> PulseAudio does something wrong (I lack the motivation to do that
> myself). The "Device %s doesn't support %u Hz, changed to %u Hz."
> message is printed from src/modules/alsa/alsa-util.c, so that's a good
> place to start.

Tanu, please ignore the "issue". It was caused by a bad edit to 
/usr/share/alsa/alsa.conf.

The bad edit was:

-pcm.front cards.pcm.default
+##pcm.front cards.pcm.front
+pcm.front cards.pcm.default

As a result, the front:0 device was redirected to dmix, which by default 
accepts only 48 kHz.

-- 
Alexander E. Patrakov