[vdr] Re: Softdevice + EPIA-M / Sound resampling

["Colin Paton" <ac2crp@blueyonder.co.uk>]

Hi,

I suspect that the audio thread may be being starved of CPU access which is
why I'm getting funny audio.

I did rough benchmarks with 'top' and got the following results on an M10000
Nehemiah CPU:

Playing back with sound + MPEG decoding but no video display (but call to
'Flip') = ~17% CPU
Playing back with blit added (get video display) = ~78% CPU
Playing back with FB sync but no blit = ~46% CPU
Playing back with blit + FB sync = ~98% CPU

Without sync and blit audio sounds OK.

My next task is to try and track down why sync and blit are using lots of
CPU. I suspect there's a busy loop in there somewhere.

I figured it would probably be suitable just to be simple and drop or add a
frame in order to maintain sync between the broadcast timestamps and the
video clock. I go with the assumption that the difference between the two
shouldn't be too much, therefore the odd frame slip won't be noticeable.
Obviously setting the clock exactly is the correct way to do it - but I
suspect would be quite involved, especially as I don't have datasheets for
the chip.

Does anyone have the audio problem with softdevice on a 'meaty' CPU?

Thanks,

Colin


----- Original Message -----
From: "Henrik Johansson" <henjo@ieee.org>
To: <vdr@linuxtv.org>; <ac2crp@blueyonder.co.uk>
Sent: Sunday, February 01, 2004 2:55 PM
Subject: Re: [vdr] Softdevice + EPIA-M / Sound resampling


> Colin Paton wrote:
>
> >Hi,
> >
> >I have glued some CLE266 hardware mpeg2 decoding code into softdevice.
I've
> >now got this working with my Nehemiah M10000 and CVS DirectFB. Video is
> >working well - smooth pictures on the display.
> >
> >
> Great news.
>
> >However, the sound is still a bit iffy and AV sync isn't perfect. I
suspect
> >that the sound card (I'm using ALSA) isn't quite playing back at the same
> >rate as the video.
> >
> >I wait for the vertical blanking pulse before flipping the video
> >framebuffer. This works well - get smooth pictures, but causes problems
with
> >the sound.
> >
> >I would therefore like to change the following:
> >
> >- Make video the primary sync source, and match audio to video.
> >- Resample the audio in order to alter the frame rate slightly if
necessary.
> >This should hopefully avoid the gaps and clicks that I've been
experiencing.
> >
> >I think that xine resamples the audio so I'll have a look at that.
> >
> >I have two questions:
> >
> >- Is audio resampling really necessary? I'm not an MPEG A/V sync expert -
> >perhaps someone more qualified could point me to a source of information?
> >- Is anyone already doing this? I don't want to reinvent any wheels!
> >
> >
> >
> I'm not an MPEG A/V sync expert either but isn't the problem even worse.
> When you're waiting for the vertical blanking pulses which are not in
> perfectly sync with the DVB stream clock reference (PCR) you will
> eventually get dropped frames. To do this right (which probably is not
> possible) I think you need to sync both the frame rate of the video mode
> and the audio clock to the PCR. The latter should be possible by
> resampling the audio stream before sending it to the soundcard as you
> suggest. For the video I think it could be done by implementing a PLL in
> software which measures the VBL frequency and compares this with the PCR
> clock and use the correction signals to program the videomode timing
> parameters.
>
> What do you think?
>
> Regards
> Henrik Johansson
>
>



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.