Using alsa-lib for timing

Using alsa-lib for timing

[Robert Spier]

[Summary of this message:
  I want to use alsa for timing of video frames, and want alsa to
  trigger a wakeup every .01466 seconds.  But the documentation is
  sparse in this area]


I'm attempting to use alsa-lib as a timing tool for a specialized
movie playback engine.  It _must_ tick/wakeup at 24fps (every .04166
sec) and the input audio will be at 44.1khz/2 channel/16bit per chan.

For legacy reasons we need to use the poll based interface
(getting the file handle from snd_pcm_poll_descriptors()).  

Alsa will tick regularly at .0416 seconds if the period size is set to
1837[1] samples.  This is suboptimal because:
    1- this is a weird period size - generally powers of 2 are used
    (1024,2048,4096)

    2- for truly accurate 24fps playback we need 1837.5 samples/video
    frame, which can be approximated by alternating between 1837 and
    1838 samples/video frame.  (And the period size cannot be changed
    at runtime.)

The general solution to this with other sound libraries (OSS and IRIX)
is to use a rational period size and set a wakeup point.  In ALSA,
this is done with snd_pcm_sw_params_set_avail_min, but it doesn't have
the expected effect. 

Because it's only a _minimum_ the wakeup can be delayed (usually until
a multiple of the period size) is reached.  This screws up the
timing.  I saw something in the alsa-devel archives that wakeup points
(avail_min) settings can only be powers of two... which is different
than OSS.)

Am I missing something obvious here?  
Are there any examples of code (or other tools?) doing similar things?

Please don't recommend I switch to asynchronous ticks, sadly, that
isn't an option for this code.

Thanks!

-R


Footnotes: 
[1]  24fps = .041666 seconds/video frame
     44100hz = samples/seconds
     1837.5 samples/video frame
     
     




-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: Using alsa-lib for timing

[Paul Davis]

>[Summary of this message:
>  I want to use alsa for timing of video frames, and want alsa to
>  trigger a wakeup every .01466 seconds.  But the documentation is
>  sparse in this area]
>
>
>I'm attempting to use alsa-lib as a timing tool for a specialized
>movie playback engine.  It _must_ tick/wakeup at 24fps (every .04166
>sec) and the input audio will be at 44.1khz/2 channel/16bit per chan.

you *cannot* do this with a stock linux kernel. its impossible. there
is no interrupt source that interrupts at that frequency. the firm
timers patch (probably only available for 2.4.16 at this point), or
the new POSIX clock stuff that is pending for 2.5/2.6 can do this
because they reprogram the system timer interrupt on an as-needed
basis. it provides u-sec level accuracy, in a highly efficient
fashion. 

>The general solution to this with other sound libraries (OSS and IRIX)
>is to use a rational period size and set a wakeup point.  In ALSA,
>this is done with snd_pcm_sw_params_set_avail_min, but it doesn't have
>the expected effect. 
>
>Because it's only a _minimum_ the wakeup can be delayed (usually until
>a multiple of the period size) is reached.  This screws up the
>timing.  

correct. thats why real time processes need to run:

	 * with SCHED_FIFO priority
	 * with mlockall() called
	 * on a kernel with the morton low latency patches or
	     equivalent applied.

even all these will not provide a solution that works the way you want.

	  I saw something in the alsa-devel archives that wakeup points
>(avail_min) settings can only be powers of two... which is different
>than OSS.)

no, its not different than OSS, even if the API appears to make it
so. there are almost no soundcards that interrupt at anything other
than periods-of-2 frames, and hence no matter what you set it to, the
kernel is only going to notice when the interrupt comes in, regardless
of what the API says. "why can't it notice because of the elapsed
time?" the kernel is interrupt-driven. in order to realize that a
certain amount of time has passed, it needs receive an interrupt (or
be finishing up a system call, in some cases) that give it a chance to
say "hmmm, looks like i need to service some pending tasks". that
requires an interrupt source with the desired periodicity or one that
is programmed on an as-needed ("one shot") basis. your kernel almost
certainly contains neither.

the basic problem is that you are going about this in the wrong
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.

--p






-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: Using alsa-lib for timing

[Robert Spier]

Paul, 

    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 wrong
>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.

    We've gone back to our standby method of timing everything off the
    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



-------------------------------------------------------
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

Re: Using alsa-lib for timing

[James Courtier-Dutton]

Robert Spier wrote:

>Paul, 
>
>    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 wrong
>>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.
>>    
>>
>
>    We've gone back to our standby method of timing everything off the
>    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
>  
>
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.
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