6 Jan
2010
6 Jan
'10
9:24 a.m.
Adrian Knoth wrote:
On Fri, Dec 25, 2009 at 05:16:22PM +0100, Ralf Mardorf
wrote:
Hi,
The development version of Qjackctl seems to have (partial) jackdbus
support now. I have jackd (--classic) and jackdbus (--dbus) on my system
without big problems. The only problem you can get it when you stop an
certain 'studio' in Ladish, some apps seems to autolaunch jackd, and a
running jackd prevents jackdbus to be started. I suggested the Ladish
developers to implement some kind of mechanism which tracks if jackd is
running when jackdbus/ladish can't be started.
But I suggest you to enable both --classic and --dbus for Debian, along
with the latest qjackctl with jackdbus support, so people can use jackd
and jackdbus.
\r
but for Suse and Debian based distros JACK2
can't be simply compiled
and installed while the package or all files of the package aren't
removed,
There's jack2 in Debian experimental, and you're free to download the
package source:
http://packages.debian.org/source/experimental/jack-audio-connection-kit
You then say dpkg-source -x *.dsc and run debuild in the directory. Feel
free to modify debian/rules, so you can add all the flags that you want.
I've disabled the jackdbus package at the moment, because I have yet to
try it myself and get the big picture. (to be honest, I'm not entirely
sure there's consensus about jackdbus, but I don't want to re-start this
lengthy discussion again)
Oops, right now I noticed that there's a
package called "jackdbus" for
Which is empty, as you've already shown. That was one of the reasons why
I've disabled it for now in the experimental package.
I must confess I know almost nothing about jackdbus. All I know is that
it can talk to pulseaudio to get the soundcard back, which, on the other
hand, is completely unimportant to usual studio setups where you have a
cheap (mainboard) system card and the real, unused recording card.
Given that it's unused, I don't have to ask anybody about releasing it,
so simply starting jackd does the trick.
Feel free to educate me. ;)
PS: For the occasional jackd-on-my-builtin-laptop-card-user, it would be
sufficient to run jackd *on top* of pulseaudio and no cards are handed
over back and forth. Latency on these chips is crap anyway, real work
beyond tweaking some volume curves isn't done, so it's all about running
jackd *somehow* to get the inter-app-routing. I suggest to add a PA
backend for jackd, that is, jackd -d pulse.
Steinberg does this on Win32, you can run your Cubase with poor latency
on top of the ordinary D3D- or MME API. Though nobody would ever use
this for recording or any other decent work, it gives you the chance of
running the app, make small changes and export a mixdown. That's roughly
the level one could expect from a builtin soundcard, for everything
else, additional audio gear would be used.
I think pleasing the desktop user who insists to run jackd on his el
cheapo card could be achieved with this jack-on-PA approach. This would
remove the need for passing access to sound hardware between PA and
jackd.
Just my €0.02