[Jack-Devel] stepping down

classic Classic list List threaded Threaded
61 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Markus Seeber
On 01/30/2016 05:13 PM, Paul Davis wrote:
> Sometime in the next two weeks, I will find the time to deal with a variety
> of pull requests for JACK 1, update some articles on jackaudio.org (notably
> FAQ stuff), and do a new release of JACK 1.

Would it be possible to provide old documentation or concept material
about JACK? I have been browsing through some old presentations from
previous LACs and sometimes I find small pieces in the net about JACK
but maybe there is more material that explains the concepts behind JACK?
It does not have to be nicely formatted and fleshed out, but anything
that helps to learn a bit about JACK would be helpful.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Paul Davis
In reply to this post by Kjetil Matheussen-2


On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen <[hidden email]> wrote:



I don't think Jack is the wrong solution for a DAW either. But Jack never got finished.
It has a wonderful API, but it shouldn't be a struggle for a program to create a jack client
if a jack server isn't running. (there were a lot of talk about this around 10 years ago,
but the end result never became as good as it should I think).

i am not sure what the problem is here. if the client doesn't specify anything, then the server will start automatically with the same parameters as it did last time. this has worked for years. no?
 

I think the first program trying to create a client also should start the server. Not
just fork off a process, but actually run the server.
And if another program wants to create a jack client, it connects to the first client process,
which is the one running the server.

this seems a bit odd to me. if the first client is really just a client, why would it become the server? what happens when the user closes it (or otherwise resets it)?

that's the whole point of using a control application that exists before (and almost certainly after) all other clients.
 

Furthermore, GUI should be built into libjack, so that you can call
jack_open_audio_driver_configuration_gui(), jack_open_audio_connection_configuration_gui(),
etc. inside your client.

I know there is something called libjackserver, but how many uses it?

libjackserver isn't what you think it is. you're thinking of the server API, used to start, stop and otherwise control a JACK server. it is the basis of jack2's dbus support, so basically everything using jack2 is using it. it is also present in jack1, and is also used internally there.
 
libjackserver is also used *all* the time.

Does it do
all these things? How stable is it? In my opinion, there shouldn't
be any libjackserver, or jackd program, or qjackctl, only libjack.

this would simply lead *back* to jackd, since lots of people would want a program they could start in order to start jack, that would run before and after other clients. someone would write it, link it to libjack and it would become "jackd".
 

Another problem with Jack is that it never attempted to do consumer audio,
and then we got pulseaudio in addition to Jack. There should only be Jack, IMO.

here we sort of agree.
 


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Joakim Hernberg-2
On Sun, 31 Jan 2016 08:44:42 -0500
Paul Davis <[hidden email]> wrote:

> On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen
> <[hidden email]
> > wrote:
>
> >
> >
> >
> > I don't think Jack is the wrong solution for a DAW either. But Jack
> > never got finished.
> > It has a wonderful API, but it shouldn't be a struggle for a
> > program to create a jack client
> > if a jack server isn't running. (there were a lot of talk about this
> > around 10 years ago,
> > but the end result never became as good as it should I think).
> >
>
> i am not sure what the problem is here. if the client doesn't specify
> anything, then the server will start automatically with the same
> parameters as it did last time. this has worked for years. no?
>
>
> >
> > I think the first program trying to create a client also should
> > start the server. Not
> > just fork off a process, but actually run the server.
> > And if another program wants to create a jack client, it connects
> > to the first client process,
> > which is the one running the server.
> >
>
> this seems a bit odd to me. if the first client is really just a
> client, why would it become the server? what happens when the user
> closes it (or otherwise resets it)?
>
> that's the whole point of using a control application that exists
> before (and almost certainly after) all other clients.
>
>
> >
> > Furthermore, GUI should be built into libjack, so that you can call
> > jack_open_audio_driver_configuration_gui(),
> > jack_open_audio_connection_configuration_gui(),
> > etc. inside your client.
> >
> > I know there is something called libjackserver, but how many uses
> > it?
> >
>
> libjackserver isn't what you think it is. you're thinking of the
> server API, used to start, stop and otherwise control a JACK server.
> it is the basis of jack2's dbus support, so basically everything
> using jack2 is using it. it is also present in jack1, and is also
> used internally there.
>
> libjackserver is also used *all* the time.
>
> Does it do
> > all these things? How stable is it? In my opinion, there shouldn't
> > be any libjackserver, or jackd program, or qjackctl, only libjack.
> >
>
> this would simply lead *back* to jackd, since lots of people would
> want a program they could start in order to start jack, that would
> run before and after other clients. someone would write it, link it
> to libjack and it would become "jackd".
>
>
> >
> > Another problem with Jack is that it never attempted to do consumer
> > audio, and then we got pulseaudio in addition to Jack. There should
> > only be Jack, IMO.
> >
>
> here we sort of agree.

