Re: [linux-audio-dev] Still I cannot understand why...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Dec 15 2001 - 18:38:29 EET