[mythtv] Re: Audio problem when changing channels

[Isaac Richards]

On Monday 04 November 2002 06:01 am, John Coiner wrote:
> 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.

Would you mind checking current CVS?  I made a few changes the other day to 
that section of code, since I was helping someone that it was taking a good 
15 seconds sometimes to resync after a channel change:

  - update the nexttrigger variable with the current time after a frame is 
displayed, and before calculating the time until the next frame should be 
shown.  If 'nexttrigger' was erroneously far in the future -- like a second 
or so -- the usleep limiter I put in there would kick in, and 'nexttrigger' 
would take quite a long time to drop back down to something close to the 
current time.  This change seems correct to me, but I'll revert it if it 
breaks stuff for you.

  - The reader in the audio output loop could wrap around the writer 
occasionally, if the numbers lined up wrong.  Really throws things off when 
that happens. =)

> 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?

That seems very 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.

Isaac