I'll comment as somewhat of a heretic using reaper in wine together
with wineasio/jack.  I have a monolithic environment in that reaper is
the daw, and my plugins are vsts hosted by reaper either in it's own
process or in separate processes (for bridging/sandboxing).  I also
enjoy all the benefits in using jack, being able to record/output
from/to pulseaudio and alsa (mostly using the alsa loopback device in
combination with zita-a2jbridge as it seems to be the best solution).

In addition I can use zita-n2jbridge to distribute audio over my lan,
and even use zita-a2jbridge to connect additional soundcards.  Mostly
features I don't use very often, but very handy to just change output
in reaper and hear my mix on the laptop or tv speakers (with very
low latency)...

When I start reaper, wineasio creates the jack client, the server
autostarts (if not running) and wineasio auto connects the reaper
outputs to the main soundcard outputs.

When rewriting the wineasio client, it was very handy having the jack
api and I suspect that it would have been a lot harder to do if I
had to program using the alsa api instead.

What can I say, I really love the environment and think JACK is working
fantastically well.  Having the plugins hosted in my daw is clearly
superior (imo), but the routing flexibilty of jack and the ease of
programming to the jack api makes jack a great asset in my setup.

As always YMMW.

--

   Joakim
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Christian Schoenebeck
In reply to this post by Paul Davis
On Sunday 31 January 2016 14:44:42 Paul Davis wrote:

> > I don't think Jack is the wrong solution for a DAW either. But Jack never
> > got finished.
> > It has a wonderful API, but it shouldn't be a struggle for a program to
> > create a jack client
> > if a jack server isn't running. (there were a lot of talk about this
> > around 10 years ago,
> > but the end result never became as good as it should I think).
>
> i am not sure what the problem is here. if the client doesn't specify
> anything, then the server will start automatically with the same parameters
> as it did last time. this has worked for years. no?

Well, it worked for many, but it also had confusing aspects for many users, on
Linux at least.

Anyway, IMO many proposed useful features never made into JACK due to
generalization concerns. JACK's general design concept was always "it's just a
server with a set of buffers being passed around, JACK does not know or care
what the content of the buffers is". And this fundamental design barrier was
defended over years, which caused it to age.

Generalization of software is good for developers, but real value for users is
added by adding customizations for the main purpose it is used for. And the
main purpose of JACK is distributing audio signals with audio applications and
audio devices, not distributing RSS feeds between coffee machines. Accordingly
important features for that purpose, like the ability to control the gain
factor of audio connections should IMO be incorporated directly into JACK.

Another internal deficit was the policy how to deal with laggy clients. Which
is quite important for consumer use cases. Instead of simply kicking out a
laggy client from the signal graph it would be better to handle it like
CoreAudio does: that is automatically increasing the latency instead.

CU
Christian
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Joakim Hernberg-2
On Sun, 31 Jan 2016 14:37:13 +0100
Christian Schoenebeck <[hidden email]> wrote:

> Another internal deficit was the policy how to deal with laggy
> clients. Which is quite important for consumer use cases. Instead of
> simply kicking out a laggy client from the signal graph it would be
> better to handle it like CoreAudio does: that is automatically
> increasing the latency instead.

I'm absolutely not a fan of zombifying clients (at least up to a
certain point), but I'd also not be a fan of automagically changing
latencies... IMO it far better to just the client cause xruns and to
let the user deal with the problem himself.

--

   Joakim
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Paul Davis


On Sun, Jan 31, 2016 at 9:42 AM, Joakim Hernberg <[hidden email]> wrote:
On Sun, 31 Jan 2016 14:37:13 +0100
Christian Schoenebeck <[hidden email]> wrote:

> Another internal deficit was the policy how to deal with laggy
> clients. Which is quite important for consumer use cases. Instead of
> simply kicking out a laggy client from the signal graph it would be
> better to handle it like CoreAudio does: that is automatically
> increasing the latency instead.

