[mythtv] No Start with Pulse Audio (Changeset 20310)

[Daniel Kristjansson]

On Thu, 2009-04-23 at 20:18 +0100, Ed W wrote:
> Forgive joining in 2 weeks later, but the issue seems to be unrelated
> to pulseaudio or myth - the issue seems to be just kernel scheduling
> being way off the mark on some kernels. Actually it seems surprising
> that myth works at all reliably under these conditions either - if
> busy wait loops are being serviced at 1/5 second kind of intervals
> then likely plenty more things are going to go wrong than the
> relatively small problem of feeding the audio server with a small
> amount of data?

I have a tree locally with pulseaudio output that I plan to merge
before 0.22. It should work much better than using the pulse audio
ALSA emulation, but will still fail in some extreme cases.

According to a pulse audio dev the issue is with the pulse audio
config and the default kernel config used in Ubuntu. The kernel they
use in Ubuntu does not have the low-latency and high HZ enabled but
pulse audio is compiled with options that only work acceptably when
those options are used. Unfortunately some useful drivers do not
work acceptably with those same options enabled. This is further
complicated because the way we measure latency in MythTV's ALSA
output code is incompatible with pulse audio's implementation of
the ALSA API.

There are also latency issues with the latest released version of
pulse audio which are fixed in svn. Ubuntu's pulse audio packager
directed me to use the latest ALSA and the svn pulse audio and that
did in fact solve the > 1/2 second latency problems I was seeing
when I first ran into problems with the pulseaudio's ALSA emulation.
But obviously we can't require that end users compile their own
pulse audio server from svn. (FYI Compiling a low latency, high HZ
kernel also worked. And while I would prefer that everyone used a
low latency kernel with MythTV, it should work without it.)

The solution for 0.21-fixes and current trunk just disables pulse audio
mixing when MythTV is running, but the plan is use pulse audio when
you use the MythTV's own pulse audio output and disable it when using
the other output methods. Both because the 'emulation' mode seems to
cause more problems than the native mode and because then if a user
does  have huge delays with pulse audio, they will just need to
reconfigure MythTV to not use it in order to bypass it.

-- Daniel