Re: [linux-audio-dev] jack and alsa design issue

>I'm writing an application that will use alsa in the common case, but be
>jack-capable. I'm faced with the following design question: Do I wrap
>the jack part to emulate the read/write of alsa, or do I wrap the alsa
>part to emulate the callback style of jack? In other words, do I push or
>pull from the audio segment of the program?
>
>As I understand it, alsa can be asynchronous but it requires using SIGIO
>which doesn't excite me. So I'd have to create another thread that
>selects and fills a ringbuffer.
>
>To adapt jack, I'd have a ringbuffer which is drained when the program
>pulls the audio.
>
>Adapting Jack seems the easier thing to do, but what do you think?

if your app is supposed to be a realtime audio app, then a callback
driven model is almost demonstrably more correct. SIGIO is not
appropriate for this. you would be better taking the same design that
JACK itself uses to interact with ALSA, and wrapping that as your ALSA
interface. Its also far from clear of the worth of a native ALSA
interface for most programs, though perhaps yours is an exception. If
there is any reason why the user might want to feed the output of
another program into yours (or vice versa), why confuse them with two
different I/O model options?

also, there is already a library that can convert a blocking
read/write app into a JACK client. xmms-jack uses it, i regret that i
forget its name. there is a link on the JACK site on the apps
page. Might be bio2jack. it adds latency to the app that uses it, but
it does work. There is another solution along the same lines, but less
invasive. I forget its name.

--p
Received on Fri Mar 18 20:15:13 2005