> 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: [EMAIL PROTECTED] ------------------------------------------------------- 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_id78&alloc_id371&op=click _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
