Re: [RDD] jackd2 and DBUS

2021-12-02 Thread Fred Gleason 
On Dec 1, 2021, at 04:27, Florent Peyraud  wrote:

> 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.

Interesting idea. What would be the advantages of this approach over the 
existing method of starting jackd(1) by having caed(8) fork() a process?


> 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 ?

We can already do this in the existing implementation.

Cheers!


|-|
| Frederick F. Gleason, Jr. | Chief Developer |
|   | Paravel Systems |
|-|
| A room without books is like a body without a soul. |
| |
| -- Cicero   |
|-|___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] jackd2 and DBUS

2021-12-02 Thread Fred Gleason 
On Dec 2, 2021, at 08:25, Florent Peyraud  wrote:

> unfortunately, either promiscuous mode in jack or system-wide daemon in 
> pulse-audio are configurations not recommended nor supported. And as I'm 
> trying to provide a solution for average users and rivendell administrators, 
> who are not necessarily system administrators, I would like to avoid as much 
> as possible unsupported or not recommended solutions. Moreover, since it 
> deals with shared memory, relaxing permissions on such files may introduce 
> security flaws.

Well, it all depends on your use case. But first, the low-hanging fruit: 
PulseAudio.

The use case for which PulseAudio was designed is ‘general desktops’ —i.e. 
playing the various beeps, boops and other sound effects generated by a GUI in 
the course of its normal operation when running typical ‘office automation’ 
type applications (web browsers, word processors, etc). As such, it has no 
place on a system designed to handle pro audio. It’s one of the first things I 
typically disable on any new Rivendell system.

As for JACK’s promiscuous mode, I’m not quite sure what you mean by calling it 
‘unsupported’. It’s present in the stock tarballs and binary downloads 
available at the canonical JACK GitHub site, so it’s certainly ’supported’ by 
the primary JACK developers. Whether its use is *appropriate* in a given 
situation is a matter of professional judgement. Does it open new avenues by 
which a system could be compromised in some way? Sure. So does giving a user an 
account on the system. So does turning on the power on the computer in the 
first place. I think the more relevant question to ask is: does it provide 
additional capabilities sufficient to justify the additional risk? The standard 
security principle of ‘least privilege’ holds that a user should have no more 
power on a system than the minimum necessary to do their required tasks. Given 
that Rivendell's previous, “non-promiscuous mode” JACK setup required that 
users run all JACK audio applications as ‘root’, I have to imagine that this 
change makes for a vastly improved security posture in general.


> By the way, I could not find a way to start Jackd in promiscuous mode through 
> dbus. If you have any clue, I would be pleased to test it

Unfortunately, the only way I’ve found to enable it is to define a 
$JACK_PROMISCUOUS_SERVER variable in the environment and then export that to 
jackd(1) as well as every audio application that will be using it. There are a 
number of drawbacks to this approach, the primary one in Rivendell’s case being 
that there is no easy way to give the feature a convenient user-facing ON/OFF 
switch (with, say, a checkbox in RDAdmin). Instead, it’s got to be baked-in to 
a number of static configuration files on the system. There are various values 
that can be given to that environmental variable that influence how it works; 
see the ENVIRONMENT section of the jackd(1) man page for specifics. AFAICT, 
there is no way to enable/disable it via dbus.

Cheers!


|-|
| Frederick F. Gleason, Jr. | Chief Developer |
|   | Paravel Systems |
|-|
|   Liberty is always dangerous, but it is the safest thing we have.  |
| |
|  -- Harry Emerson Fosdick   |
|-|___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] jackd2 and DBUS

2021-12-02 Thread Fred Gleason 
On Dec 2, 2021, at 05:20, Alejandro olivan Alvarez 
 wrote:

> 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...  yay!!! :-D

Wow Alejandro, that was fast! I committed that to Git less than an hour ago.  :)


> 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?

First off, let’s be clear that the changes we’re talking about here apply to 
Rivendell 4.x ONLY. Previous Rivendell versions (v3.x and earlier) are NOT 
affected.

That said, Rivendell v4.x packages now define a ‘magic’ environmental variable 
($JACK_PROMISCUOUS_SERVER) that causes the JACK subsystem to relax the ‘all 
clients must be run under the same user as the server’ requirement, thus 
eliminating the need to run non-Rivendell audio apps as the ‘root’ user. With 
two caveats (see below), this should ‘just work’, with no other special 
configuration needed.

Caveat 1: The version of the JACK server installed by default by the standard 
Rivendell CentOS 7 installer (jack2-1.9.9.5) does *not* support promiscuous 
mode, so you will need to update that component in order to make use of this 
capability. Fortunately, that’s easy to do. Just get a root shell and run the 
command:

yum update jack2

Caveat 2: When I mentioned ‘Rivendell v4.x packages’ above, I was being very 
specific: Rivendell installations that are done by package managers (yum, dpkg, 
apt, etc) do everything automatically. However, users who are installing 
directly from source (such as those currently testing recent code changes in 
Git) will need to do an extra step: after doing ‘make install’, you’ll need to 
copy a small configuration file from ‘conf/rivendell-env.conf’ in the source 
tree to the ‘/etc/profile.d/‘ directory. This only needs to be done once.


