Many thanks for the info.! I guess my follow-up question would be this: I want to implement non-busy waiting for alsa simultaneous audio playback/capture. If I call the blocking versions of snd_pcm_read/snd_pcm_write in a separate process (that I fork off from the main application), will the read/write process yield to the main application process during the blocking read/write (i.e. will it got to sleep waiting for i/o?)?
Cheers, rjc. -- Ryan Cassidy Electrical Engineering Graduate Student, CCRMA Researcher Stanford University E-mail: [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:alsa-devel- > [EMAIL PROTECTED] On Behalf Of Jaroslav Kysela > Sent: Sunday, November 09, 2003 12:38 AM > To: Ryan Cassidy > Cc: 'Paul Davis'; [EMAIL PROTECTED] > Subject: RE: [Alsa-devel] Interrupt-driven (or callback/handler?), Full- > duplex (simultaneous capture/playback) without using JACK > > On Sat, 8 Nov 2003, Ryan Cassidy 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). > > > > > > > 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? > > 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). > > For a playback example, you might look to alsa-lib/test/pcm.c - see > the async_callback() function contents. > > Jaroslav > > ----- > Jaroslav Kysela <[EMAIL PROTECTED]> > Linux Kernel Sound Maintainer > ALSA Project, SuSE Labs > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Alsa-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/alsa-devel ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
