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

[mailing lists]

Alexander, thank you very much for the detailed explanation.

> 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.

but (I suppose) that the default|alternative rates declared in etc/pulse/daemon.conf are contrasted with the rates detected from alsa devices and the common ones considered for use. When I played with this two variables on the laptop, the frecuencies were rounded to the nearest frecuency supported by the usb sound card, this did not happen when I changed the values on the raspberry, and we talk of the same sound card. It doesn't matter what I put is was always "Device front:1 doesn't support 44100 Hz, changed to 48000 Hz". it sounds like PA did a fallback to a "safe" sample rate.

Here is the verbose (-vvv) output:

http://pastebin.com/wfgxATEq

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

the configuration files used were:

user at rpi ~ $ grep '^[^#]' pulseaudio/etc/pulse/default.pa 
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-alsa-card device_id=0 
load-module module-native-protocol-unix
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;10.20.30.0/24
load-module module-zeroconf-publish
load-module module-rtp-recv
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-always-sink
load-module module-intended-roles
load-module module-suspend-on-idle timeout=10
.ifexists module-console-kit.so
load-module module-console-kit
.endif
.ifexists module-systemd-login.so
load-module module-systemd-login
.endif
load-module module-switch-on-port-available

user at rpi ~ $ grep '^[^;#]' pulseaudio/etc/pulse/daemon.conf 
high-priority = yes
nice-level = -11
realtime-scheduling = yes
realtime-priority = 5
default-sample-rate = 44100


> 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.

interesting.

> 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.

I wonder if raspbian people had this in mind. I will look into this, for now I prefer avoid resampling, the raspberry is running as a jukebox to attempt  modernize my (very) old amplifier.