[linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]

[Joshua Haberman]

"Paul Davis" <paul at linuxaudiosystems.com> 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