[mythtv] LiveTV playback timing problems

[Paul Sykes]

Hi,

On Sat, 27 Nov 2004 17:47:09 +0000, Ed Wildgoose <lists at wildgooses.com> wrote:
> 
> >Ok, I have managed to use /proc/asound to show that the soundcard is
> >receiving and playing a 48khz signal so I do not think it is related
> >to that.
> >
> >
> 
> Great.  First step out of the way.
> 
> >My soundcard, as I said in my last e-mail, is a C-Meida CMI 8738 PCI
> >(onboard) soundacard.  I have also tried a usb sp/dif soundcard that I
> >have and exactly the same thing happens.
> >
> >
> 
> OK, sorry I missed that point.  I don't know what that is, but as long
> as the driver works then fine.
> 
> Can you please try playing back one of the myth tv files in mplayer and
> telling me whether that works ok?  Please try using both alsa and oss
> drivers in mplayer (use the "-ao" param).  The code in mplayer is
> "somewhat" similar to myth and so this gives a few clues.
> 
> Can you also confirm whether you ARE using an external digital
> receiver?  Can you try just using analogue out on the card.

I am not using a digital receiver, my C-Media card is outputting 2
channels to my amp and my USB digital device outputs to a sony md deck
before heading for the same amp.

> Now, once you have done the above, try both the alsa and OSS drivers in
> myth.  OSS is done just by changing the output device to "/dev/dsp" or
> whatever.  To get alsa, just give it the device something like "
> ALSA:plughw:0"

I have tried both these and the same thing happens, the audio and
video stay in sync and appear to be in realtime as the clock on BBC
News 24 remains correct, however the timer showing the position in the
livetv feed falls behind.  I have also tried arts and it all does the
same thing.

> >I do not think that this is a problem related to sound/video hardware,
> >I think that it is something to do with the linux timing services,
> >like the RTC.
> >
> >
> 
> Perhaps.  However, Myth works as follows:
> 
> 1) Feed the audio to the card as fast as possible
> 2) Count the bytes going into the card and assume 48000 samples per
> sec.  When we have sent 48000 / 25 samples (=1920 samples) then it must
> be time to draw the next frame (assuming 25 fps).

What is the timing method used for the timeshift timer?  This is the
timer that is falling behind, despite the fact that both the video and
the audio play back at the correct speed and reamin in sync.

> The RTC is just used to help us wait for the magic moment using a little
> less CPU.  The alternative is to simply use "usleep" or even count
> sheep, which is less accurate and can consume more CPU.  There are other
> methods as well.

I have tried removing all RTC support from the timer so the latest cvs
release shows that it is using usleep as a timing method and the same
thing happens.  This also happens with generic RTC support enabled and
enhanced RTC support.  I have also tried HPET but I'm not sure that my
procossor/motherboard support it. Another timing source that the cvs
version has attempted to use is SGI OpenGL but again the same thing.

> If you give myth an impossible audio device then it should error when
> you start playback and offer to play without audio.  This will then stop
> feeding data to the card and should revert to simply using the clock for
> video sync.  Perhaps doing this will confirm if it's really an audio problem

Even with the audio device disabled the video stays in sync with real
time, but the timer that appears when I press the pause button or stry
and skip backwards has fallen behind, after a few minutes.  What is
the timing method used for this timer?  I know that usually there
would be a timing signal in the video track, but that does not appear
to be the way the mythtv works?

> In summary, feeding stufff down spdif has a few funny gremlins which can
> bite with some dodgy drivers.  Try the tests above and we can see if
> it's your audio drivers or not.

I am not feeding anything down an spdif so hopefully these 'gremlins'
are not taking hold.
 
> Ed W
> 

Thanks

Paul