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

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

[Ryan Cassidy]

Hi all,

I am trying to write an application that uses ALSA interrupt-driven
(which I guess is obtained by adding PCM handler(s) in ALSA?),
full-duplex (simultaneous capture/playback) using the ALSA PCM API
directly (i.e. not using JACK).

My question: do I only need to register one callback/handler function to
take care of both capture and playback?  My hope is that when I link the
capture and playback streams, and register a single handler with either
capture or playback, this handler will be called whenever there is BOTH
capture data to be read and a free playback buffer to be written (?).
Is this the case?

Any help, info., or advice GREATLY appreciated.

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




-------------------------------------------------------
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/

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

[Paul Davis]

>I am trying to write an application that uses ALSA interrupt-driven
>(which I guess is obtained by adding PCM handler(s) in ALSA?),
>full-duplex (simultaneous capture/playback) using the ALSA PCM API
>directly (i.e. not using JACK).
>
>My question: do I only need to register one callback/handler function to
>take care of both capture and playback?  My hope is that when I link the
>capture and playback streams, and register a single handler with either
>capture or playback, this handler will be called whenever there is BOTH
>capture data to be read and a free playback buffer to be written (?).
>Is this the case?

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). 

the snd_pcm_wait() function isn't enough for what you want to do, and
using it to what you want to do is equivalent to reimplenting the JACK
ALSA driver. a couple of people have asked that the core of JACK's
ALSA driver's inner loop be merged into alsa-lib, since it would do
what you want (take N PCM handles, block and return when all of them
have at least X frames of audio ready to read or write). at this time,
this has not happened, and there is no sign that it will be.

if you really don't want to use JACK, then i would suggest that,
assuming your program is be either private or distributed under the
GPL, you just take the JACK ALSA driver and use that as a template for
your efforts. its not simple, because full-duplex, interrupt-driven
audio i/o is not simple unless you're a JACK client :) if you want to
write the "server", you have to work a lot harder.

either that, or take a look at ecasound's ALSA i/o code, since i think
that kai implemented that "correctly" also.

--p



-------------------------------------------------------
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/

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

[Ryan Cassidy]

Paul,

Many thanks for the speedy reply!  See responses below...

> -----Original Message-----
> From: alsa-devel-admin@lists.sourceforge.net [mailto:alsa-devel-
> admin@lists.sourceforge.net] On Behalf Of Paul Davis
> Sent: Saturday, November 08, 2003 7:42 PM
> To: rcassidy@stanford.edu
> Cc: alsa-devel@lists.sourceforge.net; ryanc@ieee.org
> Subject: Re: [Alsa-devel] Interrupt-driven (or callback/handler?),
Full-
> duplex (simultaneous capture/playback) without using JACK
> 
> >I am trying to write an application that uses ALSA interrupt-driven
> >(which I guess is obtained by adding PCM handler(s) in ALSA?),
> >full-duplex (simultaneous capture/playback) using the ALSA PCM API
> >directly (i.e. not using JACK).
> >
> >My question: do I only need to register one callback/handler function
to
> >take care of both capture and playback?  My hope is that when I link
the
> >capture and playback streams, and register a single handler with
either
> >capture or playback, this handler will be called whenever there is
BOTH
> >capture data to be read and a free playback buffer to be written (?).
> >Is this the case?
> 
> 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?

> the snd_pcm_wait() function isn't enough for what you want to do, and
> using it to what you want to do is equivalent to reimplenting the JACK
> ALSA driver. a couple of people have asked that the core of JACK's
> ALSA driver's inner loop be merged into alsa-lib, since it would do
> what you want (take N PCM handles, block and return when all of them
> have at least X frames of audio ready to read or write). at this time,
> this has not happened, and there is no sign that it will be.
> 
> if you really don't want to use JACK, then i would suggest that,
> assuming your program is be either private or distributed under the
> GPL, you just take the JACK ALSA driver and use that as a template for
> your efforts. its not simple, because full-duplex, interrupt-driven
> audio i/o is not simple unless you're a JACK client :) if you want to
> write the "server", you have to work a lot harder.

I'm willing to go over to JACK eventually, but I'd like to see "how it's
done" directly with ALSA (for academic purposes, I suppose) first.

> 
> either that, or take a look at ecasound's ALSA i/o code, since i think
> that kai implemented that "correctly" also.
> 
> --p
> 
> 
> 
> -------------------------------------------------------
> 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
> Alsa-devel@lists.sourceforge.net
> 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/

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

[Jaroslav Kysela]

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 <perex@suse.cz>
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/

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

[Ryan Cassidy]

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: ryanc@ieee.org
 

> -----Original Message-----
> From: alsa-devel-admin@lists.sourceforge.net [mailto:alsa-devel-
> admin@lists.sourceforge.net] On Behalf Of Jaroslav Kysela
> Sent: Sunday, November 09, 2003 12:38 AM
> To: Ryan Cassidy
> Cc: 'Paul Davis'; alsa-devel@lists.sourceforge.net
> 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 <perex@suse.cz>
> 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
> Alsa-devel@lists.sourceforge.net
> 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/

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

[Jaroslav Kysela]

On Mon, 10 Nov 2003, Ryan Cassidy wrote:

> 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?)?

Sure. It's the standard unix behaviour.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
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/

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

[Paul Davis]

>Many thanks for the info.!

just keep in mind what jaroslav noted about signal handling
context. please don't build a serious application around this
mechanism. sooner or later, you may want to make a system call from
the handler that violates the POSIX guarantees about what can be
done. at that point, you will need to completely reimplement your
code. 

acting as my own devil's advocate, and again echoing what jaroslav
wrote, if you write real-time safe code in the handler, you won't be
making any system calls anyway; at best perhaps a write to a FIFO to
drive some other thread, and write(2) is specifically allowed.

finally, you will still need to implement the full logic of JACK's
internal loop that uses snd_pcm_avail_update() on both streams to
determine how much data space is available. JACK's is arguably a bit
more complex, since it wants to guarantee that clients process equal
size blocks every time for both playback and capture.

--p


-------------------------------------------------------
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/

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

[Ryan Cassidy]

> 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