"Ivica Ico Bukvic" <ico@xxxxxx> 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>
Attachment:
pgp7kVtdlCkla.pgp
Description: PGP signature
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
