Mailing List Archive

I get audio dropouts when changing channels, but it is only momentary. If I
scroll through channels audio usually drops out until I slow scrolling down
or stop altogether.

On 31 Oct 2002 at 21:32, Randy Page wrote:

> I seem to have an audio problem when I change channels quickly using mythtv.
> After about 4 channels the audio starts to slow down. After about 6 channels


Do you mean the audio falls behind the video, or just slows down in general,
ie opposite of the highspeed chipmunk effect?
--
Harondel J. Sibble
Sibble Computer Consulting
Creating solutions for the small business and home computer user.
help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com
(604) 739-3709 (voice/fax) (604) 686-2253 (pager)

I had the same problem as Randy only it was a little
random when it happened - sometimes it happened when I
was changing channels very quickly, sometimes when I
was just watching tv and most often when I was watching
a program that I was recording. It makes both the video
and audio slow down - so yeah, just the opposite of
chipmunk effect.

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. So if you have the same
problems try to either tune your harddrive, replace
your drive with a new faster one or just add an
additional drive you just use for storage.

-Emil

On Fri, 01 Nov 2002, "Harondel J. Sibble" wrote:

>
> I get audio dropouts when changing channels, but it is
> only momentary. If I
> scroll through channels audio usually drops out until
I
> slow scrolling down
> or stop altogether.
>
> On 31 Oct 2002 at 21:32, Randy Page wrote:
>
> > I seem to have an audio problem when I change
> channels quickly using mythtv.
> > After about 4 channels the audio starts to slow
down.
> After about 6 channels
>
>
> Do you mean the audio falls behind the video, or just
> slows down in general,
> ie opposite of the highspeed chipmunk effect?
> --
> Harondel J. Sibble
> Sibble Computer Consulting
> Creating solutions for the small business and home
> computer user.
> help@pdscc.com (use pgp keyid 0x3AD5C11D)
> <a
href="http://mail.telocity.com/jump/http://www.pdscc.com">http://www.pdscc.com</a>
> (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@snowman.net
> <a
href="http://mail.telocity.com/jump/http://www.snowman.net/mailman/listinfo/mythtv-dev">http://www.snowman.net/mailman/listinfo/mythtv-dev</a>

On Thursday 31 October 2002 09:58 pm, Harondel J. Sibble wrote:

> Do you mean the audio falls behind the video, or just slows down in
> general, ie opposite of the highspeed chipmunk effect?

Opposite of the highspeed chipmunk effect.

R.

Thats exactly what I got...

What result do you get from doing hdparm?

hdparm -tT /dev/hd? (whatever your drive is)

Randy Page wrote:

>
> On Thursday 31 October 2002 09:58 pm, Harondel J.
> Sibble wrote:
>
> > Do you mean the audio falls behind the video, or
just
> slows down in
> > general, ie opposite of the highspeed chipmunk
effect?
>
> Opposite of the highspeed chipmunk effect.
>
> R.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@snowman.net
> <a
href="http://mail.telocity.com/jump/http://www.snowman.net/mailman/listinfo/mythtv-dev">http://www.snowman.net/mailman/listinfo/mythtv-dev</a>

On 1 Nov 2002 at 10:39, Emil Friis wrote:

> Thats exactly what I got...
>
> What result do you get from doing hdparm?
>
> hdparm -tT /dev/hd? (whatever your drive is)

This is a 20gb Seagate Barraudda IV - 7200rpm

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.69 seconds =185.51 MB/sec
Timing buffered disk reads: 64 MB in 1.70 seconds = 37.65 MB/sec
[root@marcus root]# hdparm -tT /dev/hdb

This is a 40gb Western Digital - 7200rpm

/dev/hdb:
Timing buffer-cache reads: 128 MB in 0.68 seconds =188.24 MB/sec
Timing buffered disk reads: 64 MB in 1.41 seconds = 45.39 MB/sec

--
Harondel J. Sibble
Sibble Computer Consulting
Creating solutions for the small business and home computer user.
help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com
(604) 739-3709 (voice/fax) (604) 686-2253 (pager)

This is what I get: (30 gb WD 5400rpm)

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.69 seconds =185.51 MB/sec
Timing buffered disk reads: 64 MB in 2.70 seconds = 23.70 MB/sec

I think a new drive is in order.

Randy

On 1 Nov 2002 at 12:38, rpage wrote:

> I think a new drive is in order.
You might check here
http://www.hardwareanalysis.com/content/article/1540

That's how I ended up with my 40gb WD.
--
Harondel J. Sibble
Sibble Computer Consulting
Creating solutions for the small business and home computer user.
help@pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com
(604) 739-3709 (voice/fax) (604) 686-2253 (pager)

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

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