#406: Frets on Fire has eye-straining hickups when using PulseAudio
-----------------------+----------------------------------------------------
Reporter: tjyrinki | Owner: lennart
Type: defect | Status: new
Priority: normal | Milestone:
Component: daemon | Severity: normal
Resolution: | Keywords:
-----------------------+----------------------------------------------------
Comment (by coling):
Replying to [comment:3 tjyrinki]:
> Anyway. With -esd or -pulseaudio libsdl the problem, mostly (see below),
disappears. Is libsdl1.2's ALSA variant not supported by pulseaudio or
should it also work? Regarding this bug, if SDL's ALSA output plugin is
not within the safe subset of ALSA, this bug itself does not exist anymore
since esd and pulseaudio plugins work. Which is nice.
From our fairly extensive tests in Mandriva, we found that the ESD backend
was unbearable... mainly due to the delay that it introduced which made
playing games pretty pointless ;)
I'd say that it should be possible to make the libsdl ALSA output play
nice with pulseaudio (via the alsa plugin), but I've not played with the
code and I can't really comment as to what tricks they are using that is
causing problems. It could be they are trying to access the async API or
some other thing that is not allowed via the alsa plugin infrastructure.
As you say it may not stick to the "safe alsa subset" which suggests
you've read Lennart's blog on this topic, in which case you'll probably
know as much as me about it :p
> Using -esd or -pulseaudio however brings forward another bug/problem
with pulseaudio which still prevents its usage in this problematic case...
The background is that for some reason, FoF/pygame/sdl has a bug that
using 16-bit samples on x86-64 prevents some of the audio from playing (if
you hit wrong notes, the music in the background totally stops while it
shouldn't). The only solution to the problem so far has been to select
8-bit samples into use from FoF settings (yes, it sucks, but it's the only
solution found currently).
Weird. I'm not sure I can personally offer any insight here :(
> However, with libsdl1.2debian-esd, Pulseaudio and 8bit samples the sound
is garbled/cracking a lot. With libsdl1.2debian-pulseaudio and 8bit
samples the Frets on Fire simply does not start, instead hanging without
error message, probably in some audio subsystem initialization. Libsdl1
.2debian-alsa works fine, but exhibits the original problem presented in
this bug if pulseaudio is installed.
> Is lack of 8-bit sample size support a known issue in Pulseaudio, or
should I file a bug about it now?
To be honest I don't know. I wouldn't have expected pulse to be limited in
this way but I've not personally poked at that bit. A quick look in
sample.h showed me:
{{{
* PulseAudio supports the following sample formats:
*
* \li PA_SAMPLE_U8 - Unsigned 8 bit integer PCM.
}}}
So it should support 8 bit samples. That is not to say it actually works
properly (I've not tested) or that the SDL pulse layer exposes it
correctly (if it even has to - I'm not super familiar with how the SDL
audio engines work!).
HTHs provide some insight for further debugging :)
--
Ticket URL: <http://www.pulseaudio.org/ticket/406#comment:4>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server
_______________________________________________
pulseaudio-tickets mailing list
pulseaudio-tickets@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets
