Bugzilla Bug 12527

http://jackit.sourceforge.net/

The jack-audio-connection-kit is a low latency audio server
that is supported by many current tools, and more to come.
Not everyone needs support for it, but those who require synchronous
execution of clients and low latency for audio production
or performance require it. Please add it.

Paul

USE flag issues over to me please, martin

I personally don't think we need to put a use variable in for jack (yet?).  If 
a program is designed to utilize jack, i have most often seen it only as a 
requirement or "you'd be stupid not to put in this option" and not an 
optional/experimental component.  

Hi Nick;

I am not using jack now. So, it seems ugly to make me build it,
and build support for it into all my audio tools. Particularly
as if you want jack stuff, you probably need a CVS build. Some
things require it, but not every editor/tracker/synth/disk recorder/etc,
though they may support it. It seemed to me more analogous to esd/arts/
alsa in the build I was working on (ecasound) as far as USE goes.
I feel a little awkward trying to argue this because I _dont_ have
jack experience, or really much non-trivial audio experience.
I think jack is pretty small, though, so I dont care too much, as long as
the stuff builds--

Paul

ardour-cvs requires jack-cvs
ecasound works with virtual/jack (either cvs or the "release" jack)
qjackconnect is written for jack...

In the professional audio world jack is becoming more and more useful and audio software authors have been integrating it more and more into "suggested/required* area instead of the *optional* area...  For now I am going to stand behind my belief of jack use variable not being needed.  If there is performance hits due to adding of the jack functionality and/or space constraints created by having it installed I would consider the flag.  But as it stands right now, if you are installing a program which supports jack right now in portage, you want it included and we even now have logic to allow you to have the cvs version installed so you can experiment with bleeding edge audio programs.

I'm fine with this. If in the future many more apps start to support JACK, we
might want to come back and reconsider this decision. Not everyone will need, or
want, JACK support in all apps, probably the limited few who are experimenting
with audio production.

You seem to forget one thing...
JACK support _can_ be absolutely optional!

Thanks to Guenter Geiger's libjackasyn It's relatively simple to "jackify" 
OSS sound apps with a fairly small patch either using the LD_PRELOAD 
method or by manually replacing open/close/write/ioctl calls whith jackoss_* calls.

No normal user would want jack support in OSS apps, unless he wants to
have jack on his system.
Not to speak of a dependency on jackd up and running (in case LD_PRELOAD 
doesn't work).

I've got several jack related ebuilds in my local portage overlay. Some of
those require a jack USE flag, because of the problems mentioned above.
However, I don't think they qualify for inclusion into gentoo unless a jack USE
flag is added.

Regards,

Rene

PS: Why is this marked as FIXED?

There are more and more Jack'ed apps turning up in my queue these days. In a
proportion, the jack support is disabled by default.

This basically means i have two choices:

i) enable jack - forcing people who don't use jack to emerge it

ii) disable jack - forcing people who do use jack to edit / customize the
ebuild

Long term, i expect this will get worse (as more apps add preliminary jack
support) and then better as it matures and is turned on by default.

In the meantime i think we need a jack USE flag.

Spoke too seemant on irc today. Have his permission to add this. Will do so
over the weekend. Will take a while to get all the ebuilds using it...

commited. please open new bugs for ebuilds that need this use flag.