Re: [RDD] jackd2 and DBUS

2021-12-03 Thread Florent Peyraud 


Le 03/12/2021 à 15:59, Fred Gleason a écrit :
On Dec 3, 2021, at 05:41, Florent Peyraud > wrote:



Do you have a target date for the final 4.0.0 release ?


2022Q1 is the current goal, but, in the words of a TV commercial 
widely aired in the US in the 1970s: “We sell no wine before its time.”
It this is the price for the quality... I hope we can help in getting 
this "2022Q1" to be "Early 2022Q1"


Yes, I’m THAT old…  :)


like good wines ;)

Regards

Florent

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

Re: [RDD] jackd2 and DBUS

2021-12-03 Thread Fred Gleason 
On Dec 3, 2021, at 05:41, Florent Peyraud  wrote:

> Do you have a target date for the final 4.0.0 release ?

2022Q1 is the current goal, but, in the words of a TV commercial widely aired 
in the US in the 1970s: “We sell no wine before its time.”

Yes, I’m THAT old…  :)

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-03 Thread Fred Gleason 
On Dec 3, 2021, at 05:41, Florent Peyraud  wrote:

> Well. "unsupported' may not be the correct term. I've read some ML posts 
> talking about this options not being supported, but probably they meant it 
> did not represent the most widely used configuration.

That’s certainly true in the JACK developer community, where promiscuous mode 
is regarded as a rather exotic, rarely used feature. It makes sense when you 
remember that the original (and still overwhelmingly most common) use case for 
JACK is what I call the “recording studio” workflow. A recording engineer comes 
in in the morning, fires up the gear for today’s session, starts up the various 
apps, hooks up all the signal flows, etc. The musicians arrive, set up all of 
their kit, check everything out. The session recording gets done. Then, 
everybody tears everything down and goes home for the night. Tomorrow, repeat. 
Etc. In that context, the same-user-does-everything rule makes perfect sense.

Rivendell’s use case is extremely different. There, we want JACK to be a 
system-wide service, that starts when the computer boots up and then runs 
continuously (sometimes for MONTHS or longer), just doing its job in the 
background, taking care of all users. This is definitely a niche use case from 
JACK’s POV.

Cheers!


|-|
| Frederick F. Gleason, Jr. | Chief Developer |
|   | Paravel Systems |
|-|
| Everything in war is very simple. But the simplest thing is |
| difficult.  |
| |
| -- Carl von Clauswitz   |
| "On War"|
|-|___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] jackd2 and DBUS

2021-12-03 Thread Alejandro olivan Alvarez 


On 12/3/21 11:41 AM, Florent Peyraud wrote:


Hi Fred !

Le 02/12/2021 à 22:43, Fred Gleason a écrit :
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.


Well, I agree with you, it depends on the use case : Most of my 
customers are community radio stations. The computers they use are 
multi purpose. They can be used for office suites as well as sound 
editing with audacity as well as browsing the web, or use rdlibrary to 
encode carts. For them, it is quite common to have only the 
motherboard integrated sound card, and it is hard to cope with this 
device being exclusively used by caed with an alsa setup. They DO need 
to be able to listen to songs on the net, then integrate them in 
Rivendell and set markers in rdlibrary, all in the same session. For 
them, having a sound daemon in between allowing concurrent access to 
the sound device is a must. And sometimes, programs does not know how 
to speak JACK protocol, but they know how to speak alsa/pulseaudio 
language.


Hi, here I dare to add that, in my own experience (because often I do 
test in my own laptop) that's what I'm usually doing by combining two 
pieces:


Jackd in promiscuous mode is one of the pieces... because then, I can 
bridge my user-space jackd apps to and from Rivendell ... but still, I 
need to have a sound card for 'regular' apps.


Here comes the second part, my solution (no pulse audio here) is to 
start jackd against the laptop sound card (and not a dummy interface, as 
I do in my mockup Rivendell terminals), AND setup an ALSA-to-JACK bridge 
configuration (it is documented around in internet, it is done through 
an .asoundrc file that adds user-overrides to ALSA config). This second 
piece includes setting as ALSA's default audio interface the 
ALSA-to-JACK bridge virtual interface. This way, any non-jack-aware apps 
will happily play audio to jackd fully unaware/transparently :-)


The only caveat for this approach is that, for sound cards that do 
feature sub-devices (such ASI cards) jack only gets the physical 
ins/outs of first subdevice... but this is fine for an integrated 
mobo/laptop sound card.


With pulse audio (I don't use it) in theory all this should happen 
(AFAIK) automagically...


I could share my .asoundrc config file for alsa-to-jack bridge (also, 
that may need extra packages installed)


Cheers.

I agree, rivendell exclusive access to the sound device is also the 
way I usually sets rdairplay dedicated machines up, but it is less and 
less common for my customers to have this kind of dedicated machine.


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.
Well. "unsupported' may not be the correct term. I've read some ML 
posts talking about this options not being supported, but probably 
they meant it did not represent the most widely used configuration. On 
the security matter, I agree with you, there is a trade-off to find, 
and after looking more closely to the

Re: [RDD] jackd2 and DBUS

2021-12-03 Thread Florent Peyraud 

Hi Fred !

Le 02/12/2021 à 22:43, Fred Gleason a écrit :
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.


Well, I agree with you, it depends on the use case : Most of my 
customers are community radio stations. The computers they use are multi 
purpose. They can be used for office suites as well as sound editing 
with audacity as well as browsing the web, or use rdlibrary to encode 
carts. For them, it is quite common to have only the motherboard 
integrated sound card, and it is hard to cope with this device being 
exclusively used by caed with an alsa setup. They DO need to be able to 
listen to songs on the net, then integrate them in Rivendell and set 
markers in rdlibrary, all in the same session. For them, having a sound 
daemon in between allowing concurrent access to the sound device is a 
must. And sometimes, programs does not know how to speak JACK protocol, 
but they know how to speak alsa/pulseaudio language.


I agree, rivendell exclusive access to the sound device is also the way 
I usually sets rdairplay dedicated machines up, but it is less and less 
common for my customers to have this kind of dedicated machine.


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.
Well. "unsupported' may not be the correct term. I've read some ML posts 
talking about this options not being supported, but probably they meant 
it did not represent the most widely used configuration. On the security 
matter, I agree with you, there is a trade-off to find, and after 
looking more closely to the JACK_PROMISCUOUS_SERVER option usage, the 
group limitation could be an acceptable trade-off.
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.


I had a look on your commit and saw the nice way you set the variable 
for both the daemon and the user session. It should allow launching jack 
from caed or as a standalone daemon launched on its own (before caed). 
I'll give a try with it. It may be the trade-off between having a full 
DBus dynamically configured system and a strictly static setup. Thanks a 
lot :)


Do you have a target date for the final 4.0.0 release ?

Best

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

Re: [RDD] jackd2 and DBUS

2021-12-01 Thread Alejandro olivan Alvarez 



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.



___
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

[RDD] jackd2 and DBUS

2021-12-01 Thread Florent Peyraud 

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