22 Oct
2002
22 Oct
'02
8:17 a.m.
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