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

[Taybin Rutkin]

On Mon, 21 Oct 2002, Ivica Bukvic wrote:

> of good PRO apps (contrary to your definition of OSS-based "toys" in one
> of your previous e-mails) do not, and will not support it (i.e. RTcmix)
> [either due to fact the apps are not being constantly updated any more,
> or maybe the developers are skeptical about porting to Jack when there
> are so few apps ported into its framework], while a few PRO apps (i.e.
> Ardour) will.

The problem is that OSS and ALSA based programs use the block on
read/write metaphor that kills latency.  That's why they need to be
ported/rewritten to the non-blocking style.  That jack forces the clients
to do so could probably be considered it's greatest contribution.

> fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs.
> gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and
> free. Most of us in Linux strive to make everything work under it both
> hardware-wise and software-wise, as well as being backwards-compatible.
> Yet, in this case if the audio app does not support JACK, then it's

What needs to be done is for someone to implement alsa-server as a jack
client. This has been gone over before, the solution was found
(alsa-server), but no one did it.

> If you really want the JACK to take off, then you should look not only
> forwards, but also backwards, and find a relatively viable solution
> (even if it is at the expense of the latency) that will work with 1000+
> decent apps that have not been ported to JACK framework, thus leaving
> the issue of latency for the user to choose.

If latency is a choice for the user (and often it isn't) then they can
pick their sound server.  Jack is a no-compromise low-latency server.

> Case and point, I may want to use ardour, but if I take a break and want
> to listen to some mp3's on an un-jackified player (such as xmms, for
> instance), how user-friendly would it be to have to save session, close
> ardour, close jackd, and only then start xmms, and then after 10 minutes

This is unnecessary.  I often run xmms and ardour at the same time.  Xmms
doesn't talk to Ardour or Jack, but it doesn't interfere either.  Of
course, I don't hit play while recording or playing in Ardour.

> Neither will the commercial companies want to touch jackd with a 20-foot
> pole if there will be an aura of limited hw it works with (that
> automatically limits a pool of people that may potentially purchase an

But companies write for ASIO.  Certain software needs a promise of
low-latency.

> That's what is wrong with Jack and that's why you are getting so many
> requests to do the obvious. Comments like these only make the situation
> worse. Jack should (and does!) allow for higher latency work so that it
> can accommodate itself to crappier audio hw.

Everything is about tradeoffs.  The important design decision in jack was
to work in lowlatency.  Allowing for higher latency would compromise that
decision.

And that's almost besides the point.  You can have higher latencies.  I
often run with a buffer of 8192.  Horrible latency.  But I never see an
xrun.

> What is yet to be determined is for example why am I getting xruns all
> over the place after having jackd run for 10 minutes even at very high
> buffer sizes and having it sit idle for most of those 10 minutes?

Well, that really depends on your system.  Latency is tricky.  Heck,
digidesign only provides support on certain hardware configurations.

You might want to look at PortAudio also, which has jack as an output.

Taybin
--
http://www.piratesvsninjas.com