RE: Interrupt-driven (or callback/handler?), Full-duplex (simultaneous capture/playback) without using JACK

["Ryan Cassidy" <rcassidy@stanford.edu>]

> On Sat, 8 Nov 2003, Ryan Cassidy wrote:
> 
> > > Paul Davis wrote:
**************************************************
> > > the ALSA PCM API doesn't have "handlers". it doesn't provide any
kind
> > > of callback mechanism. what it does do is to provide a poll(2)
> > > interface, allowing callback-like mechanisms to be built around it
> > > (like JACK).
> > >

> > Ryan J. Cassidy replies:
*********************************************
> > Will snd_async_add_pcm_handler() not do the trick?  It says
> > "asynchronous," which doesn't sound like what I want, but the
"handler"
> > part sounds promising :).
> >
> > If that doesn't work, it's sort of a bummer that ALSA doesn't offer
a
> > callback-mechanism for simultaneous audio i/o, non?  This means that
to
> > get "what I want" (i.e. allowing my program to do useful work while
> > waiting for new audio samples), I need to use snd_pcm_wait() and
fork
> > off an extra process to do the "useful work," right?


> Jaroslav replies:
****************************************************** 
> Yes, snd_async_add_pcm_handler() might help you and it works. It's
> originated in the interrupt handler. But please note that the handler
is
> in the unix style signal callback thus there are many restrictions
(you
> should avoid to do most of syscalls in this code etc.).
> 
> But for mmaped access and the standard ALSA transfer mechanism (use
only
> snd_pcm_avail_update() to get the right position) it is the fast way
to
> create an interrupt based handlers in the applications.
> 
> For the synchronization: You must do it in your application. We work
with
> two diferrent streams and although the streams are hardware
synchronized,
> there might be some buffering issues (FIFOs) so the playback and
capture
> pointers do not match exactly. So the best way is to obtain the
current
> pointer using snd_pcm_avail_update() and compute how many frames you
can
> process for the duplex operation (I mean for both streams).

Just to be sure here: it is possible, then, to add a single PCM handler
(via snd_async_add_pcm_handler()) to a LINKED pair of streams (one for
playback, one for capture)?  Moreover, this handler will be called only
once each period/buffer-time to signal the need for BOTH capture and
playback frames (since the streams are linked)?

(Note to Paul: I realize that no system calls are allowed within the
handler, but I think I could work around this via message-passing to the
main application.  Perhaps this is naïve/incorrect?)

Since the streams are hardware synchronized, is there any way to disable
the FIFOs that Jaroslav mentions above?  Why are the FIFOs needed in the
first place?

Cheers, rjc.
--
Ryan J. Cassidy
Electrical Engineering Graduate Student, CCRMA Researcher
Stanford University
E-mail: ryanc@ieee.org



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click