Robert Spier wrote:
Paul,One approach I have taken to try and overcome the problem of using audio card clocks and system clocks, it that I use resampling. So I use the system clock to sync audio/video, and then let the audio card ask for samples, using a sort of callback method from alsa, similar to the way jack gets alsa to simulate a callback interface.
Thank you for your clear explanation. I've submitted a small
documentation patch to the sf.net project which might prevent the
next person who comes along from falling into the same trap.
the basic problem is that you are going about this in the wrongWe've gone back to our standby method of timing everything off the
way. there have been many discussions here and on LAD about how to do
this sort of thing. its not easy. your first and most basic problem is
that you are trying to sync two clocks (the video frame clock and the
audio frame clock) that do *not* run in sync. any solution that starts
with this as its approach is going to fail, for better or for worse.
audio, using polling to trigger the RTC for a per-frame delay.
It's CPU intensive, but works well enough for our purposes.
(Although definitely sub-optimal and quite nasty.)
-R
If my application notices that the sound card is outputting samples too quickly(I.E. audio hardware clock is slightly faster than the system clock), it does some resampling, thus making the sound card have to output more samples. As the sound card now has more samples, it then is kept in step with the system clock.
I have found that the linux system clock is always more accurate than most sound card clocks, so I believe that this approach is quite good.
Cheers
James
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
