Mailing List Archive: Sound jerkiness with latest RedHat kernel

Sound jerkiness with latest RedHat kernel

Jun 8, 2003, 3:02 PM

Post #1 of 8 (1537 views)

Hi all,

I'm currently using kernel 2.4.20-18.9 from RedHat. Since the latest
kernel upgrade I started noticing choppy audio and playback slowly lagging
behind live TV (after about 20 minutes of live TV, it's about 2 minutes
behind).

I'm using a PVR250 with a Pentium IV 2.4Ghz. CPU usage is really low
(below 6% user time and below 4% user time). I'm using an ultra ATA ide
subsystem with a dedicated disk for the ringbuffer/store.

I've have DMA enabled and a few tweaks on the HD:
/sbin/hdparm -X70 -c1 -W1 -A1 -a128 -u1 /dev/hdb

I tuned the elevator:
/sbin/elvtune -r 2048 -w 4096 -b 0 /dev/hdb

And I reduced the bitrate of the PVR:
/usr/local/bin/test_ioctl -d /dev/video0 -c bitrate=2500000,bitrate_peak=8000000

iostat results are:
avg-cpu: %user %nice %sys %idle
5.00 0.00 4.00 91.00

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/hdb 0.00 142.00 0.00 36.00 0.00 1424.00 0.00 712.00 39.56 42949613.96 2.78 27.78 100.00

However I had little success.

I've seen several messages posted to this mailing list complaining about
RedHat kernels. Could anybody solve this? Is anybody using latest RedHat
kernel without problems?

Thanks and best regards,

Flavio

Re: Sound jerkiness with latest RedHat kernel [ In reply to ]

rheller at cfl

Jun 8, 2003, 5:19 PM

Post #2 of 8 (1526 views)

Permalink

Flavio,

I just upgraded to 2.4.20-18.9 RedHat this afternoon and have not had
any problems of this sort. I've let Live TV run for about an hour now
and the audio and video are in perfect sync.

My system is quite different from yours, however. I have an Athlon 2500+
processor, LeadTek Win-something-or-another capture card (Brooktree 878
chip), Nvidia GeForce 4 FX5200-based video card using Nvidia's latest
drivers, and SB Live (EMU10K1-based) sound card using the OSS drivers
that come with RH9. MythTV is CVS from 6/6.

I built a custom-kernel so lirc would work. The serial driver change is
the only difference from the Athlon RH9 kernel config template. I tried
applying your hdparm and elvtune settings while the live tv was running
and could see no difference, good or bad.

Don't know what to say.......

Re: Sound jerkiness with latest RedHat kernel [ In reply to ]

calvin at houstonns

Jun 9, 2003, 1:52 PM

Post #3 of 8 (1520 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I also have this same problem. I found if I DO NOT set...

/usr/local/bin/test_ioctl -d /dev/video0 -c bitrate=2500000,bitrate_peak=8000000

the problem goes away. I have a 120gig drive so it is a fix for now, but not long...

Calvin

On Sun, Jun 08, 2003 at 06:02:04PM -0400, Flavio Villanustre wrote:
> Hi all,
>
> I'm currently using kernel 2.4.20-18.9 from RedHat. Since the latest
> kernel upgrade I started noticing choppy audio and playback slowly lagging
> behind live TV (after about 20 minutes of live TV, it's about 2 minutes
> behind).
>
> I'm using a PVR250 with a Pentium IV 2.4Ghz. CPU usage is really low
> (below 6% user time and below 4% user time). I'm using an ultra ATA ide
> subsystem with a dedicated disk for the ringbuffer/store.
>
> I've have DMA enabled and a few tweaks on the HD:
> /sbin/hdparm -X70 -c1 -W1 -A1 -a128 -u1 /dev/hdb
>
> I tuned the elevator:
> /sbin/elvtune -r 2048 -w 4096 -b 0 /dev/hdb
>
> And I reduced the bitrate of the PVR:
> /usr/local/bin/test_ioctl -d /dev/video0 -c bitrate=2500000,bitrate_peak=8000000
>
> iostat results are:
> avg-cpu: %user %nice %sys %idle
> 5.00 0.00 4.00 91.00
>
> Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
> /dev/hdb 0.00 142.00 0.00 36.00 0.00 1424.00 0.00 712.00 39.56 42949613.96 2.78 27.78 100.00
>
>
> However I had little success.
>
> I've seen several messages posted to this mailing list complaining about
> RedHat kernels. Could anybody solve this? Is anybody using latest RedHat
> kernel without problems?
>
> Thanks and best regards,
>
> Flavio
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE+5POZ1CCG53ZaRNYRAvubAJ9xteafwPRY4iFoBSCd2pPyyQA/BACfVeU9
+0PFTMTkSoLQ7RLMRjPGxCI=
=kdRy
-----END PGP SIGNATURE-----

Re: Sound jerkiness with latest RedHat kernel [ In reply to ]

craigl at begeek

Jun 9, 2003, 3:43 PM

Post #4 of 8 (1507 views)

Permalink

Calvin Gorriaran wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I also have this same problem. I found if I DO NOT set...
>
> /usr/local/bin/test_ioctl -d /dev/video0 -c bitrate=2500000,bitrate_peak=8000000
>
>the problem goes away. I have a 120gig drive so it is a fix for now, but not long...
>
so if you do a:

test_ioctl -C

it shows you recording at 8Mbps/16Mbps?

i have the same problem, dropping it below about 6Mbps and it starts
getting all choppy. now i settle on 6 and 9. very strange, what
prco/memory do you have?

