Bug 48109

Summary: [regression] pulseaudio-1.99.2 doesn't like snd-pcsp
Product: PulseAudio Reporter: Alexander E. Patrakov <patrakov>
Component: modulesAssignee: pulseaudio-bugs
Status: RESOLVED FIXED QA Contact: pulseaudio-bugs
Severity: normal    
Priority: medium CC: 1001lists, lennart
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 75721    

Description Alexander E. Patrakov 2012-03-30 23:09:13 UTC 
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.
Comment 1 Tanu Kaskinen 2012-03-31 01:44:57 UTC 
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.
Comment 2 Alexander E. Patrakov 2014-05-09 18:16:20 UTC 
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.
Comment 3 Tanu Kaskinen 2014-05-23 12:43:55 UTC 
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).
Comment 4 Alexander E. Patrakov 2014-05-25 11:04:00 UTC 
Unfortunately, I could not find time to look into this, and will definitely not look until May 31, 2014.
Comment 5 Alexander E. Patrakov 2014-06-02 16:46:43 UTC 
Fixed by http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-June/020767.html

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.