>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