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