cheers,

CraigL->Thx();

Re: Sound jerkiness with latest RedHat kernel [ In reply to ]

calvin at houstonns

Jun 9, 2003, 3:57 PM

Post #5 of 8 (1504 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[mythtv@pvr-01 utils]$ sudo ./test_ioctl -C
Password:
ioctl: IVTV_IOC_G_CODEC
Codec parameters
aspect : 2
audio : 0x00e9
bframes : 3
bitrate : 8000000
bitrate_peak: 16000000
dnr_mode : 3
dnr_spatial : 0
dnr_temporal: 0
dnr_type : 0
framerate : 0
framespergop: 15
gop_closure : 0
pulldown : 0
stream_type : 0
[mythtv@pvr-01 utils]$

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE+5RC/1CCG53ZaRNYRAv8lAJ9Oa+E02lUlzURtgQGE3w/bg0kKaACghk+3
FpJdJumAQ8D8y3mf+xgrBxU=
=97ou
-----END PGP SIGNATURE-----

Re: Sound jerkiness with latest RedHat kernel [ In reply to ]

matt at mmc

Jun 9, 2003, 6:08 PM

Post #6 of 8 (1547 views)

Permalink

What do you consider "jerky" and "choppy" ??

I found the best test is to watch CNN and watch the scroll. I have now
noticed that the scroll jerks every 20 - 30 seconds. I am going to
recompile a vanilla kernel from kernel.org and see what happens.

-Matt

--

Craig Longman said:
> Calvin Gorriaran wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>I also have this same problem. I found if I DO NOT set...
>>
>> /usr/local/bin/test_ioctl -d /dev/video0 -c
>> bitrate=2500000,bitrate_peak=8000000
>>
>>the problem goes away. I have a 120gig drive so it is a fix for now, but
>> not long...
>>
> so if you do a:
>
> test_ioctl -C
>
> it shows you recording at 8Mbps/16Mbps?
>
> i have the same problem, dropping it below about 6Mbps and it starts
> getting all choppy. now i settle on 6 and 9. very strange, what
> prco/memory do you have?
>
> cheers,
>
> CraigL->Thx();
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users
>

Re: Sound jerkiness with latest RedHat kernel [ In reply to ]

craigl at begeek

Jun 9, 2003, 7:08 PM

Post #7 of 8 (1528 views)

Permalink

Matt wrote:

>What do you consider "jerky" and "choppy" ??
>
every second or so the audio stops for a little bit (<1/10 of a second
perhaps). the video also seems to pause for an equally short period.
the problem may only be with one or the other, and then the other one
just pausing to resync, i'm not sure. that's what i consider 'choppy'.

>I found the best test is to watch CNN and watch the scroll. I have now
>noticed that the scroll jerks every 20 - 30 seconds. I am going to
>recompile a vanilla kernel from kernel.org and see what happens.
>
>
thats a little different. i notice minor jerks like that on cnn now
much less frequently, with the latest experimental + jitter reduction
code. it had been much more jerky before that, so much so that i turned
off the overlay, preferring the odd bit of tearing from the jerking i
was seeing. but now i have turned it back on and am pleased. my system
still jerks the cnn scroller more that i would like (maybe every 3-5
seconds), but its way, way better.

that's mytechnical definitions for 'jerky' and 'choppy' at least. :-)

i also intend on trying a new kernel or two. i notice someone else
mentioned that they had problems with both the low-latency and the
pre-emptive patches, so i might just try one or the other (probably the
low-latency?) and see if that helps or not. right now i'm running a
stock (custom compiled, but nothing out of the ordinary compiled in)
debian 2.4.20 kernel.

cheers,

CraigL->Thx();

Re: Sound jerkiness with latest RedHat kernel [ In reply to ]

bjm at lvcm

Jun 9, 2003, 8:54 PM

Post #8 of 8 (1514 views)

Permalink

Craig Longman wrote:
> Matt wrote:
>
>> What do you consider "jerky" and "choppy" ??
>>
> every second or so the audio stops for a little bit (<1/10 of a second
> perhaps). the video also seems to pause for an equally short period. the
> problem may only be with one or the other, and then the other one just
> pausing to resync, i'm not sure. that's what i consider 'choppy'.

Right. This is usually a pause to straiten out things in
the buffers. It's not that there aren't enough megs of data
in the pipe, it's when things don't happen in quite the right
order for the next frame to be ready in time. This is one
distinct type of problem, the audio cuts out and the picture
freezes for a fraction of a second.

>> I found the best test is to watch CNN and watch the scroll. I have now
>> noticed that the scroll jerks every 20 - 30 seconds. I am going to
>> recompile a vanilla kernel from kernel.org and see what happens.
>>
>>
> thats a little different. i notice minor jerks like that on cnn now
> much less frequently, with the latest experimental + jitter reduction
> code. it had been much more jerky before that, so much so that i turned
> off the overlay, preferring the odd bit of tearing from the jerking i
> was seeing. but now i have turned it back on and am pleased. my system
> still jerks the cnn scroller more that i would like (maybe every 3-5
> seconds), but its way, way better.

This is the problem of trying to update the frame for the
graphics card at just the right time so that there is a
one to one relationship between the frames and the screen
refreshes. This despite a multiuser scheduler where other
process may want the CPU when the frontend needs it. When
there are misses, there is no update for one frame then two
updates for the next. The audio is continuous but the CNN
crawler will have nervous twitches.

> that's mytechnical definitions for 'jerky' and 'choppy' at least. :-)

Good job. I followed exactly what you meant =).

-- bjm