I'm absolutely not a fan of zombifying clients (at least up to a
certain point), but I'd also not be a fan of automagically changing
latencies... IMO it far better to just the client cause xruns and to
let the user deal with the problem himself.

coreaudio has per-client latency, not just system-wide latency.
 

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Paul Davis
In reply to this post by Christian Schoenebeck


On Sun, Jan 31, 2016 at 8:37 AM, Christian Schoenebeck <[hidden email]> wrote:
On Sunday 31 January 2016 14:44:42 Paul Davis wrote:
> > I don't think Jack is the wrong solution for a DAW either. But Jack never
> > got finished.
> > It has a wonderful API, but it shouldn't be a struggle for a program to
> > create a jack client
> > if a jack server isn't running. (there were a lot of talk about this
> > around 10 years ago,
> > but the end result never became as good as it should I think).
>
> i am not sure what the problem is here. if the client doesn't specify
> anything, then the server will start automatically with the same parameters
> as it did last time. this has worked for years. no?

Well, it worked for many, but it also had confusing aspects for many users, on
Linux at least.

Anyway, IMO many proposed useful features never made into JACK due to
generalization concerns. JACK's general design concept was always "it's just a
server with a set of buffers being passed around, JACK does not know or care
what the content of the buffers is". And this fundamental design barrier was
defended over years, which caused it to age.

i don't think that this isn't accurate.

(1) JACK *has* to know what the data is because it has to (potentially) mix it. this has always been true.
(2) adding new data types to JACK is a relatively simple matter from the perspective of jackd and libjack. It isn't simple for applications/clients, which have to deal with the possibility of ports of "odd" types.

 

Generalization of software is good for developers, but real value for users is
added by adding customizations for the main purpose it is used for. And the
main purpose of JACK is distributing audio signals with audio applications and
audio devices, not distributing RSS feeds between coffee machines. Accordingly
important features for that purpose, like the ability to control the gain
factor of audio connections should IMO be incorporated directly into JACK.

this is VASTLY less important than global latency management. almost every client that writes data to a JACK port has a gain control somewhere in the path that leads to the port, and manages gain for its own reasons. but very few clients (if any) can truly manage latency issues, and i have reversed my original position on this (which used to be that clients should do it).
 

Another internal deficit was the policy how to deal with laggy clients. Which
is quite important for consumer use cases. Instead of simply kicking out a
laggy client from the signal graph it would be better to handle it like
CoreAudio does: that is automatically increasing the latency instead.

given that jack2 (the most widely used implementation) still doesn't have automatic/builtin MIDI bridging, as well as no easy way to use multiple devices, i think that's a much less important issue (particularly since jack2 doesn't kick clients out under almost any circumstances at all.


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Joakim Hernberg-2
In reply to this post by Paul Davis
On Sun, 31 Jan 2016 10:06:16 -0500
Paul Davis <[hidden email]> wrote:

> On Sun, Jan 31, 2016 at 9:42 AM, Joakim Hernberg
> <[hidden email]> wrote:
>
> > On Sun, 31 Jan 2016 14:37:13 +0100
> > Christian Schoenebeck <[hidden email]> wrote:
> >
> > > Another internal deficit was the policy how to deal with laggy
> > > clients. Which is quite important for consumer use cases. Instead
> > > of simply kicking out a laggy client from the signal graph it
> > > would be better to handle it like CoreAudio does: that is
> > > automatically increasing the latency instead.
> >
> > I'm absolutely not a fan of zombifying clients (at least up to a
> > certain point), but I'd also not be a fan of automagically changing
> > latencies... IMO it far better to just the client cause xruns and to
> > let the user deal with the problem himself.
> >
>
> coreaudio has per-client latency, not just system-wide latency.

I guess it's a matter of perspective, but personally I'd also dislike
latencies of a client changing automagically.  I'd still prefer for the
user having to manually change his configuration.

--

   Joakim
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Kjetil Matheussen-2
In reply to this post by Paul Davis


On Sun, Jan 31, 2016 at 2:44 PM, Paul Davis <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen <[hidden email]> wrote:



I don't think Jack is the wrong solution for a DAW either. But Jack never got finished.
It has a wonderful API, but it shouldn't be a struggle for a program to create a jack client
if a jack server isn't running. (there were a lot of talk about this around 10 years ago,
but the end result never became as good as it should I think).

i am not sure what the problem is here. if the client doesn't specify anything, then the server will start automatically with the same parameters as it did last time. this has worked for years. no?
 
 
Well, I've never used it. It doesn't feel safe. There is no obvious place to
check that it does what it's supposed to.


 

