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.
