30 Jan
2016
30 Jan
'16
9:13 a.m.
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.
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:
* most linux distributions use JACK2 as their default, so JACK1's
relevance has diminished. I
still believe JACK1 to be a superior choice from some technical
perspectives, but there is
no doubt that JACK2's integration with dbus and thus its
interoperability with PulseAudio
has made this the safe and simpler choice for Linux.
* I really don't have the time to even think about things related to JACK
these days. It does
any future development a disservice to have me as the bottleneck, which
I effectively am
at the moment.
* Because 110% of my time is spent on Ardour, the fact that Ardour now has
non-JACK
audio/MIDI I/O options has diminished the significance of JACK for my
own work.
* as the years have gone on, although I am still delighted by the
technical quality and
the conception of JACK, I no longer think that it is a particularly good
idea for most users. There
are times when it is useful
I will continue to pay for the hosting of jackaudio.org (even though JACK2
continues to be distributed, managed and communicated about via other
channels), although if someone wanted to migrate this to some other more
communitarian platform, we could look into that.
I would be happy if someone volunteered to step up as maintainer of JACK1.
It would obviously be even better if someone was willing to take the big
leap to JACK3, a version that combines all the best parts of JACK1 and
JACK2, but I think it is more realistic to accept at this point that this
is not going to happen.
If nobody does step up, then there is a good chance that JACK1 will become
officially unmaintained. This isn't of much consequence, because once the
latest pull requests are merged, there won't be any known bugs in the code,
and also because not many people use it anymore. This also means, of
course, that "maintainer" is not much of a task, should someone feel
hesitant about taking it on.
--p
30 Jan
30 Jan
9:39 a.m.
On Sat, 30 Jan 2016 11:13:06 -0500
Paul Davis <paul(a)linuxaudiosystems.com> 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:
Sorry to hear about that (as a jack1 user). I thank you for all your
work and wish you all the best with future endeavors!
--
Joakim
10:04 a.m.
On 30.01.2016 17:13, 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 <http://jackaudio.org> (notably FAQ stuff), and do a new
release of JACK 1.
Great!
Does this include the latest patch from Fons too?
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)".
Can't say I'm surprised.
JACK development has been slowly decreasing in activity.
We have working meta-data in jack1 now at least, thanks for that!
I would be happy if someone volunteered to step up as
maintainer of JACK1.
I'd be happy to take care of the maintenance of the code (making sure it
works on new distros, dealing with pull requests, etc).
But only if someone else is willing to handle the non-coding parts, like
the website.
It would obviously be even better if someone was
willing to take the
big leap to JACK3, a version that combines all the best parts of JACK1
and JACK2, but I think it is more realistic to accept at this point
that this is not going to happen.
I think the ideal case would be to combine both pulseaudio and jack in a
single API that allows both realtime/producer-oriented plus
consumer-oriented applications.
Having pulseaudio give up the soundcard for JACK is nice and all, but
users get very confused why their sound mixer suddently stops working...
Anyway, I got a question for you Paul.
What do you think about the jack1 dbus patch?
Having that in would allow to have the same dbus tricks jack2 uses for
pulseaudio.
I know you don't truly agree on how it was done, but since you're
stepping down I know there's very little chance the "proper" way will
get done.
And Nedko, if you're reading this, are you willing to finish the jack1
dbus integration if Paul agrees with its inclusion?
11:09 a.m.
On Sat, Jan 30, 2016 at 12:03 PM, Filipe Coelho <falktx(a)gmail.com> wrote:
On 30.01.2016 17:13, 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.
Great!
Does this include the latest patch from Fons too?
It will, yes.
I'd be happy to take care of the maintenance of the code (making sure it
works on new distros, dealing with pull requests, etc).
But only if someone else is willing to handle the non-coding parts, like
the website.
The website doesn't change much. The "Applications" page already has its
own maintainer (though it also doesn't change much). I think you already
have push access on github, so ... great.
Anyway, I got a question for you Paul.
What do you think about the jack1 dbus patch?
Having that in would allow to have the same dbus tricks jack2 uses for
pulseaudio.
I know you don't truly agree on how it was done, but since you're stepping
down I know there's very little chance the "proper" way will get done.
my objection was that i think the dbus integration should be in a separate
process that uses the server control API to start/stop a JACK server.
at this point, i don't think that my objection is worth anything at all,
even though i still believe that my conception (the one that came out of
the 2007 "Berlin summit") is "more correct".
the reality is that nobody ever developed any other control protocols for
JACK. there was talk of an OSC control app, but this never materialized.
from a pragmatic perspective, dbus is the only control protocol that has
ever emerged, and after many (many!) years in that condition, it makes
sense to integrate that into the server itself.
3:37 p.m.
On 01/30/2016 07:09 PM, Paul Davis wrote:
The website doesn't change much. The "Applications" page already has its
own maintainer (though it also doesn't change much). I think you already
have push access on github, so ... great.
The lack of change and improvement on the website...
Well, I'll take the blame on me for that.
In the past, I had a vision but my motivation to support the website
kind of drowned due to various reasons. Some are similar observations
like Paul's, some are related to the complicated situation JACK (as an
API AND it's implementations) is in and there is also that damn thing
called "life" that keeps happening to me, very distracting.
Basically, I realised, that JACK is dead, maybe not yet the software,
but as a project and that is frustrating. The more I research about JACK
the more tired and sad I get, especially the inevitable aging of the
software and so on... the usual stuff that software developers have to
deal with. (see attachment for a little smile)
That may sound very negative (because I am currently very negative about
that) and I am not willing to contribute to JACK (1/2/API tools/homepage
and in general) anymore unless someone can provide a positive and
realistic vision for the project that is beyond milking the dead cow for
another 4 or 5 years.
I can check and merge pull requests, communicate and provide help
regarding the homepage if someone want's to take over but I won't put
significant effort in a website of which I have the feeling nobody cares
about and represents a dead project.
Well, enough rant and with the disclaimer that this is just from a
personal and very limited perspective on things.
6:10 p.m.
Hi,
i find it a bit sad that anyone seems to say things like "JACK is dead"
easily--- There is no alternative to it IMHO
Please, JACK lovers, speak out!
On Sat, January 30, 2016 23:30, Markus Seeber wrote:
On 01/30/2016 07:09 PM, Paul Davis wrote:
The website doesn't change much. The "Applications" page already has
its own maintainer (though it also doesn't change much). I think you
already have push access on github, so ... great.
The lack of change and improvement on the website...
Well, I'll take the blame on me for that.
In the past, I had a vision but my motivation to support the website
kind of drowned due to various reasons. Some are similar observations like
Paul's, some are related to the complicated situation JACK (as an
API AND it's implementations) is in and there is also that damn thing
called "life" that keeps happening to me, very distracting.
Basically, I realised, that JACK is dead, maybe not yet the software,
but as a project and that is frustrating. The more I research about JACK
the more tired and sad I get, especially the inevitable aging of the
software and so on... the usual stuff that software developers have to
deal with. (see attachment for a little smile)
That may sound very negative (because I am currently very negative about
that) and I am not willing to contribute to JACK (1/2/API tools/homepage
and in general) anymore unless someone can provide a positive and
realistic vision for the project that is beyond milking the dead cow for
another 4 or 5 years.
I can check and merge pull requests, communicate and provide help
regarding the homepage if someone want's to take over but I won't put
significant effort in a website of which I have the feeling nobody cares
about and represents a dead project.
Well, enough rant and with the disclaimer that this is just from a
personal and very limited perspective on things.
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
7:38 p.m.
On Sun Jan 31 2016, tom(a)trellis.ch wrote:
Hi,
i find it a bit sad that anyone seems to say things like "JACK is
dead" easily--- There is no alternative to it IMHO
Please, JACK lovers, speak out!
JACK is dead, Slackware just incorporated PulseAudio--I'm so depressed.
Surely the end of civilization is nigh.
Oh, wait, that was last week's news. This week, I'm just honery. I shall
fiddle while Rome burns, and record myself using JACK1! And some DSSI
plugins. And my Delta 44, with its newly-replaced caps. And my
PCI-slotted PC that it all runs on. And, heck, I might just use
ecasound via a serial port to do the recording. 'Cause I'm a dinosaur,
but I'm not going extinct, because I've got the source code to all this
freakin' stuff! (Oh, yeah, the PCI slot thing might be a problem.)
Long live JACK!
(A very big thank-you to you, Paul, for all the work you've done. Best
wishes on your future endeavors.)
-Sean
8:36 p.m.
can’t exist without Jack. interapplication is essential to us.
in fact, I thought I remember a jack-video project about a decade ago.
that’s what I need now in addition to jack audio.
Ken
On Jan 30, 2016, at 3:10 PM, tom(a)trellis.ch wrote:
Hi,
i find it a bit sad that anyone seems to say things like "JACK is dead"
easily--- There is no alternative to it IMHO
Please, JACK lovers, speak out!
On Sat, January 30, 2016 23:30, Markus Seeber wrote:
On 01/30/2016 07:09 PM, Paul Davis wrote:
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
The website doesn't change much. The "Applications" page already has
its own maintainer (though it also doesn't change much). I think you
already have push access on github, so ... great.
The lack of change and improvement on the website...
Well, I'll take the blame on me for that.
In the past, I had a vision but my motivation to support the website
kind of drowned due to various reasons. Some are similar observations like
Paul's, some are related to the complicated situation JACK (as an
API AND it's implementations) is in and there is also that damn thing
called "life" that keeps happening to me, very distracting.
Basically, I realised, that JACK is dead, maybe not yet the software,
but as a project and that is frustrating. The more I research about JACK
the more tired and sad I get, especially the inevitable aging of the
software and so on... the usual stuff that software developers have to
deal with. (see attachment for a little smile)
That may sound very negative (because I am currently very negative about
that) and I am not willing to contribute to JACK (1/2/API tools/homepage
and in general) anymore unless someone can provide a positive and
realistic vision for the project that is beyond milking the dead cow for
another 4 or 5 years.
I can check and merge pull requests, communicate and provide help
regarding the homepage if someone want's to take over but I won't put
significant effort in a website of which I have the feeling nobody cares
about and represents a dead project.
Well, enough rant and with the disclaimer that this is just from a
personal and very limited perspective on things.
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
11:26 p.m.
Thank you, Paul Davis, for originally making it possible for me to
build a real-tine composition environment using a transparent and
discoverable API.
John Mills
On 2016-01-31 12:10, tom(a)trellis.ch wrote:
Hi,
i find it a bit sad that anyone seems to say things like "JACK is
dead"
easily--- There is no alternative to it IMHO
Please, JACK lovers, speak out!
31 Jan
31 Jan
4:04 a.m.
On Sat, Jan 30, 2016 at 4:13 PM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
* as the years have gone on, although I am still
delighted by the
technical quality and
the conception of JACK, I no longer think that it is a particularly
good idea for most users. There
are times when it is useful
One thing that hasn't been mentioned yet is the educational aspect of JACK;
it is probably the simplest way to do audio I/O using C/C++. And the
community
around it are a great bunch.
I like JACK for its routing and pro-audio use-cases, but its the fact that
it
taught me to program audio applications due to it that I like most of all :)
Cheers! -Harry
--
http://www.openavproductions.com
4:22 a.m.
On 01/30/2016 05:13 PM, Paul Davis wrote:
It would obviously be even better if someone was
willing to take the big
leap to JACK3, a version that combines all the best parts of JACK1 and
JACK2, but I think it is more realistic to accept at this point that this
is not going to happen.
Have there been some plans about JACK3 already or was this always just a
general Idea?
4:33 a.m.
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.
4:22 p.m.
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
1 Feb
1 Feb
2:53 a.m.
On Sun, January 31, 2016 3:13 am, 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.
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:
* most linux distributions use JACK2 as their default, so JACK1's
relevance has diminished. I
still believe JACK1 to be a superior choice from some technical
perspectives, but there is
no doubt that JACK2's integration with dbus and thus its
interoperability with PulseAudio
has made this the safe and simpler choice for Linux.
* I really don't have the time to even think about things related to JACK
these days. It does
any future development a disservice to have me as the bottleneck, which
I effectively am
at the moment.
* Because 110% of my time is spent on Ardour, the fact that Ardour now
has
non-JACK
audio/MIDI I/O options has diminished the significance of JACK for my
own work.
* as the years have gone on, although I am still delighted by the
technical quality and
the conception of JACK, I no longer think that it is a particularly
good
idea for most users. There
are times when it is useful
I will continue to pay for the hosting of jackaudio.org (even though JACK2
continues to be distributed, managed and communicated about via other
channels), although if someone wanted to migrate this to some other more
communitarian platform, we could look into that.
I would be happy if someone volunteered to step up as maintainer of JACK1.
It would obviously be even better if someone was willing to take the big
leap to JACK3, a version that combines all the best parts of JACK1 and
JACK2, but I think it is more realistic to accept at this point that this
is not going to happen.
If nobody does step up, then there is a good chance that JACK1 will become
officially unmaintained. This isn't of much consequence, because once the
latest pull requests are merged, there won't be any known bugs in the
code,
and also because not many people use it anymore. This also means, of
course, that "maintainer" is not much of a task, should someone feel
hesitant about taking it on.
The end of an era!
A big congratulations to Paul and the Ardour team for getting to the point
where Paul is too busy to work on JACK anymore. That is a great
accomplishment and is due in large part to the original development of
JACK to create a solid foundation for Ardour.
JACK1 is still a very useful part of our toolkit. We routinely use it for
distributed audio processing on a range of machines with many different
versions of Linux. In that environment it seems to be more stable than
JACK2.
It seems that the differences between JACK1 and JACK2 relate to the
intended target use case. JACK2 does a decent job of trying to enable many
consumer friendly tasks and take out some of the pain of doing inter
application audio production. JACK1 handles some heavy lifting scenarios
more effectively than JACK2.
Maybe that is a good direction to continue for the different codebases?
JACK1 - Heavy lift mechanism for high performance Linux platforms
JACK2 - Flexible user friendly solution with cross platform support
I don't see any problem with continuing the split development process in
that regard. Maybe we don't need a single tool to do everything anyway?
I hope that Paul will continue to provide his insight and expertise as
part of the JACK development community.
If he is interested, I nominate Harry Van Haaren as the new official
maintainer for JACK1 codebase. He has proven his skills and commitment and
is a fair and impartial communicator.
Anyone else want to put their hat in?
--
Patrick Shirkey
Boost Hardware Ltd
4:18 a.m.
On Mon, Feb 01, 2016 at 08:53:05PM +1100, Patrick Shirkey wrote:
It seems that the differences between JACK1 and JACK2
relate to the
intended target use case. JACK2 does a decent job of trying to enable many
consumer friendly tasks and take out some of the pain of doing inter
application audio production. JACK1 handles some heavy lifting scenarios
more effectively than JACK2.
Maybe that is a good direction to continue for the different codebases?
JACK1 - Heavy lift mechanism for high performance Linux platforms
JACK2 - Flexible user friendly solution with cross platform support
I think that distinction is somewhat arbitrary. Some of us use JACK2 as a
multi-core replacement for JACK1. My own use case typically involves multiple
jack clients, sometimes large numbers of them, and JACK2 usually gives me
better performance on SMP systems. D-bus is actually irrelevant to me.
John
5:31 a.m.
On Mon, 1 Feb 2016 11:07:25 +0000, John Rigg wrote:
On Mon, Feb 01, 2016 at 08:53:05PM +1100, Patrick
Shirkey wrote:
D-bus is unimportant for me too. I don't know if JACK1 nowadays provide
-Xalsarawmidi or if I still need it this day, but JACK2's -Xalsarawmidi
at least reduced MIDI jitter on my Linux machine, when I needed it,
that's why I used it to get "high performance". For my usage JACK2
isn't more user-friendly than JACK1 is. The reason to prefer JACK2 over
JACK1 could be to get better performance, JACK1 not necessarily is
the better choice for "high performance" and JACK2 not necessarily is
more user-friendly.
Regards,
Ralf
It seems that the differences between JACK1 and
JACK2 relate to the
intended target use case. JACK2 does a decent job of trying to
enable many consumer friendly tasks and take out some of the pain of
doing inter application audio production. JACK1 handles some heavy
lifting scenarios more effectively than JACK2.
Maybe that is a good direction to continue for the different
codebases?
JACK1 - Heavy lift mechanism for high performance Linux platforms
JACK2 - Flexible user friendly solution with cross platform support
I think that distinction is somewhat arbitrary. Some of us use JACK2
as a multi-core replacement for JACK1. My own use case typically
involves multiple jack clients, sometimes large numbers of them, and
JACK2 usually gives me better performance on SMP systems. D-bus is
actually irrelevant to me.
7:07 a.m.
On Mon, Feb 1, 2016 at 7:31 AM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
wrote:
D-bus is unimportant for me too. I don't know if JACK1 nowadays provide
-Xalsarawmidi or if I still need it this day, but JACK2's -Xalsarawmidi
at least reduced MIDI jitter on my Linux machine, when I needed it,
that's why I used it to get "high performance".
jack1 has a similar implementation but for the ALSA sequencer API, which
means that (1) a2jmidid is no longer necessary (2) it can be used used to
communicate with other (ALSA MIDI using) applications, not just hardware.
6:17 a.m.
On Mon, February 1, 2016 10:07 pm, John Rigg wrote:
On Mon, Feb 01, 2016 at 08:53:05PM +1100, Patrick
Shirkey wrote:
Maybe it is the difference in the way we are using JACK over here.
Particularly with netjack but also with a variety of older systems. In
some cases we don't have pulseaudio or D-bus running. in total we have
more consistent results with JACK1 for our use case.
I'm not saying that JACK2 cannot be made to perform as well as JACK1 in
the same circumstances and it could also be that proper A/B testing
reveals a user bias instead of real world performance differences.
However we generally do not have the time or inclination to do such tests
as it usually takes a considerable amount of effort to get a fully working
system and trying to replicate the results with JACK2 is not our main
motivation.
The point is that JACK1 is still very useful so unless we are going to
spend a lot of time/effort to track down the differences between JACK1 and
JACK2 it is useful to keep JACK1 alive for specific use cases.
Assuming that we have a few people who are willing to keep contributing to
the JACK1 codebase then it shouldn't be a problem for JACK1 to track JACK2
or vice versa.
However if no one wants to continue maintaining JACK1 then we need to
spend some time to find and isolate any differences in performance between
the two.
--
Patrick Shirkey
Boost Hardware Ltd
It seems that the differences between JACK1 and
JACK2 relate to the
intended target use case. JACK2 does a decent job of trying to enable
many
consumer friendly tasks and take out some of the pain of doing inter
application audio production. JACK1 handles some heavy lifting scenarios
more effectively than JACK2.
Maybe that is a good direction to continue for the different codebases?
JACK1 - Heavy lift mechanism for high performance Linux platforms
JACK2 - Flexible user friendly solution with cross platform support
I think that distinction is somewhat arbitrary. Some of us use JACK2 as a
multi-core replacement for JACK1. My own use case typically involves
multiple
jack clients, sometimes large numbers of them, and JACK2 usually gives me
better performance on SMP systems. D-bus is actually irrelevant to me.
2 Feb
2 Feb
1:30 a.m.
On Tue, Feb 02, 2016 at 12:17:08AM +1100, Patrick Shirkey wrote:
Maybe it is the difference in the way we are using
JACK over here.
Particularly with netjack but also with a variety of older systems. In
some cases we don't have pulseaudio or D-bus running. in total we have
more consistent results with JACK1 for our use case.
I'm not saying that JACK2 cannot be made to perform as well as JACK1 in
the same circumstances and it could also be that proper A/B testing
reveals a user bias instead of real world performance differences.
However we generally do not have the time or inclination to do such tests
as it usually takes a considerable amount of effort to get a fully working
system and trying to replicate the results with JACK2 is not our main
motivation.
The point is that JACK1 is still very useful so unless we are going to
spend a lot of time/effort to track down the differences between JACK1 and
JACK2 it is useful to keep JACK1 alive for specific use cases.
Assuming that we have a few people who are willing to keep contributing to
the JACK1 codebase then it shouldn't be a problem for JACK1 to track JACK2
or vice versa.
However if no one wants to continue maintaining JACK1 then we need to
spend some time to find and isolate any differences in performance between
the two.
I agree that JACK1 is still very useful. I'm mainly using JACK2 at the moment
because I need to run multiple clients with the load spread over several CPU
cores. I used JACK1 for many years before my present use case, and I'd use it
again on a simpler setup.
As a user it's a bit frustrating that there are other differences between
JACK1 and 2 apart from UP/SMP and dbus capability. There's often some
other trade off to consider when deciding which one to use.
John
2:52 a.m.
On Mon, 1 Feb 2016 09:07:17 -0500, Paul Davis wrote:
On Mon, Feb 1, 2016 at 7:31 AM, Ralf Mardorf wrote:
Thank you for the clarification Paul.
On Tue, 2 Feb 2016 08:19:16 +0000, John Rigg wrote:
D-bus is unimportant for me too. I don't know
if JACK1 nowadays
provide -Xalsarawmidi or if I still need it this day, but JACK2's
-Xalsarawmidi at least reduced MIDI jitter on my Linux machine, when
I needed it, that's why I used it to get "high performance".
jack1 has a similar implementation but for the ALSA sequencer API,
which means that (1) a2jmidid is no longer necessary (2) it can be
used used to communicate with other (ALSA MIDI using) applications,
not just hardware. As a user it's a bit frustrating that there are
other differences
between JACK1 and 2 apart from UP/SMP and dbus capability. There's
often some other trade off to consider when deciding which one to use.
For newbies the help/man page are a PITA, for example take a look at
JACK2. Some options are not only missing explanations, beyond that
the man page even doesn't mention all options shown by help.
For example:
[rocketmouse@archlinux ~]$ jackd --help|grep sync;man jackd|grep sync;info jackd|grep
sync
no message buffer overruns
no message buffer overruns
no message buffer overruns
[ --sync OR -S ]
It focuses on two key areas: synchronous execution of all clients, and low latency
operation.
-L --async-latency
Extra output latency in asynchronous mode (percent) (default: 100)
The socket port we are listening on for sync packets (default: 3000)
-t, --transport-sync int
info: No menu item 'jackd' in node '(dir)Top'.
It focuses on two key areas: synchronous execution of all clients, and low latency
operation.
-L --async-latency
Extra output latency in asynchronous mode (percent) (default: 100)
The socket port we are listening on for sync packets (default: 3000)
-t, --transport-sync int
[rocketmouse@archlinux ~]$ jackd --help|grep autoconnect -A6; man jackd|grep autoconnect
no message buffer overruns
no message buffer overruns
no message buffer overruns
[ --autoconnect OR -a <modechar>]
where <modechar> is one of:
' ' - Don't restrict self connect requests (default)
'E' - Fail self connect requests to external ports only
'e' - Ignore self connect requests to external ports only
'A' - Fail all self connect requests
'a' - Ignore all self connect requests
Regards,
Ralf
1 Feb
1 Feb
7:10 a.m.
On Mon, Feb 1, 2016 at 4:53 AM, Patrick Shirkey <pshirkey(a)boosthardware.com>
wrote:
It seems that the differences between JACK1 and JACK2 relate to the
intended target use case. JACK2 does a decent job of trying to enable many
consumer friendly tasks and take out some of the pain of doing inter
application audio production. JACK1 handles some heavy lifting scenarios
more effectively than JACK2.
On Linux, JACK1 provides extremely easy ways to use multiple devices at
once, full integration with the ALSA sequencer system for MIDI and the
metadata system to allow for "pretty names" among other things.
JACK2 offers dbus integration which means that it can interact with
pulseaudio to "share" a device.
I don't think that your characterization is entirely accurate.
If he is interested, I nominate Harry Van Haaren as
the new official
maintainer for JACK1 codebase. He has proven his skills and commitment and
is a fair and impartial communicator.
Filipe (falktx) has already volunteered for the position.
12:18 p.m.
Patrick Shirkey wrote:
If he is interested, I nominate Harry Van Haaren as
the new official
maintainer for JACK1 codebase
He's a little busy, and happily developing LV2 plugins for OpenAV in the
time that's spare...
Paul Davis wrote:
Filipe (falktx) has already volunteered for the
position.
And is IMO the right guy for the job. Thanks falkTX for volunteering,
I'm a happy JACK1 user, and hope to keep it that way :)
Cheers, -Harry
--
http://www.openavproductions.com
2 Feb
2 Feb
12:31 a.m.
Thanks for making pro audio possible on linux Paul !
And good luck with Ardour !
Grtz
Thijs
Op 1-feb.-2016 20:18 schreef "Harry van Haaren" <harryhaaren(a)gmail.com>om>:
Patrick Shirkey wrote:
If he is interested, I nominate Harry Van Haaren
as the new official
maintainer for JACK1 codebase
He's a little busy, and happily developing LV2 plugins for OpenAV in the
time that's spare...
Paul Davis wrote:
Filipe (falktx) has already volunteered for the
position.
And is IMO the right guy for the job. Thanks falkTX for volunteering,
I'm a happy JACK1 user, and hope to keep it that way :)
Cheers, -Harry
--
http://www.openavproductions.com
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
1 Feb
1 Feb
4:28 a.m.
On Sat, Jan 30, 2016 at 11:13:06AM -0500, 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.
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)".
Thank you Paul for the great piece of software that is JACK. It played a major
part in enabling me to switch from analogue tape to computer based recording
over a decade ago. Best of luck in your other projects.
John
3270
days inactive
3273
days old
jackaudio@lists.linuxaudio.org
23 comments
14 participants
participants (14)
-
Filipe Coelho -
Florian Paul Schmidt -
Harry van Haaren -
Joakim Hernberg -
John Mills -
John Rigg -
Kenneth Fields -
Markus Seeber -
Patrick Shirkey -
Paul Davis -
Ralf Mardorf -
Sean Bolton -
Thijs van severen -
tom＠trellis.ch