While looking at the issue reported in bug 704450, I found that the OGG audio testcase attached to the bug plays with no sound output under Linux. This is under fedora 16 using alsa-lib-1.0.24-2. Also fails under fedora 14 using alsa-lib-1.0.24-1. Mardeg says the file was created using Audacity version 1.3.12-beta. Turning off the quite error handler I get this message: ALSA lib pcm.c:7459:(snd_pcm_set_params) Unable to get period size for PLAYBACK: Invalid argument
It plays for me under Fedora 14 with alsa-lib-1.0.24-1, alsa-plugins-pulseaudio-1.0.24-2 and pulseaudio-0.9.21-7 with onboard Intel sound (snd_hda_intel driver, CX20585 chipset). The sound hardware shouldn't matter, though, as we're asking for software resampling when initializing the PCM. The file is slightly odd in that it's 96kHz, but the software resampling should take care of that if the the hardware doesn't support it. Is your F14 system standard, or has Pulseaudio been disabled? If it's standard, can you please attached the output of |pacmd ls|? It'd also be useful if you could attach a debug log from PulseAudio, which you can get by running: $ echo 'autospawn = no' > ~/.pulse/client.conf $ pulseaudio -k; pulseaudio -vvvvv 2>&1 | tee pa.log Now attempt to play the file in Firefox. Hit Ctrl-C in the terminal to kill PA afterwards. $ rm ~/.pulse/client.conf And then attach pa.log to the bug.
If I disable PA on that F14 system, I can reproduce this. I suspect Fedora's ALSA is not configured to offer resampling when used directly because it assumes PA will take care of that.
Fixing this would require our own resampling, which is something we're going to end up with in the future, but not in the very short term.
Summary: Some OGG audio files play silently under Linux → Media with sample rates incompatible with the hardware can't be played if the OS doesn't provide resampling
The only output after I opened the attachment was the last line which occurred when it should have started playing sound.
(In reply to Matthew Gregan [:kinetik] from comment #2) > If I disable PA on that F14 system, I can reproduce this. I suspect > Fedora's ALSA is not configured to offer resampling when used directly > because it assumes PA will take care of that. Well if this were the issue, this seems to be the only OGG audio file I have found that does not play.
(In reply to Bill Gianopoulos from comment #4) > The only output after I opened the attachment was the last line which > occurred when it should have started playing sound. Thanks for this. It doesn't look like the ALSA PulseAudio plugin is connecting to PA at all, you'd expect to see a lot more output when attempting to play the file, including something like: I: sink-input.c: Created input 0 "ALSA Playback" on alsa_output.pci-0000_00_1b.0.analog-stereo with sample spec s16le 2ch 96000Hz and channel map front-left,front-right I: sink-input.c: media.name = "ALSA Playback" I: sink-input.c: application.name = "ALSA plug-in [firefox]" Is the alsa-plugins-pulseaudio package installed? Do you have an /etc/alsa/pulse-default.conf? Did you still see the snd_pcm_set_params error from the error handler logging during this test? (In reply to Bill Gianopoulos from comment #5) > Well if this were the issue, this seems to be the only OGG audio file I have > found that does not play. Assuming the cause is what I said it is (lack of software resampling), it's possible that most files you've come across are using more common sampling rates that the hardware supports directly.
Well I just figured that out myself. Evidently alsa-plugins-pulseaudio is not installed by default. Installing that fixed the problem.
Oh and with alsa-plugins-pulseaudio installed, I no longer see the snd_pcm_set_params error either.
Okay, that all makes sense now. AIUI, PA doesn't hold the ALSA device open exclusively unless its active, so in your configuration PA was running but not being used due to the missing alsa-plugins-pulseaudio bridge, and the ALSA layer is configured without resampling based on the assumption that PA is in use for ALSA user-level apps.
Well, it would make perfect sense, were it not for the fact that the wiki page for the fedora project to switch to using pulseaudio has a list of packages that were supposed to have been added to the default package install list. Looks like not all of them were.
(In reply to Bill Gianopoulos from comment #0) > ALSA lib pcm.c:7459:(snd_pcm_set_params) Unable to get period size for > PLAYBACK: Invalid argument http://code.google.com/p/chromium-os/issues/detail?id=13231 and http://code.mythtv.org/trac/ticket/8267 are relevant to this. It looks like snd_pcm_set_params can fail in some situations because it may be invalid to fetch hw_params using getters before setting the hw_params with snd_pcm_hw_params. This can cause an error like the above in a situation which could otherwise work if the snd_pcm_sw_params and snd_pcm_hw_params setters were used to configure the PCM directly, rather than relying on the simple snd_pcm_set_params wrapper.
I also noticed this was silent in the lastest mobile Firefox nightly on Android Ice-Cream Sandwich on the Galaxy Nexus which plays other ogg vorbis files fine.
I'm also interested in this, as I explicitly disable all the regular software resampling nonsense on my Linux. Does this BUG also cover the sample format? I'm not aware of any hardware that takes FLOAT32_LE, so I need it converted to some PCM (16/24/32) form as well as a supported sample rate.
Component: Audio/Video → Audio/Video: Playback
The resampler work is complete.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.