To reproduce: find a desktop-class machine that still has a PC speaker in addition to a regular sound card, then build and load the snd-pcsp kernel module. Expected results: pulseaudio should be able to use it (and it is indeed useful for event sounds). Actual results: pulseaudio before 1.99 worked, and 1.99.2 doesn't want to use this device at all. Here is the relevant portion of the log: I: [pulseaudio] card.c: Created 3 "alsa_card.platform-pcspkr" I: [pulseaudio] alsa-util.c: cannot disable ALSA period wakeups I: [pulseaudio] alsa-util.c: Device hw:2 doesn't support 44100 Hz, changed to 37286 Hz. I: [pulseaudio] alsa-util.c: ALSA period wakeups were not disabled I: [pulseaudio] alsa-sink.c: Successfully opened device hw:2. I: [pulseaudio] alsa-sink.c: Selected mapping 'Analog Mono' (analog-mono). I: [pulseaudio] alsa-sink.c: Successfully enabled mmap() mode. I: [pulseaudio] alsa-sink.c: Successfully enabled timer-based scheduling mode. E: [pulseaudio] alsa-sink.c: Failed to find any supported sample rates. I: [pulseaudio] module.c: Loaded "module-alsa-card" (index: #7; argument: "device_id="2" name="platform-pcspkr" card_name="alsa_card.platform-pcspkr" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes card_properties="module-udev-detect.discovered=1""). I: [pulseaudio] module-udev-detect.c: Card /devices/platform/pcspkr/sound/card2 (alsa_card.platform-pcspkr) module loaded. I.e. the problem seems to be that the device only supports the weird 37286 Hz sample rate.
We could add 37286 Hz to the list of supported rates, but I think we should try to support any strange rate that the sound card uses. The function that causes this failure is pa_alsa_get_supported_rates(). I wonder why it uses a static list of rates instead of querying the hardware about all the rates it supports. Is there no API for that in alsa? Can some cards support any rate, making the list of supported rates too big? If getting the full list of supported rates from alsa is for some reason not possible or good idea, then I think pa_alsa_get_supported_rates() should, in case the hardware doesn't support any of the "normal" rates, return the abnormal rate that the hardware does support. There shouldn't be any reason to refuse to work on strange hardware.
PulseAudio now accepts such cards, but fails an assertion if one tries to create a monitor source: E: [pulseaudio] source.c: Assertion '(default_rate % 4000 == 0) || (default_rate % 11025 == 0)' failed at .../pulseaudio-5.0/src/pulsecore/source.c:1016, function pa_source_update_rate(). Aborting.
Ok, those assertions are bad. We can't do that assumption about the default sample rate. I believe we can do that assumption about the alternate sample rate with the current code, but it would be better if we didn't have to do that assumption about the alternate sample rate either. Would you like to write a patch that does something sensible in pa_sink/source_update_rate() in case of unusual rates? If not, maybe I'll get around to that later (I'll mark this as a release blocker to increase the chances of that happening).
Unfortunately, I could not find time to look into this, and will definitely not look until May 31, 2014.
Fixed by http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-June/020767.html
Fixed: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=42c814b9f320c5868fac98b4291265ca00e79fde
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.