[mythtv] Issues with ALSA

Neil Whelchel koyama at firstlight.net
Fri Mar 19 20:57:51 EST 2004

I have been having a number of issues with ALSA and libmyth with audio
sync and buffering. (blocking)

When I run the video player with ALSA I get hundreds of "Audio buffer
overflow, audio data lost!" messages and the video plays back at ~1200
frames per second with 100% CPU usage and the audio is chopped up badly.

Upon looking through audiooutputalsa.cpp I noticed that there is nothing
to block within AudioOutputALSA::AddSamples(). (There is some blocking
code in AudioOutputOSS::AddSamples().)

The way that I understand the player
(please correct me if I am wrong) is that the A/V stream demux, audio
decoding, and playback are in the same thread (video is handed off), and
this thread is blocked by the audio buffer becoming full. The video thread
checks the PTS of the audio and displays the next frame based on this

Based on the audio buffer blocking the demux/decode I made the following
change to AudioOutputALSA::Reconfigure():

err = snd_pcm_open(&new_pcm_handle, audiodevice,

err = snd_pcm_open(&new_pcm_handle, audiodevice,

(Open in blocking mode instead of nonblocking.)
This corrected the problem and everything seems to work properly, however
this created a new question as well:
For some reason AudioOutputOSS has a function to set or clear blocking
(AudioOutputOSS::SetBlocking()). Under which conditions does the player
require the audio output not to block? Can AudioOutputALSA work correctly
without the equivalent of AudioOutputOSS::SetBlocking() or is there some
condition/mode that may require it?

The other half of my problem is poor/bad audio/video sync:
I reduced problem this by changing AudioOutputALSA::AddSamples():

audbuf_timecode = timecode + (int)((frames*100000.0) / effdsp);

audbuf_timecode = timecode;

There is a comment in the code that suggests that the timestamp handed to
this function is at the start of the chunk and that the above code
obviously adjusts it to the end...
However, upon watching the values handed to the function, it seems more
like the PTS is at the end. (The first time AudioOutputALSA::AddSamples()
is called the timestamp is not zero, it is usually between 25-40, which is
about right to be at the end. I have not yet looked at the demux code, so
at the moment it is a black box to me, so this is based upon speculation.)
However, even if it is wrong, it results in much better A/V sync in my

-Neil Whelchel-
First Light Internet Services
760 366-0145
- We don't do Window$, that's what the janitor is for -

More information about the mythtv-dev mailing list