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
