Hi Alejandro
Interesting approach ! Thanks a lot for the sharing :)
Do you use Pulse Audio jack plugin and jackdbus ? Or maybe you just
blacklist pulse audio, but in this case, how do you handle OS sounds ?
Regards
Florent
Le 11/06/2021 à 10:03, Alejandro olivan Alvarez a écrit :
Hi!
I've been for several weeks now playing with Rivendell (on Debian) too
... and I faced the same thing as you comment.
I have (IMHO) solved all jackd / root/non-root issues in a way that I
consider the perfect/definitive one: I run jack IN PROMISCUOUS MODE (a
mode designed, although rarely used by the average user, precisely to
allow multi/cross-user client/server inter-operation/sharing, instead
of jackd's default users compartimentalization. In this mode, as long
as any user is on a given, same, POSIX group, declared as env variable
by the user terminal starting Jackd, their jack-client instances are
user-inter-operable with a common/shared jackd server... ), so, to my
understanding, rivendell setup is a perfect use-case for a
promiscuous-mode jackd deployment... here's what I do:
- Create a Systemd unit (jackd.service), that launches jackd in
promiscuous mode for GID XXX (the unit has environment promiscuous
variable set to GID XXX)
- Where XXX is rivendell group (I also assign statically rivendell
user UID XXX)
- To further ensure that promiscuous environment variable present
system wide, I add it to /etc/environment
- I setup jackd.service unit to be run on boot.. so jackd server,
becomes a system-wide service, reachable to anyone in GID XXX
- I MODIFY rivendell.service systemd unit to be launched/depend on
jackd.service unit so it is started AFTER jackd.
- I add root as memeber of group rivendell (GID XXX) , so rivendell
process, owned by root, can connect to jack service
- I add the normal system user that logs in the terminal, to rivendell
group (GID XXX), allowing him ant his jackd clients to connect to
jackd service.
This way, the jackd stuff is totally and completelly user
transparent/traversal ... rivendell connects to jack just as it
starts, NO NEED to configure anything, it just works.
Logged user starts qjackctl and, tada!... it connects automatically
to the already running jackd server (no need to start jackd from
qjackctl!)
Any jackd-client application launched by the user, appears in the
patchbay, and can be connected to/from rivendell (run as root, member
of XXX)... No problems, no issues, no conflicts, everything JUST WORKS
The only little inconvenience here is that, whenever I update
rivendell, the rivendell systemd unit is reinstalled, and I have to
modify it again to make it to 'want' jackd.service.
Hope this helps... If someone is interested on further details on how
to do this, just let me know!
Best regards.
On 6/9/21 7:45 PM, Florent Peyraud wrote:
Hi everyone
I'm currently working on Ubuntu integration of Rivendell, which means
dealing with systemd, pulseaudio and so on...
In order to make caed use pulse alsa plugin, or even jackd, one
solution is to log in as root, which is evil.
The other solution would be to run caed as the logged in user. This
is due to the fact that pulseaudio and jackd daemons are (normally)
only accessible by the same user as the one that launched them. This
is what I tried with this procedure :
---8<---
sudo systemctl edit rivendell
[Service]
User=radio
--->8---
then I start Rivendell with `systemctl start rivendell.service`,
which usually succeed mostly. But caed and/or rdcatchd crash.
I have core dumps but not analyzed it yet. No evidence could be found
in logs. I'll try to dig deeper and let you know if I can find
something but I'm interested in your feedback if you can reproduce it
on another system (centos for instance...).
As far as you know, is there something in rdservice and its children
which definitely need root rights (shared memory or something like
this) ?
Or maybe it could be possible to run rdservice as root, and it could
launch caed as another user ? I think this was done for pypad
components at a certain time (this has been rollbacked IIRC)
Thanks for your feedback
Best Regards
Florent
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
