I'm posting new reply on this thread since, to my joy, as of beta4
commit
https://github.com/ElvishArtisan/rivendell/commit/3c4e2bd6d7dda1a730d1d8f6fb6754bb76d1530d
released tonight, the whole picture regarding Rivendell/Jackd
integration in recent systems may very much change for some of us Jackd
fans: Rivendell is coming now with out-of-the-box promiscuous mode
support... yayyyyy!!! :-D
So, it is time now to drop old hackish practices and switch to the
intended/ortodox packaged ones for the jackd integration with
promiscuous mode, which raises me some questions (at this point, I guess
just Fred can answer) about overall how the new picture is:
- Does a rivendell handled jackd instance (defined in RDConfig)
automatically run in promiscuous mode for the 'audio' GID? or has to be
somehow 'enabled'?
- While regular users are already set as 'audio' members (very clever
move selecting audio as the promiscuous GID!), now the package seems to
be handling the environment variable part, pointing to the 'audio' GID,
but... is it system wide? or does user-space launched applications have
to initialize it?
Thank you very much for such a new feature!
Best regards.
On 12/1/21 10:27 AM, Florent Peyraud wrote:
Hi everyone.
I'm trying to streamline the integration of Rivendell 4 on lubuntu or
other debian based distros using modern tools such as systemd and
DBus. Now, qjackctl and the packages jackd2 uses Dbus to launch jack
daemon by default. This provides some cool features, notably the
handshaking with pulseaudio in order to release the alsa device from
pulse and let jack use it instead, and also the automatic connection
of pulseaudio into jack as a client.
The way qjackctl launches jack is by issuing the "/usr/bin/jackdbus
auto", then setups and actually starts jack through the DBUS interface
with /usr/bin/jack_control
I would like to mimic this behavior in order to make rivendell service
(well... caed) start Jack this way with an external scirpt, but it
fails when trying to connect jack. The logfile says "Unable to
communicate with JACK server". Obviously, the actual jack server may
take too much time to launch and it is not ready when caed tries to
connect. DBus provides a way to check the status of jack. Maybe just a
pause could be sufficient to allow jack to start before trying to
connect to it.
Would it be possible to take this way of launching jack through DBus
into account so that it can be started at boot time with caed instead
of waiting for a user session to begin ?
By the way, I tweaked systemd service for rivendell (sudo systemctl
edit rivendell) in order to start the daemons with another user
(actually the user who starts the session afterwards to use Rivendell
tools) so that I can launch qjackctl or other tools with this user and
modify the patching of clients without being forced to connect as
root, which is not recommended on ubuntu/debian. Maybe, it could be
useful to be able to select the user for each sub-service in rd.conf,
and drop privileges while starting rivendell service according to this.
Thanks a lot for your answers/ideas. Take care
Florent
_______________________________________________
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
_______________________________________________
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
