[mythtv] Re: Audio problem when changing channels

[John Coiner]

Let me comment on this, even though I haven't seen this problem.

Please please if you are checking in a fix for the 'Audio problem when 
changing channels' bug, could you run it by me, so I can verify that it 
doesn't break A/V sync. It very probably won't, I'm just being paranoid 
again.

For the curious, here is a bit about mythtv's a/v sync...

Our A/V sync works by varying the rate at which video frames are 
displayed, to keep sync with the audio. We can't vary how fast the audio 
is played; once we request a samplerate from the sound card, we're stuck 
with that (or, as close as the sound card gets to it, some cards are off 
by a few percent.)

On each frame, we calculate the error, how far off we are from perfect 
sync. The first (stupid) implementation I did corrected the entire error 
on each frame, but this produces jittery (i.e. jerky) video output. The 
reason is that our error calculation is based on querying the sound 
driver to find out where it is -- but the value returned by the sound 
driver is inexact, and the calculated error has a lot of noise as a result.

The solution is to correct only a small fraction of the measured error 
on each frame (currently we correct 1/50th of the error.) This is 
sufficient to maintain sync, and it also smooths out the noise, so that 
the video output has the lowest possible jitter.

Everything I've described so far exists to maintain A/V sync at steady 
state, when mythtv has been running, unpaused, on the same channel, for 
at least a few seconds. But we don't always have steady state-- a 
channel change is a disruptive event, which empties all the buffers, and 
usually puts the A/V out of sync. With '1/50th' feedback, it took too 
long to resync after a channel change. To deal with this, if we detect a 
very large A/V sync error, we use stiffer feedback to get back into sync 
quickly.

> From: "Emil Friis" <emilfriis@telocity.com>
> Subject: Re: [mythtv] Audio problem when changing channels
> Date: Fri, 01 Nov 2002 04:46:48 -0800 (PST)
> 
> I tried to watch CPU usage when this happened but that
> was not the problem and I wasn't even using any swap
> space, so I guessed at IO problems but couldn't get my
> harddrive to do any better than 284/20 with hdparm -tT.
> I ended up buying a new drive to use as storage and
> that solved my problems.

This sounds like a separate issue. The mythtv record module 
(NuppelVideoRecorder) has this wonderful feature that if it can't encode 
and store frames fast enough, it skips the encode step and just stores 
raw frames. This reduces CPU usage, but it increases I/O usage. So, if 
the problem was a shortage of CPU, this is good, and if the problem was 
a shortage of I/O bandwidth, this is very very bad because it makes the 
shortage much worse. The disk will thrash, audio and video will skip, 
although CPU use reported in 'top' is well below normal levels...

This is only true for rtjpeg. It looks like the mpeg4 stuff always 
encodes. (It also seems like the mpeg4 stuff always uses all available 
CPU to encode -- if I pause the player, the encoder picks up the slack. 
Very weird. Does anyone know why it does that?)

I think this is the best fix:

The recorder should have separate encode and write threads, and separate 
buffers for unencoded frames vs. encoded frames. Separate threads allow 
better utilization of the CPU and disk in parallel. If the unencoded 
buffer starts filling up, this implies a shortage of CPU, and it makes 
sense to skip the encode step. But, if the encoded buffer is filling up, 
this implies a shortage of I/O bandwidth, and we should not skip the 
encode step. Isaac, does this seem reasonable?

The simpler alternative is to allow people to specify 'SlowIO=1' to 
force it to always encode. When I did this, the record buffer overflowed 
frequently, so I made it larger, and then it overflowed occasionally... 
This is better than an I/O bound meltdown, but it wasn't perfect either. 
That's why I'm considering re-threading the recorder.

-- john