Subject: Re: [linux-audio-dev] Still I cannot understand why...
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Dec 15 2001 - 18:40:47 EET
>2) Combining JACK and ALSA?
>
>At least in theory it is possible to write an JACK ALSA plugin. It
>would be very tricky to combine the ALSA PCM and JACK APIs, but I think it
>might work. So 'jack_process(frames,buf)' would be replaced by a
>combination of ALSA poll() and snd_pcm_read/write (or mmap commit).
>
>Paul has mentioned the callback-driven design as the cornerstone of JACK,
>but I think synchronous execution of clients is really _the_ key feature.
>Of course, a callback API is more natural way to achieve it, but the
>wait()-then-operate() approach works, too.
yes, of course.
as i mentioned in a recent email however, the difficulty is that the
ALSA poll interface is (necessarily) a bit complex. but it would still
be a huge step to have applications move to this model rather than the
block-on-read/write one that so many do these days.
if we could just people to use this model, that would help the future
out a great deal - it would become much easier to move or wrap the
program flow in such applications into any current or future
synchronously executed system.
>4) The big API debate...
>
>The real _BIG_ question is what audio API should Linux applications use.
>This is a difficult one to say the least. First of all this divides our
>little community to pieces. Paul offers the JACK client API, ALSA people
>want us to use the ALSA PCM API, KDE&GNOME people advocate CSL (Common
>Sound Layer),
the CSL stuff is simply a wrapper around the same old API model. this
is a sample CSL program that reads from /dev/urandom and sends it to
the audio output:
int main (int argc, char **argv)
{
const int size = 1024;
CslDriver *driver;
CslPcmStream *stream;
CslOptions options;
short buffer[size];
int i, j, fd;
options.n_channels = 2;
options.rate = 44100;
options.pcm_format = CSL_PCM_FORMAT_S16_LE;
csl_driver_init (NULL, &driver);
csl_pcm_open_output (driver, "cslpcm1", options.rate, options.n_channels, options.pcm_format, &stream);
fd = open("/dev/urandom", O_RDONLY);
for (i = 0; i < 500; i++)
{
read(fd, buffer, size);
for (j = 0; j < size; j++)
buffer[j] = CLAMP(buffer[j], -4000, 4000);
csl_pcm_write (stream, size, buffer);
}
csl_pcm_close (stream);
csl_driver_shutdown (driver);
return 0;
}
i must confess that i can't see anything here that isn't addressed by
ALSA. given ALSA's impending merger into the kernel, as well as
KDE&GNOME's contentment with telling people they need "libfoo", its
hard for me to see what this offers anyone except for a simplified
configuration call.
I don't care about the details of the API. I don't care if its JACK,
PortAudio, CSL ALSA, OSS, or whatever. What I care about is that the
API supports, nurtures and sustains program design that in turn
facilitates a synchronous execution system. PortAudio is the only
existing API that I know of that really does this, though as you note,
ALSA certainly makes it possible.
> Gstreamer folks might prefer people to write Gstreamer
>components, etc, etc ... These are of course just my assumptions, so I
some of the gstreamer folks seem interested in adding a JACK I/O
module, which would render that part of things mute.
--p
This archive was generated by hypermail 2b28 : Sat Dec 15 2001 - 18:38:29 EET