18 May
2009
18 May
'09
3:17 p.m.
"Ivica Ico Bukvic" <ico(a)vt.edu> writes:
So if I understand this correctly (and please correct
me if I am wrong), we
now have a way to build jack clients which work only with dbus or with
direct access to C API?
We have a way to build jack clients that work over dbus, yes. But only
"control" clients. I.e. like qjackctl. You cant use dbus for audio
(buff/sample leve) stuff. D-Bus is not realtime at all. You dont need
realtime IPC for starting jack server, right? ;)
If so, what happens if an app that has been built to
work with dbus support only (is this even possible?) tries to access jackd
that has no dbus support built-in?
apps access jack server. jack server can be started by jackd or by
jackdbus. jack server is the thing that runs the drivers, that sets the
realtime threads, loads internal clients (netjack2), etc.
If the app has no automatic means of
falling back to the C API access this basically makes jackd as problematic
as the early years of ALSA when apps were unable to work with it because
they only supported OSS...
normal app does not use dbus for this at all. the same IPC between jack
client and jack server is used, regardless of jackd or jackdbus being
used. I.e you use same jack.h API for accessing both jackd and jackdbus
(server), the jack.h implementation in libjack.so is same. With one
exception, the launching of the jack server in the case when it was not
already started and when the "noautostart" option was enabled (env
variable or parameter to the function call). If libjack.so wants to
launch the jack server, it is done differently depending of whether
jackd or jackdbus model is choosen by the packager.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>