> Thank you very much for such a new feature!

You’re welcome!

Cheers!


|-|
| Frederick F. Gleason, Jr. | Chief Developer |
|   | Paravel Systems |
|-|
| Never give in. Never stop. Fix bugs. Add features. Iterate. To the  |
| end of time. For real? Yeah. For real.  |
| |
|   -- Daniel Stenberg|
|   Stackoverflow post, 28 April 2019 |
|-|


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] jackd2 and DBUS

2021-12-02 Thread Alejandro olivan Alvarez 

On 12/2/21 2:25 PM, Florent Peyraud wrote:

Hello !

I've just realized I didn't click on "send" button yesterday night, 
and since then, thins may have changed with v4.0.0beta4 ;) 
Hi! yep... now its me I'm waiting to learn about the orthodox 
rivendell-ish way to have the right integration! :-)

Never mind, I post it like this, hoping this is still relevant :)

Le 01/12/2021 à 10:43, Alejandro olivan Alvarez a écrit :



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


The way I do works just like a charm to me, where everything 
integrates an inter-operates to perfection: I'm using the jackd2 
PROMISCUOUS MODE feature to create a single, system-wide, 
user-interoperable, jackd service, that act as a hub to any jack 
client, of any user (thus Rivendell) on the whole system, allowing 
each user (the workstation user) to manage their GUI clients and/or 
applications using GUI tools and send/get audio to/from any other 
audio clients on the system.


In this mode, Rivendell automatically connects to the system-wide 
jackd server.


In the same way, qjackctl (or any other GUI applications, jack 
manager/client, etc... for instance, I use Ardour as Rivendell's 
mixer, and jamin as DSP) by means of X11/dbus does automatically 
detect and bind to the system-wide, shared, running jackd server... 
automatically.


I had posted specific setup details (Debian) before in this list if 
you're interested on.


Best regards.


Hi Alejandro

Thanks for your answer. I remember this discussion we used to have 
together ;)


I just had a look on it and as you said, you are an advanced user, 
system programmer, and don't rely necessarily on distros sound stack 
(pulse, dbus), which is perfectly fine in your case. The promiscuous 
mode also exist for pulse audio (well, a kind of promiscuous mode) in 
order to have a system wide daemon running.


unfortunately, either promiscuous mode in jack or system-wide daemon 
in pulse-audio are configurations not recommended nor supported. And 
as I'm trying to provide a solution for average users and rivendell 
administrators, who are not necessarily system administrators, I would 
like to avoid as much as possible unsupported or not recommended 
solutions. Moreover, since it deals with shared memory, relaxing 
permissions on such files may introduce security flaws.


By the way, I could not find a way to start Jackd in promiscuous mode 
through dbus. If you have any clue, I would be pleased to test it


Thanks and regards

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

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] jackd2 and DBUS

2021-12-02 Thread Florent Peyraud 

Hello !

I've just realized I didn't click on "send" button yesterday night, and 
since then, thins may have changed with v4.0.0beta4 ;) Never mind, I 
post it like this, hoping this is still relevant :)


Le 01/12/2021 à 10:43, Alejandro olivan Alvarez a écrit :



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


The way I do works just like a charm to me, where everything 
integrates an inter-operates to perfection: I'm using the jackd2 
PROMISCUOUS MODE feature to create a single, system-wide, 
user-interoperable, jackd service, that act as a hub to any jack 
client, of any user (thus Rivendell) on the whole system, allowing 
each user (the workstation user) to manage their GUI clients and/or 
applications using GUI tools and send/get audio to/from any other 
audio clients on the system.


In this mode, Rivendell automatically connects to the system-wide 
jackd server.


In the same way, qjackctl (or any other GUI applications, jack 
manager/client, etc... for instance, I use Ardour as Rivendell's 
mixer, and jamin as DSP) by means of X11/dbus does automatically 
detect and bind to the system-wide, shared, running jackd server... 
automatically.


I had posted specific setup details (Debian) before in this list if 
you're interested on.


Best regards.


Hi Alejandro

Thanks for your answer. I remember this discussion we used to have 
together ;)


I just had a look on it and as you said, you are an advanced user, 
system programmer, and don't rely necessarily on distros sound stack 
(pulse, dbus), which is perfectly fine in your case. The promiscuous 
mode also exist for pulse audio (well, a kind of promiscuous mode) in 
order to have a system wide daemon running.


unfortunately, either promiscuous mode in jack or system-wide daemon in 
pulse-audio are configurations not recommended nor supported. And as I'm 
trying to provide a solution for average users and rivendell 
administrators, who are not necessarily system administrators, I would 
like to avoid as much as possible unsupported or not recommended 
solutions. Moreover, since it deals with shared memory, relaxing 
permissions on such files may introduce security flaws.


By the way, I could not find a way to start Jackd in promiscuous mode 
through dbus. If you have any clue, I would be pleased to test it


Thanks and regards

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

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] jackd2 and DBUS

2021-12-02 Thread Alejandro olivan Alvarez 
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...  yay!!! :-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