I think the first program trying to create a client also should start the server. Not
just fork off a process, but actually run the server.
And if another program wants to create a jack client, it connects to the first client process,
which is the one running the server.

this seems a bit odd to me. if the first client is really just a client, why would it become the server?

If only one program produces sound, why would you also want to start a server?

 
what happens when the user closes it (or otherwise resets it)? 

1. If it is the last client which is about to close, then the server closes as well.
2. If you close the client running the server while other clients are running as well,
then the server must be transferred to another client first, in a glitch-free and
spike-free manner, of course. This functionality would both feel natural
(the user doesn't have to think about the server concept at all), plus that it
would provide an enormous number of fun and interesting programming challenges
for the implementors of that functionality.

 
that's the whole point of using a control application that exists before (and almost certainly after) all other clients.
 


 

Furthermore, GUI should be built into libjack, so that you can call
jack_open_audio_driver_configuration_gui(), jack_open_audio_connection_configuration_gui(),
etc. inside your client.

I know there is something called libjackserver, but how many uses it?

libjackserver isn't what you think it is. you're thinking of the server API, used to start, stop and otherwise control a JACK server. it is the basis of jack2's dbus support, so basically everything using jack2 is using it. it is also present in jack1, and is also used internally there. 
 
libjackserver is also used *all* the time.


Oh right, guess I knew that once though.

 
Does it do
all these things? How stable is it? In my opinion, there shouldn't
be any libjackserver, or jackd program, or qjackctl, only libjack.

this would simply lead *back* to jackd, since lots of people would want a program they could start in order to start jack, that would run before and after other clients. someone would write it, link it to libjack and it would become "jackd".

But my point is that you don't need the jackd program. Every client is also a potential
server (although the user doesn't know this), and since libjack provides functionalities for
configuring jack the same way for all clients, jackd is not needed. This way we can also
create formally specified error messages for the clients. Currently, if something goes
wrong, you have to dig around in the "messages" window in qjackctl, which may contain
some information that could help you make things work. It's really bad actually.



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Paul Davis


On Sun, Jan 31, 2016 at 3:48 PM, Kjetil Matheussen <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 2:44 PM, Paul Davis <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen <[hidden email]> wrote:



I don't think Jack is the wrong solution for a DAW either. But Jack never got finished.
It has a wonderful API, but it shouldn't be a struggle for a program to create a jack client
if a jack server isn't running. (there were a lot of talk about this around 10 years ago,
but the end result never became as good as it should I think).

i am not sure what the problem is here. if the client doesn't specify anything, then the server will start automatically with the same parameters as it did last time. this has worked for years. no?
 
 
Well, I've never used it. It doesn't feel safe. There is no obvious place to
check that it does what it's supposed to.

You're sure of that? Every one of your JACK clients explicitly avoids auto-start?

The mechanism for this is extremely simple and robust. The contents of the file ~/.jackdrc are executed. You can check the result with ps aux or a graphical equivalent.
 


 

I think the first program trying to create a client also should start the server. Not
just fork off a process, but actually run the server.
And if another program wants to create a jack client, it connects to the first client process,
which is the one running the server.

this seems a bit odd to me. if the first client is really just a client, why would it become the server?

If only one program produces sound, why would you also want to start a server?

i can think of lots of reasons. but i don't think it matters.
 

, plus that it
would provide an enormous number of fun and interesting programming challenges
for the implementors of that functionality.

and no effective difference for users over and above the current auto-start scenario.

you also missed out how EVERY single possible JACK client now has to have some way to bring up a server control dialog, that will work no matter what GUI toolkit the client was written with (or no GUI toolkit).

is this supposed to be a serious suggestion?
 

But my point is that you don't need the jackd program. Every client is also a potential
server (although the user doesn't know this), and since libjack provides functionalities for
configuring jack the same way for all clients, jackd is not needed. This way we can also
create formally specified error messages for the clients. Currently, if something goes
wrong, you have to dig around in the "messages" window in qjackctl, which may contain
some information that could help you make things work. It's really bad actually.

a pathway for errors to propagate from server to clients was something discussed in berlin in 2007.



 


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Kjetil Matheussen-2


On Sun, Jan 31, 2016 at 9:59 PM, Paul Davis <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 3:48 PM, Kjetil Matheussen <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 2:44 PM, Paul Davis <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen <[hidden email]> wrote:



I don't think Jack is the wrong solution for a DAW either. But Jack never got finished.
It has a wonderful API, but it shouldn't be a struggle for a program to create a jack client
if a jack server isn't running. (there were a lot of talk about this around 10 years ago,
but the end result never became as good as it should I think).

i am not sure what the problem is here. if the client doesn't specify anything, then the server will start automatically with the same parameters as it did last time. this has worked for years. no?
 
 
Well, I've never used it. It doesn't feel safe. There is no obvious place to
check that it does what it's supposed to.

You're sure of that? Every one of your JACK clients explicitly avoids auto-start?


I think so too, but I meant to say that, as a user, I always start jackd first since I don't want
to risk a client to start jackd in a way I don't feel sure about.


 
The mechanism for this is extremely simple and robust. The contents of the file ~/.jackdrc are executed. You can check the result with ps aux or a graphical equivalent.


It would be better if this information was available in a function in libjack so that
clients can show what's happening.


 

, plus that it
would provide an enormous number of fun and interesting programming challenges
for the implementors of that functionality.

and no effective difference for users over and above the current auto-start scenario.

you also missed out how EVERY single possible JACK client now has to have some way to bring up a server control dialog, that will work no matter what GUI toolkit the client was written with (or no GUI toolkit).

is this supposed to be a serious suggestion?

Yes. First you imagine what would be perfect. Later we can worry about reality.



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Kjetil Matheussen-2
In reply to this post by Paul Davis


On Sun, Jan 31, 2016 at 9:59 PM, Paul Davis <[hidden email]> wrote:

and no effective difference for users over and above the current auto-start scenario.

Another problem with the current auto-start system is that when the client exits, a ghostly
jackd process still continue to live in the system. (Why can't I play any sound on my linux
machine anymore?)


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Paul Davis


On Sun, Jan 31, 2016 at 4:22 PM, Kjetil Matheussen <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 9:59 PM, Paul Davis <[hidden email]> wrote:

and no effective difference for users over and above the current auto-start scenario.

Another problem with the current auto-start system is that when the client exits, a ghostly
jackd process still continue to live in the system. (Why can't I play any sound on my linux
machine anymore?)

Not true if the server was started with the -T flag, which causes it to exit with the last client. This is a user choice.

Jack2's support for this flag was broken for years.
 


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Paul Davis
In reply to this post by Kjetil Matheussen-2


On Sun, Jan 31, 2016 at 4:11 PM, Kjetil Matheussen <[hidden email]> wrote:

I think so too, but I meant to say that, as a user, I always start jackd first since I don't want
to risk a client to start jackd in a way I don't feel sure about.

it starts it the way you started it last time!
 

It would be better if this information was available in a function in libjack so that
clients can show what's happening.

what information?
 

Yes. First you imagine what would be perfect. Later we can worry about reality.

I don't anything perfect about jack_lsp popping up a GUI dialog to configure a server. I don't see anything good about a careful constructed GUI application having to deal with the reality of a new dialog being created. this isn't even close to perfect.

what problem are you actually concerned with fixing? what users does it affect? when?
 


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Michael
In reply to this post by Paul Davis

On 2016-01-31, at 12:59 PM, Paul Davis <[hidden email]> wrote:



On Sun, Jan 31, 2016 at 3:48 PM, Kjetil Matheussen <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 2:44 PM, Paul Davis <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen <[hidden email]>wrote:



I don't think Jack is the wrong solution for a DAW either. But Jack never got finished.
It has a wonderful API, but it shouldn't be a struggle for a program to create a jack client
if a jack server isn't running. (there were a lot of talk about this around 10 years ago,
but the end result never became as good as it should I think).

