"Paul Davis" <[EMAIL PROTECTED]> wrote: > >So why, having studied the docs, am I completely stumped with jack? It > >refuses to play. I don't consider any solution based on a piece of software > >_I_ can't operate suitable for general use. > > JACK *isn't* intended for general use, and i get tired of suggestions > that it should be. there are lots of people working on solutions for > "general use". JACK is intended for people who are serious about > audio.
I don't understand this attitude. I think it hinders acceptance of JACK (even for serious audio) and it contributes to further fragmentation of the Linux audio world. If you would rather everyday applications not use JACK, what should they be using instead? OSS is simple but limited, and spotty drivers/implementations make it difficult to write robust code. It will soon be available only through emulation. It forces use of the blocking model. ALSA is very powerful and complete, but very complex. This will make for lots of application that "support" ALSA, but badly. Writing in a blocking style is not difficult, but writing in callback style using poll() is basically impossible without studying jack/drivers/alsa/alsa_driver.c for a week. This leaves JACK: easy to program for (provided you know the constraints on the callback's behavoir), uses the callback model, automatically allows for sharing of data between applictions. The only hitch is getting JACK up and running. Writing applications that target JACK will always be a liability if JACK remains a rare and esoteric platform. OSS will be the safe choice, followed by ALSA once Linux 2.6 is in widespread use. Applications that you might find useful even in serious situations might opt to use OSS or ALSA. Take the recent of announcement of the synth ZynAddSubFX, an application that could be a very useful in a JACK pipeline. It was written for OSS. I don't know why Nasca Paul chose the way he did, but it is evident that JACK wasn't compelling to him, even though this is an app that is ideal for use with JACK. I fully understand that crappy consumer interfaces are not going to be able to run JACK with 128 frames per period, but surely any card could handle JACK if you bumped that size high enough. Is there any reason that a particular card/computer could not handle JACK at all, at any period size? I can't imagine why -- JACK is only making ALSA calls. If JACK won't work on a crappy consumer card, does this mean no ALSA app would either? What is the harm in all applications, XMMS up to Ardour, using JACK? I can only see benefits. Josh -- "Only Angels can sing that high, and only dogs can hear it." -- James Evans