Callback after a specified number of samples

Callback after a specified number of samples

[Wolfgang Hesseler]

Hello,
is it possible to get a callback after a specified number
of samples (e.g. 4000) are played?
I'd like to refill the buffer then and need the exact
number to synchronize audio and video.

-- 
Werden Sie mit uns zum "OnlineStar 2002"! Jetzt GMX wählen -
und tolle Preise absahnen! http://www.onlinestar.de



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Callback after a specified number of samples

[Jaroslav Kysela]

On Sun, 29 Sep 2002, Wolfgang Hesseler wrote:

> Hello,
> is it possible to get a callback after a specified number
> of samples (e.g. 4000) are played?
> I'd like to refill the buffer then and need the exact
> number to synchronize audio and video.

Look to alsa-lib/test/pcm.c and "async" method.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Callback after a specified number of samples

[Wolfgang Hesseler]

Paul Davis <pbd@op.net> wrote

> >Hello,
> >is it possible to get a callback after a specified number
> >of samples (e.g. 4000) are played?
> >I'd like to refill the buffer then and need the exact
> >number to synchronize audio and video.
> 
> you can get this to a limited extent by setting the software parameter
> "avail_min" with snd_pcm_sw_params_set_avail_min(). it controls the
> number of frames of data/space that has to be available for a task
> sleeping on a read/write of the PCM stream to be woken up.
> 
> however, it won't do what you want, because the resolution is limited
> to the interrupt frequency of the audio card, and for just about every
> interface out there, this is almost always a power of 2 value. 

Is this an Alsa design or a hardware limitation?

> thus,
> you could set avail_min to 4000, but you be will woken only when the
> actual value is 4096, not 4000. why? because the ALSA driver has no
> way of knowing when the value is 4000 - it can only know when the
> interrupt comes in.
> 
> the only way around this is to use an alternate, higher-frequency
> interrupt source, such as the RTC (real time clock), but this
> is invariably power-of-2 also, and worse, doesn't run in sync
> with audio or video. if you could find a suitable source, you just
> check the current frames/space available every interrupt, and move on
> from there. i don't know of any suitable interrupt sources.
> 
> to put it another way, your approach is wrong :) syncing audio and
> video needs to be done differently. audio has a much higher frame
> rate, so use that as the basic time source, and simply redraw the
> screen at suitable intervals (preferably the vertical refresh
> interval), using the current audio "time" as a guide to what to draw.

You think of polling snd_pcm_avail_update and drawing the picture when
the calculated number of samples have been played?




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Callback after a specified number of samples

[tomasz motylewski]

I do the following: knowing the sample rate and the current position of the HW
pointer (via snd_pcm_avail_update - why there is no function which would tell
me directly that - the current position in the buffer?) I can calculate when
the required position _will_ happen. So  I can just schedule the timer or sleep
until that time. When it arrives I can check again snd_pcm_avail_update to see
whether my calculation way correct and adjust the sleep period.

I do not understand why ALSA drivers (or at least some plug-ins) could not do
the same?

There is also another problem: I understand that snd_pcm_avail_update does not
really read current count from the card, but uses a value stored in memory. So
it will only be updated when the card generates an interrupt. Is there any way
to force snd_pcm_avail_update or to use another function which will for sure
query the HW and not use the cached value? If the card does not have a
capability to report it, this could be extrapolated from the last time sample
counter was updated and the current time.

On Mon, 30 Sep 2002, Wolfgang Hesseler wrote:

> Paul Davis <pbd@op.net> wrote
> > the only way around this is to use an alternate, higher-frequency
> > interrupt source, such as the RTC (real time clock), but this
> > is invariably power-of-2 also, and worse, doesn't run in sync
> > with audio or video. if you could find a suitable source, you just
> > check the current frames/space available every interrupt, and move on
> > from there. i don't know of any suitable interrupt sources.

