On Mon, Oct 21, 2002 at 08:51:01 -0700, Joshua Haberman wrote: > 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?
I can't answer this properly, but there is some issue to with mmap mode I believe. It is a very small number of cards that dont work. > What is the harm in all applications, XMMS up to Ardour, using JACK? I can > only see benefits. Its fine, as long as it doesn't alter the design of jack. Theres no point adapting jack to suit the needs of consumer apps if it will increase the latency or make it less stable at low buffer siezes. Thats the reason it exists. There are plenty of alternatives for xmms type things, eg. MAS. It is a good idea (IMHO) for jack to have interface clients to some of these consumer port sharing systems, so you can seamlessly interface between them. Like the alsa interface Taybin mentioned. If you look at the interfaces of things like MAS, ESD and Arts, they are very different to jack. If someone writes an mp3 player, with a callback design and makes it realtime safe then theres no reason it can't be a jack client, c.f. alsplayer. - Steve
