[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 tjyrinki):

 This one pointed me in right direction, thanks. Indeed FoF uses pygame
 which uses SDL. It seems Ubuntu still defaults to libsdl1.2debian-alsa
 instead of -esd or -pulseaudio. The -pulseaudio is not in main (supported)
 repository yet.

 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.


 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).

 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?

-- 
Ticket URL: <http://www.pulseaudio.org/ticket/406#comment:3>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server