[pulseaudio-discuss] Pulseaudio Delay with Mythtv

[Lennart Poettering]

On Sat, 18.04.09 11:20, Ken Mandelberg (km at mathcs.emory.edu) wrote:

> Recently the trunk build of Mythtv checks if pulseaudio is running and  
> aborts if it does. This is because of the rather large audio delay it  
> induces and the resulting sync with video issue.

The timing APIs in PA are certainly good enough to allow lip-sync
audio. Works perfetcly fine ih gst and mplayer and everywhere. If it
doesn't in MythTV than it is most likely a problem in their code.

Not sure what kind of strange stuff MythTV does. Most likely they are
misuing snd_pcm_delay() or snd_pcm_avail() in some way or do other
nasty assumptions regarding the values returned by it. (i.e. subtract
them from the assumed buffer size and so on). Or maybe they didn't
call them at all?

Would be good if they would follow the recommendations regarding the
'safe ALSA subset' from this guide:

http://0pointer.de/blog/projects/guide-to-sound-apis.html

If they follow this guide and implement their output driver
accordingly this will not only increase compatibility with PA but also
with other non-kernel ALSA backends such as the bluez or jack
plugins. It will even improve compatibility with some hardware sound
cards where the playback buffer is not directly mmap'able.

And also this little guide I put together for the Ekiga folks
regarding selection of the period and buffer sizes would be good to
follow:

http://bugzilla.gnome.org/show_bug.cgi?id=577498

Almost nobody understands properly how period configuration should be
chosen. I'd bet MythTV doesn't do it correctly either. That guide
might help fixing that.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4