i am not sure what the problem is here. if the client doesn't specify anything, then the server will start automatically with the same parameters as it did last time. this has worked for years. no?
 
 
Well, I've never used it. It doesn't feel safe. There is no obvious place to
check that it does what it's supposed to.

You're sure of that? Every one of your JACK clients explicitly avoids auto-start?

The mechanism for this is extremely simple and robust. The contents of the file ~/.jackdrc are executed. You can check the result with ps aux or a graphical equivalent.
 


 

I think the first program trying to create a client also should start the server. Not
just fork off a process, but actually run the server. ...

you also missed out how EVERY single possible JACK client now has to have some way to bring up a server control dialog, that will work no matter what GUI toolkit the client was written with (or no GUI toolkit). 

is this supposed to be a serious suggestion?

Another serious problem: Lets say I have a program made by someone that never knew anything about Jack, and is outputting audio to whatever the default system device is. I want that to output to the Jack system. For that to happen, something other than a program that I cannot alter must be able to start up and serve the jack system.

Hence, a server.



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Kjetil Matheussen-2
In reply to this post by Paul Davis


On Sun, Jan 31, 2016 at 10:24 PM, Paul Davis <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 4:11 PM, Kjetil Matheussen <[hidden email]> wrote:

I think so too, but I meant to say that, as a user, I always start jackd first since I don't want
to risk a client to start jackd in a way I don't feel sure about.

