[pulseaudio-tickets] [PulseAudio] #406: Frets on Fire has eye-straining hickups when using PulseAudio

[PulseAudio]

#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