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.

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: Are you worried about 
your web server security? Click here for a FREE Thawte 
Apache SSL Guide and answer your Apache SSL security 
needs: http://www.gothawte.com/rd523.html
_______________________________________________
Alsa-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-user

Reply via email to