jmorris at beau
May 7, 2012, 7:11 PM
Views: 575
Permalink
|
|
Re: Audio glitches on EPG and local commercals
[In reply to]
|
|
On Sun, 2012-05-06 at 18:43 +1000, Jean-Yves Avenard wrote:
> Well there you go.
>
> video is decoding to slowly and the gap between audio and video
> becomes too great and audio needs to be paused for video decoding to
> catch up.
That theory doesn't hold. Atom based systems with an NVIDIA GPU play HD
without problems and this system has a lot more grunt. I took off the
governors and it didn't help a bit. But that was still just theory so I
thought about it a bit and decided to get some numbers. the sensors
only read to 1C and the Kill-a-Watt only to a watt and the numbers
bounced around a bit. But by letting it run a hour or more in each mode
and taking a average after letting the temps settle down these numbers
should at least be enough to make some generalizations from:
CPU MB GPU Power
Idle 32 32 40 54
LiveTV SD 35 32 42 65
Play SD 35 32 42 66
LiveTV HD 34 33 56 70
Play HD 34 33 55 69
As expected there wasn't a real difference between LiveTV and playback
from the library. But note the difference between software decode of SD
and hardware decode of HD. It is pretty obvious that the CPU is not
working hard to playback either one while the GPU is earning it's keep
when the HD stream hits it. And for these tests I had the governors
(except C1E, that is disabled in BIOS) enabled and at no time observed
either core running faster than the base 1GHz.
> > It is complaining of underruns but I already did the bit to increase the
> > buffer with:
>
> the underruns are not due to buffering here, but because the audio
> card is starved
That isn't what I read. It is saying the video is behind the audio. It
tried dropping frames to catch up a few times and then gave up and
paused the audio and started it all back from scratch to get everything
in sync. In other words the audio didn't stop because the buffer ran
dry but because it was intentionally put into pause and that caused ALSA
to complain about the buffer running dru.
The question is why? I either have a minor problem that is tickling a
code path that doesn't see enough use to get optimized or I have a
really big problem somewhere so bad it somehow is getting totally
overwhelmed. But it looks like it is actually easier for this system to
play HD vs SD.
Just tried a test. If I tune a SD channel and go to the guide I can
make it skip if I beat on the pageup key a LOT.
Did notice I have a version of the Nvidia driver that is pretty old and
a newer one is in backports. Next maint window I'll try updating that
just to see what happens.
|
signature.asc