One can recompile the kernel with HZ=2000 to get at least 1 ms timer
resolution. And then use the method above, synchronizing by reading
snd_pcm_avail_update and noting when it changes.


Best regards,
--
Tomasz Motylewski



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Callback after a specified number of samples

[Jaroslav Kysela]

On Mon, 30 Sep 2002, tomasz motylewski wrote:

> I do the following: knowing the sample rate and the current position of the HW
> pointer (via snd_pcm_avail_update - why there is no function which would tell
> me directly that - the current position in the buffer?) I can calculate when
> the required position _will_ happen. So  I can just schedule the timer or sleep
> until that time. When it arrives I can check again snd_pcm_avail_update to see
> whether my calculation way correct and adjust the sleep period.
> 
> I do not understand why ALSA drivers (or at least some plug-ins) could not do
> the same?

What same? Offer position in ring buffer?

> There is also another problem: I understand that snd_pcm_avail_update does not
> really read current count from the card, but uses a value stored in memory. So
> it will only be updated when the card generates an interrupt. Is there any way
> to force snd_pcm_avail_update or to use another function which will for sure
> query the HW and not use the cached value? If the card does not have a
> capability to report it, this could be extrapolated from the last time sample
> counter was updated and the current time.

Use snd_pcm_status() to get the accurate timing information. The 
avail_update function is light version which does not need a context 
switch between user and kernel space.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Callback after a specified number of samples

[Wolfgang Hesseler]

Paul Davis <pbd@op.net> wrote:
 
>    [ please forward to alsa-devel@lists.sourceforge.net. thanks. ]
> 
> >> however, it won't do what you want, because the resolution is limited
> >> to the interrupt frequency of the audio card, and for just about every
> >> interface out there, this is almost always a power of 2 value.
> >
> >Is this an Alsa design or a hardware limitation?
> 
> hardware limitation.
> 
> >> to put it another way, your approach is wrong :) syncing audio and
> >> video needs to be done differently. audio has a much higher frame
> >> rate, so use that as the basic time source, and simply redraw the
> >> screen at suitable intervals (preferably the vertical refresh
> >> interval), using the current audio "time" as a guide to what to draw.
> >
> >You think of polling snd_pcm_avail_update and drawing the picture when
> >the calculated number of samples have been played?
> 
> sure, if you want to burn 90-100% of your available CPU cycles on the
> poll.
> 
> look, the screen gets redrawn at most 80 times a second and regular
> video is at most 30 frames a second. that contrasts with the audio
> frame rate by 2 orders of magnitude. if you had a way to redraw the
> screen at the start of the vertical refresh cycle, you could maintain
> absolutely perfect sync without anything more than a way to ask "which
> audio frame is audible right now?", which ALSA provides.
> 
> unfortunately, as i understand it, X provides no way to do this
> without hacks and patches, so you have to settle for a given frame
> rate, timed by the kernel with usleep(2), and then do the same check
> on the current audible frame when you wake up to redraw the screen.
> 
> --p



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Callback after a specified number of samples

[tomasz motylewski]

On Mon, 30 Sep 2002, Jaroslav Kysela wrote:

> > me directly that - the current position in the buffer?) I can calculate when
> > the required position _will_ happen. So  I can just schedule the timer or sleep
> > until that time. When it arrives I can check again snd_pcm_avail_update to see
> > whether my calculation way correct and adjust the sleep period.
> > 
> > I do not understand why ALSA drivers (or at least some plug-ins) could not do
> > the same?
> 
> What same? Offer position in ring buffer?

No, I ment, use the timing information to wake up application ealier if the
period interrupt is too long.

> Use snd_pcm_status() to get the accurate timing information. The 
> avail_update function is light version which does not need a context 
> switch between user and kernel space.

Thank you. This is a very valuable information. I was mislead by this "_update"
and I have thought that it will query the card.  

The documentation says "The function snd_pcm_avail_update updates (! here
should be written: reads, not updates) the current available count of samples
for writing (playback) or filled samples for reading (capture). ".

