Hi!... OK... I'll do my best to keep this as concise as possible...if
necessary, we could go deeper afterwards if needed-
Starting at some Ubuntu (I'm using Debian) install instructions I
initially used as reference, lets consider rivendell system user is
'rivendell' , with UID/GID 150.... I will create a X11 regular
system/pam user 'operator' that will use the rivendell terminal:
- 1st:
adduser --uid 150 --system --group --home=/var/snd rivendell
chgrp rivendell /var/snd
chmod g+w /var/snd
- and:
useradd -m -g rivendell -s /bin/bash -p $(openssl passwd -crypt
VERYSECRET) operator
adduser operator audio
adduser operator dialout
adduser operator sudo
- At this point, I'm doing something that I think is not necessary, I've
still not tested/confirmed this point, but I'm not 'fine tuning'
Rivendell install at this point (I'm just learning how to use it at its
very limits/capabilities). Essentially I will setup, system-wide, the
necessary environment variable to ensure that, any terminal, virtual or
interactive, spawned by any user, belonging to GID 150 (rivendell) will
'participate' on the promiscuous Jackd 'party':
echo "JACK_PROMISCUOUS_SERVER=150" >> /etc/environment
- Now I will setup a systemd unit that will take care of providen a
system service consisting on a 'root-driven-but-GID150-promiscuous'
jackd instance. **NOTICE my unit is commented/templated so jackd can be
setup against either a dummy card, or to a real ALSA interface. For the
sake of example, I've let the card-independant dummy one, so a cut/paste
of this unit will work.
Here's the contents of /etc/systemd/system/jackd.service
[Unit]
Description=Start the JACK server in promiscuous mode for GID 150
After=sound.target
StartLimitBurst=5
StartLimitIntervalSec=33
[Service]
Type=simple
Environment="JACK_PROMISCUOUS_SERVER=150"
UMask=0
# For ALSA device binding running mode:
#Environment="JACK_NO_AUDIO_RESERVATION=1"
#ExecStart=/usr/bin/jackd -R -d alsa -d hw:????? [-r 48000] [-M] [-H]
# For a floating/independent jackd running mode:
ExecStart=/usr/bin/jackd -R --name default -d dummy -r 48000 -C 2 -P 2
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
- At this point, I have to tweak the rivendell Unit:
It must have to be launched wit proper Environment variable to it joins
the promiscuous Jackd party.
sed -i '/^Type=.*/a Environment="JACK_PROMISCUOUS_SERVER=150"'
/lib/systemd/system/rivendell.service
I want it to start after the jackd.service **NOTE: this last part, I
think, can be further enhanced, I've not tested enough, but I think a
bether systemd units inter-dependency can be achieved than just 'After' .
sed -i -e '/After/s/$/ jackd.service/' /lib/systemd/system/rivendell.service
- Finally, reload systemd and enable those services:
systemctl daemon-reload
systemctl enable jackd.service
systemctl enable rivendell.service
At this point, upon reboot, user 'operator' logs in, and launches
qjackctl...what SHOULD happen:
- qjackctl instantly recognices and binds to the system-wide,
already-running jackd instance.. NO NEED to start jack
- In patchbay/connections, rivendell should appear (connected to jack)
and, although ran by root, its inputs /outputs connections can be freely
managed
- Any rivendell restart, will result in instantaneous jackd
re-connecting to the system-wide jackd.
- Any jack client application launched by 'operator' binds to jackd
(jamin, glassplayer, glasscoder, linphone...) and, even being run by
'operador', its in/outs can be freely connected/disconnected to/from
rivendell
- Therefore, a patchbay config can be setup and enabled in qjackctl,
100% GUI, to automate connections, no need to program/script jackd
connections, the user is free to operate the thing on his own.
- The user can use Jacktrip GUI to send audio in/from rivendell
instances, in separate workstations, over LAN/WAN very easily
Hope this works on other systems as does in my Debian Buster/Stable
experiments... but it may be helpful anyways... also, as I mentioned,
I'm aware all this could be further enhanced/fine-tuned
Best regards.
On 6/11/21 2:00 PM, Chester Graham wrote:
I would very much like to see more details on how to set this up. I am
using the standard configuration on Centos 7.
Chester
On Fri, Jun 11, 2021 at 4:03 AM Alejandro olivan Alvarez
<[email protected]
<mailto:[email protected]>> wrote:
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]
<mailto:[email protected]>
> http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
<http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev>
_______________________________________________
Rivendell-dev mailing list
[email protected]
<mailto:[email protected]>
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
<http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev>
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