it starts it the way you started it last time!
 

It would be better if this information was available in a function in libjack so that
clients can show what's happening.

what information?
 

I meant server options. Driver name, realtime on/off, driver options, timeout, etc.

 

Yes. First you imagine what would be perfect. Later we can worry about reality.

I don't anything perfect about jack_lsp popping up a GUI dialog to configure a server. I don't see anything good about a careful constructed GUI application having to deal with the reality of a new dialog being created. this isn't even close to perfect.


But it's better than having different GUIs in every client for configuring jack.

 
what problem are you actually concerned with fixing? what users does it affect? when?

I think I have listed the problems. The far worst problem is that there
is no proper error response when a driver doesn't start. Especially on Windows,
where qjackctl is quite buggy and portaudio often refuses to start.




_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Paul Davis


On Sun, Jan 31, 2016 at 4:50 PM, Kjetil Matheussen <[hidden email]> wrote:


I meant server options. Driver name, realtime on/off, driver options, timeout, etc.

why does a client want these? it would not contain code to start JACK that required any of this .... unless you're suggesting a different GUI to configure the server in every client, which you're not ...
 


I don't anything perfect about jack_lsp popping up a GUI dialog to configure a server. I don't see anything good about a careful constructed GUI application having to deal with the reality of a new dialog being created. this isn't even close to perfect.


But it's better than having different GUIs in every client for configuring jack.

I am fairly confident that what is better for most users is having a well known point of control (e.g. cadence, qjackctl) to start and control JACK, as well as the capability to start the server from scripts etc.
 

 
what problem are you actually concerned with fixing? what users does it affect? when?

I think I have listed the problems. The far worst problem is that there
is no proper error response when a driver doesn't start. Especially on Windows,
where qjackctl is quite buggy and portaudio often refuses to start.

Qjackctl arranges to catch all output from the server, which is by far the simplest way to present information to the user, especially in a context where the reasons for failure can be incredibly complex. It might not work as well on Windows as it does on *nix platforms, but I hardly think that this would justify some new mechanism to pass failure information between processes. 


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Kjetil Matheussen-2
In reply to this post by Kjetil Matheussen-2


On Sun, Jan 31, 2016 at 10:50 PM, Kjetil Matheussen <[hidden email]> wrote:
 
what problem are you actually concerned with fixing? what users does it affect? when?

I think I have listed the problems. The far worst problem is that there
is no proper error response when a driver doesn't start. Especially on Windows,
where qjackctl is quite buggy and portaudio often refuses to start.


Want to add one more thing: Although the server idea works great on paper,
it doesn't always work fine in practice. I often have to repeatedly write
"killall -9 jackd" in my terminal. It's hard to get right. Better to just throw away
the idea of having a server.


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Paul Davis


On Sun, Jan 31, 2016 at 5:10 PM, Kjetil Matheussen <[hidden email]> wrote:




Want to add one more thing: Although the server idea works great on paper,
it doesn't always work fine in practice. I often have to repeatedly write
"killall -9 jackd" in my terminal. It's hard to get right. Better to just throw away
the idea of having a server.

i haven't seen a single bug report regarding such behaviour. what isn't reported can't get fixed. the only times i have to SIGKILL jackd is when i'm doing code development and i do something deeply screwy.

there will ALWAYS be a server in a system like JACK. if there is code that ends up requiring SIGKILL, then the same code can end up executing inside whatever process is running that code.
 



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Florian Paul Schmidt-2
In reply to this post by Paul Davis


On 01/30/2016 05:13 PM, Paul Davis wrote:

> This will be my last work on JACK. The time has come for me to step down
> from my role as "benign dictator (and jack1 maintainer)". There several
> reasons for this:

JACK is a wonderful project. Thanks to you and all the other great
people that worked on it (and Jack2, too) over the years.

Regards,
Flo
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
1234