And may be "Obtaining fast device status" should be changed to ""Obtaining
device status fast" and written clearly that avail_update will in fact only
read the number.


BTW. I have just read (alsa-lib DOC) that snd_pcm_avail_update should always
return a positive number when there is no error. 

But unfortunately there is a bug in alsa-lib in snd_pcm_mmap_playback_avail and
snd_pcm_mmap_capture_avail (src/pcm/pcm_local.h) which may cause a negative
value to be returned. Just think what could happen if the initial avail is not
only < 0 , but avail < pcm->boundary as well. Then avail+pcm->boundary < 0
still.

This may happen if pcm->appl.ptr is not updated (I want the card to just
play/record all the time independent whether my application cares or not at the
moment). No underruns. This works, but I had to check for negative values
coming out of avail_update. This should be at least documented (fixing will not
be as easy as I have initially thought).

Best regards,
--
Tomasz Motylewski



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Callback after a specified number of samples

[Jaroslav Kysela]

On Mon, 30 Sep 2002, tomasz motylewski wrote:

> On Mon, 30 Sep 2002, Jaroslav Kysela wrote:
> 
> > > me directly that - the current position in the buffer?) I can calculate when
> > > the required position _will_ happen. So  I can just schedule the timer or sleep
> > > until that time. When it arrives I can check again snd_pcm_avail_update to see
> > > whether my calculation way correct and adjust the sleep period.
> > > 
> > > I do not understand why ALSA drivers (or at least some plug-ins) could not do
> > > the same?
> > 
> > What same? Offer position in ring buffer?
> 
> No, I ment, use the timing information to wake up application ealier if the
> period interrupt is too long.

We can use the system timer (or any timer, if available) inside the kernel 
space to do this. See the get_tick_time and set_tick_time (also -t option 
in alsa-lib/test/latency.c).

> > Use snd_pcm_status() to get the accurate timing information. The 
> > avail_update function is light version which does not need a context 
> > switch between user and kernel space.
> 
> Thank you. This is a very valuable information. I was mislead by this "_update"
> and I have thought that it will query the card.  
> 
> The documentation says "The function snd_pcm_avail_update updates (! here
> should be written: reads, not updates) the current available count of samples
> for writing (playback) or filled samples for reading (capture). ".

That's right. It updates pointers for read/write/begin/commit operations.

> And may be "Obtaining fast device status" should be changed to ""Obtaining
> device status fast" and written clearly that avail_update will in fact only
> read the number.

Changed.

> BTW. I have just read (alsa-lib DOC) that snd_pcm_avail_update should always
> return a positive number when there is no error. 
> 
> But unfortunately there is a bug in alsa-lib in snd_pcm_mmap_playback_avail and
> snd_pcm_mmap_capture_avail (src/pcm/pcm_local.h) which may cause a negative
> value to be returned. Just think what could happen if the initial avail is not
> only < 0 , but avail < pcm->boundary as well. Then avail+pcm->boundary < 0
> still.

Well. I think that you've reached another bug. hw.ptr and appl.ptr should 
be inside interval 0 .. (boundary - 1). So, in the worse case, first avail 
should be:

(1) hw.ptr + buffer_size = buffer_size
(2) appl.ptr = boundary - 1

(1) - (2) = buffer_size - (boundary - 1)

It's definitely greater value than -boundary, so the first if case should 
be hited and value should be corrected to regular interval from 0 to 
(boundary-1).

I really wonder, how you can get negative values. It seems that hw.ptr or 
appl.ptr goes outside boundary range which is bad.

> This may happen if pcm->appl.ptr is not updated (I want the card to just
> play/record all the time independent whether my application cares or not at the
> moment). No underruns. This works, but I had to check for negative values
> coming out of avail_update. This should be at least documented (fixing will not
> be as easy as I have initially thought).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf