distros migrating to JACK2?

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

distros migrating to JACK2?

michael noble-2
hi folks,

I just saw an interesting line over at opensuse.org (http://news.opensuse.org/2010/04/14/opensuse-11-3-milestone-5-the-community-strikes-back/) regarding the installation of JACK2 as default in the upcoming opensuse 11.3 release. That wasn't the interesting part. This is:

The JACK team is coordinating with openSUSE, Ubuntu, and Debian, among others, to upgrade to jack 1.9.5 (JACK2) during the spring/summer release cycle.

This seems to imply that there is quite a large move happening across multiple distros, and that move is being coordinated with JACK developers. I'm not a dev and I'm not really comfortable commenting on dev issues, but is this really accurate? Personally I'd be glad if there were such a move as JACK2 is what I use, but my understanding is that no announcements have been made by JACK devs regarding an official obsoletion of JACK1.  The reference provided with that statement is a very short email correspondence on the opensuse-factory mailing list about the topic that references an unmentioned debian-multimedia contact.

Are any interested or invested parties willing to provide some clarification on this? I know distros are fully welcome to package whatever they wish. I also am pretty sure that whatever happens will happen regardless of my opinion on the matter. There have, however, been some colorful exchanges between packagers and devs regarding JACK in the past so in the interest of transparency and openness I was hoping involved parties might have something to say about this.

-Michael



_______________________________________________
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: [LAD] distros migrating to JACK2?

Adrian Knoth
On Fri, Apr 16, 2010 at 11:32:16AM +0200, Philipp wrote:

> > Also note that there's no (easy) way back, we're entirely switching to
> > jackd2, that is, the user won't have the possibility to select jackd1
> > instead.
> May I ask for the reasoning behind this?

There are many reasons, some technical, some organizational, some
conceptional.

First, we can't have virtual packages for shared libraries in Debian, so
we cannot provide two different versions of libjack.

Second, we don't want application A require jack1 and application B
jackd2, so you can't run both applications. As this would be the case if
you have different jackd versions with different feature sets, we
entirely counter this by only packaging one version.

This is also beneficial wrt supporting. We don't want different problems
with different versions, we don't want writing patches twice, once for
jackd1 and a second time for jackd2.

Foremost, we don't want users to stumble because they're using "the
wrong" version. To us, jackd has nothing to do with choice, it's simply
an inter-application framework for routing audio/midi data, and no user
should ever need to care about this. (Do you care about libreadline? It
simply has to be there)

That said, we expect upstream to provide at least one feature-complete
jackd implementation. This means DBUS support (pulseaudio integration),
jack-session support, ladish support or whatever the feature should be,
e.g. SMP.

Since jack-session is rather new and the decision was made prior to
this, since CCRMA and Gentoo's pro-audio overlay all use jackd2, we
chose jackd2 to be this feature-complete jackd implementation.

If you want jack-session to fly, you need to have it in jackd2. It's
that simple. ;)

Consider this as a chance to avoid even more divergence among jackd
implementations.


HTH

--
mail: [hidden email]   http://adi.thur.de        PGP/GPG: key via keyserver
_______________________________________________
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: [LAD] distros migrating to JACK2?

Paul Davis
On Fri, Apr 16, 2010 at 10:15 AM, Adrian Knoth
<[hidden email]> wrote:
> First, we can't have virtual packages for shared libraries in Debian, so
> we cannot provide two different versions of libjack.

i don't understand this. either i'm not understanding the point, or it
sounds likea debian-specific limitation. i use fedora+ccrma, which has
jack2. i removed jack2 (--nodeps) and overlaid jack1. all fedora
packages that relate to JACK continue to work normally. am i not
understanding what you mean?

> Second, we don't want application A require jack1 and application B
> jackd2, so you can't run both applications. As this would be the case if
> you have different jackd versions with different feature sets, we
> entirely counter this by only packaging one version.

this seems entirely reasonable.

> This is also beneficial wrt supporting. We don't want different problems
> with different versions, we don't want writing patches twice, once for
> jackd1 and a second time for jackd2.

this is understandable, if less reasonable. at this point in time, the
bugs in jack2 are entirely different bugs from the bugs in jack1. the
existence of a bug in either version doesn't predict the status of
that functionality in the other.

> Foremost, we don't want users to stumble because they're using "the
> wrong" version. To us, jackd has nothing to do with choice, it's simply
> an inter-application framework for routing audio/midi data, and no user
> should ever need to care about this. (Do you care about libreadline? It
> simply has to be there)

this seems sort of right, although only as long as you use "jack" to
refer to the library+server and not any of the front end control
apps,patchers etc.

> That said, we expect upstream to provide at least one feature-complete
> jackd implementation. This means DBUS support (pulseaudio integration),
> jack-session support, ladish support or whatever the feature should be,
> e.g. SMP.

this is where things really fall apart because it presupposes
agreement on the feature set, an agreement which as i think you know
just isn't there.

> Since jack-session is rather new and the decision was made prior to
> this, since CCRMA and Gentoo's pro-audio overlay all use jackd2, we
> chose jackd2 to be this feature-complete jackd implementation.

> Consider this as a chance to avoid even more divergence among jackd
> implementations.

I understand the sentiment, but I am not sure that this is likely to
have this result.
_______________________________________________
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: distros migrating to JACK2?

Paul Davis
In reply to this post by michael noble-2
On Fri, Apr 16, 2010 at 2:06 AM, michael noble <[hidden email]> wrote:
> This seems to imply that there is quite a large move happening across
> multiple distros, and that move is being coordinated with JACK developers.

it is not being coordinated JACK developers via any public mechanism
that i am aware of.

--p
_______________________________________________
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: [LAD] distros migrating to JACK2?

Adrian Knoth
In reply to this post by Paul Davis
On Fri, Apr 16, 2010 at 10:31:08AM -0400, Paul Davis wrote:

> > First, we can't have virtual packages for shared libraries in Debian, so
> > we cannot provide two different versions of libjack.
> i don't understand this. either i'm not understanding the point, or it
> sounds likea debian-specific limitation. i use fedora+ccrma, which has

It's debian-specific. I don't know the details, but the build system
can't resolve dependencies on virtual shared libraries. Something like
that.

If you see

   http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

there's only a single virtual library package (libc-dev).

There might be a way to handle it, but this would require us to put
everything into a single package, let's say jackd1.deb and jackd2.deb
both cater to the virtual package jackd.


> > That said, we expect upstream to provide at least one feature-complete
> > jackd implementation. This means DBUS support (pulseaudio integration),
> > jack-session support, ladish support or whatever the feature should be,
> > e.g. SMP.
>
> this is where things really fall apart because it presupposes
> agreement on the feature set, an agreement which as i think you know
> just isn't there.

Card reservation. That's what users are most whining about.

I already proposed something like jackd -d pulseaudio, so the non-pro
users can run their occational ardour session on top of PA without the
need to ever shut it down.

For real pros, there's still the second unoccupied card. Or third.

I also provided a proof-of-concept implementation, I've shown a working
ardour session on top of pulseaudio. Sure the latency is crap, but let's
be honest? Who's connecting his el-cheapo laptop card to a pro setup?
They buy themselves a Multiface, a FFADO-supported card or some other
pro gear. ;)


Anyway, to have this documented: I came to #jack some weeks ago and
asked whether it's right to move to jackd2 or not. Nobody cared to give
an answer, yours was "That's a political question."

Nobody said "tschack also has SMP and even performs better than jackd2",
nobody said "we're going to have jack-session support in jackd1", in
general, all communication from the jack team was "jackd2 is more or
less a drop-in replacement for jackd1", and the jackd2 camp added "we
have fancy SMP, we have fancy card reservation, we have glitchless
connections" and the lot.

So to the outside, the impression was that jackd1 development got stuck
(somewhere around 0.116 or even before) and that jackd2 will be its
successor, the development branch, if you want. Renaming it from jackdmp
to jackd2 didn't help, sharing the same website, trac and svn didn't
help.


The jack team (if such a thing exists) never set its goals, whether
jackd2 is just a playground, an alternative or the successor. There is
no jackd1 roadmap, there was nobody saying "we're going to have SMP as
well".

And now you wonder why everyone else was under the impression that the
world only needs one jackd implementation and picked the one with the
higher number?

Sit together and agree on some goals. Don't have three incompatible
netjack implementations, five session management APIs and four different
jackd incarnations just for each corner case. I'm clearly exaggerating
here, but that's exactly what was missing in the past: a decent
statement to users about goals, features and how things relate to each
other.



Cheerio

PS: jackd2 needs to rename jack_rec to jackrec, jackd1 and jackd2 should
share the same manpages (maybe from the same svn branch), netjack
command line parameters need to be the same. That's a plea to both,
jackd1 and jackd2. Work together, forward your patches, read your
tickets. Make it less cumbersome for users, they are the ultimate
judges.

--
mail: [hidden email]   http://adi.thur.de        PGP/GPG: key via keyserver
_______________________________________________
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: [LAD] distros migrating to JACK2?

Paul Davis
On Fri, Apr 16, 2010 at 3:36 PM, Adrian Knoth <[hidden email]> wrote:

I'll happily deal with the rest of the email later, but I just want to
note that I very strenously object to being lectured about how the
JACK project should behave.
There have been some serious errors in what has happened, when viewed
from both the inside and the outside. But the reasons why these things
have happened is not rooted in malice, or confusion, or lack of
communication, and it doesn't help the situation at all to suggest
that the solution is just "sit down and agree on some goals". lack of
common goals is very far from the problem here.
_______________________________________________
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: [LAD] distros migrating to JACK2?

Ralf Mardorf
In reply to this post by Adrian Knoth
Adrian Knoth wrote:

> On Fri, Apr 16, 2010 at 10:31:08AM -0400, Paul Davis wrote:
>
>  
>>> First, we can't have virtual packages for shared libraries in Debian, so
>>> we cannot provide two different versions of libjack.
>>>      
>> i don't understand this. either i'm not understanding the point, or it
>> sounds likea debian-specific limitation. i use fedora+ccrma, which has
>>    
>
> It's debian-specific.

No, I'm using a Debian and Ubuntu, were it's easy to build dummy
packages and I'm using Suse too, were it's much dirtier. I'm doing this
just to test a sequencer, my favourite distro is 64 Studio and they ship
with the JACK I wish to use.

> I don't know the details, but the build system
> can't resolve dependencies on virtual shared libraries. Something like
> that.
>
> If you see
>
>    http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
>
> there's only a single virtual library package (libc-dev).
>
> There might be a way to handle it, but this would require us to put
> everything into a single package, let's say jackd1.deb and jackd2.deb
> both cater to the virtual package jackd.
>
>
>  
>>> That said, we expect upstream to provide at least one feature-complete
>>> jackd implementation. This means DBUS support (pulseaudio integration),
>>> jack-session support, ladish support or whatever the feature should be,
>>> e.g. SMP.
>>>      
>> this is where things really fall apart because it presupposes
>> agreement on the feature set, an agreement which as i think you know
>> just isn't there.
>>    
>
> Card reservation. That's what users are most whining about.
>
> I already proposed something like jackd -d pulseaudio, so the non-pro
> users can run their occational ardour session on top of PA without the
> need to ever shut it down.
>
> For real pros, there's still the second unoccupied card. Or third.
>
> I also provided a proof-of-concept implementation, I've shown a working
> ardour session on top of pulseaudio. Sure the latency is crap, but let's
> be honest? Who's connecting his el-cheapo laptop card to a pro setup?
>  

Nobody. I don't have money, but at least an Envy24 card around 50 EUR
would make an on-board audio device obsolete.

> They buy themselves a Multiface, a FFADO-supported card or some other
> pro gear. ;)
>
>
> Anyway, to have this documented: I came to #jack some weeks ago and
> asked whether it's right to move to jackd2 or not. Nobody cared to give
> an answer, yours was "That's a political question."
>  

JACK2 doesn't disconnect clients. The disadvantage: There might be
phasing between the left and the right channel. The advantage: Even if
your hardware isn't good for usage with Linux audio, you are able to use
it, but the quality isn't optimal.

> Nobody said "tschack also has SMP and even performs better than jackd2",
> nobody said "we're going to have jack-session support in jackd1", in
> general, all communication from the jack team was "jackd2 is more or
> less a drop-in replacement for jackd1", and the jackd2 camp added "we
> have fancy SMP, we have fancy card reservation, we have glitchless
> connections" and the lot.
>
> So to the outside, the impression was that jackd1 development got stuck
> (somewhere around 0.116 or even before) and that jackd2 will be its
> successor, the development branch, if you want. Renaming it from jackdmp
> to jackd2 didn't help, sharing the same website, trac and svn didn't
> help.
>
>
> The jack team (if such a thing exists) never set its goals, whether
> jackd2 is just a playground, an alternative or the successor. There is
> no jackd1 roadmap, there was nobody saying "we're going to have SMP as
> well".
>
> And now you wonder why everyone else was under the impression that the
> world only needs one jackd implementation and picked the one with the
> higher number?
>
> Sit together and agree on some goals. Don't have three incompatible
> netjack implementations, five session management APIs and four different
> jackd incarnations just for each corner case. I'm clearly exaggerating
> here, but that's exactly what was missing in the past: a decent
> statement to users about goals, features and how things relate to each
> other.
>
>
>
> Cheerio
>
> PS: jackd2 needs to rename jack_rec to jackrec, jackd1 and jackd2 should
> share the same manpages (maybe from the same svn branch), netjack
> command line parameters need to be the same. That's a plea to both,
> jackd1 and jackd2. Work together, forward your patches, read your
> tickets. Make it less cumbersome for users, they are the ultimate
> judges.
>  

Users like me who reported their experiences were dissed other users got
Apple or Microsoft and there only were the users that were comfortable.

And now I'm comfortable, because I do need JACK2, but I'm empathetic
with those who prefer JACK1, because I did suffer a lot when JACK1 was
default, while I need to use JACK2.

There's only one good solution. Every user must have the choice between
JACK1 and JACK2.

Ralf
_______________________________________________
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: [LAD] distros migrating to JACK2?

Adrian Knoth
On Fri, Apr 16, 2010 at 09:55:56PM +0200, Ralf Mardorf wrote:

>>>> First, we can't have virtual packages for shared libraries in Debian, so
>>>> we cannot provide two different versions of libjack.
>>>>      
>>> i don't understand this. either i'm not understanding the point, or it
>>> sounds likea debian-specific limitation. i use fedora+ccrma, which has
>>>    
>>
>> It's debian-specific.
> No, I'm using a Debian and Ubuntu, were it's easy to build dummy  

Feel free to enlighten me how to provide both, jackd1 and jackd2 in
Debian.

I'm happy to please both camps, if possible.

> JACK2 doesn't disconnect clients. The disadvantage: There might be  
> phasing between the left and the right channel. The advantage: Even if  

Could you elaborate on this? I don't understand it.


> There's only one good solution. Every user must have the choice between  
> JACK1 and JACK2.

   http://linuxhaters.blogspot.com/2008/07/fallacy-of-choice.html



--
mail: [hidden email]   http://adi.thur.de        PGP/GPG: key via keyserver
_______________________________________________
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: [LAD] distros migrating to JACK2?

Paul Davis
In reply to this post by Adrian Knoth
On Fri, Apr 16, 2010 at 3:36 PM, Adrian Knoth <[hidden email]> wrote:
> It's debian-specific. I don't know the details, but the build system
> can't resolve dependencies on virtual shared libraries. Something like
> that.

That's pretty pathetic. But I guess there's not much to be done about that.

> Card reservation. That's what users are most whining about.
>
> I already proposed something like jackd -d pulseaudio, so the non-pro
> users can run their occational ardour session on top of PA without the
> need to ever shut it down.

Lennart and myself, had long discussions in Berlin last year, followed
by actual work from Nedko to implement what Lennart had suggested (or
something close to it). I'm not clear why distro packagers (and I'm
speaking generally here - you've been exemplary in getting debian
patches back to us) feel the need to ignore the design decisions of
PulseAudio and JACK's designers. The problems with interactions
between the two come from the fact that JACK is cross-platform and
that therefore these kinds of mechanisms need to be added carefully in
ways that don't cause issues for users on other platforms. This has
led to the PA/JACK "cooperation" not developing as fast or as deep as
we would like. One of the things that Lennart and I both agreed upon
VERY emphatically was that when a user starts up JACK, our conclusion
is that they *intend* for other audio routing to get out of the way,
and thus PA would go along with it. Adding a pulseaudio backend
totally inverts that assumption.


> I also provided a proof-of-concept implementation, I've shown a working
> ardour session on top of pulseaudio. Sure the latency is crap, but let's
> be honest? Who's connecting his el-cheapo laptop card to a pro setup?
> They buy themselves a Multiface, a FFADO-supported card or some other
> pro gear. ;)

if they are not connecting JACK to their el-cheapo laptop card, then
the issue doesn't arise, does it?

> Anyway, to have this documented: I came to #jack some weeks ago and
> asked whether it's right to move to jackd2 or not. Nobody cared to give
> an answer, yours was "That's a political question."

as it is. so lets tackle this head on and without reservations.

about 3 years ago, the JACK mini-summit in Berlin agreed that
stephane's implementation of jack would become the future of JACK. i
can't speak for everyone who was there, but for my part, there were a
several reasons for this decision:

     * stephane's version already supported SMP
     * stephane's version already had support for "click free graph changes"
     * stephane's version was written in C++ and was more modular in
its internal design than jack1
     * stephane had become the most active developer/maintainer of JACK
     * stephane was likely to port his implementation to Windows (OK,
we didn't actually know this at the time, but its turned out to be of
            some significance)
     * there was a lot of discussion about the "JACK Control API" and
it seemed easier to imagine implementing this
            in the context of stephane's implementation

Other's might have had some other reasons too, but I think those were mine.

What has happened since then is that the active JACK developer
community has shrunk down to about 3.25 people (Stephane, Torben Hohn,
myself and occasionally Nedko). This is hardly suprising given the
status of the project, but it does have some ramifications. And the
ramifications are that Torben, who has recently been the most active
for a while, feels uncomfortable working on the jack2 codebase and is
dissatisfied with some of the design decisions in Jack2. Because of
the very small size of the development community, this disagreement is
essentially one of personal style, and the two of them have basically
agreed to disagree while working to avoid doing anything to make the
current situation worse. When you have basically 2 active developers
and they don't agree on design and coding style and you have 2
functional implementations which each has its own "champion", its
going to be hard to see a convergence. And, indeed, Torben has moved
along by "forking" the jack1 code and implementing several of the most
important features of jack2 (SMP support, click free graph changes).
He hasn't publically announced this as a fork, and I'm not sure he
really views it that way.

For myself, I confess to being disappointed and puzzled by my own
reaction to Stephane's implementation. I was a big supporter of a C++
implementation which I felt would bring some clarity to the rather
tangled code in Jack1. I also felt very supportive of his goals for
Jack2, not to mention his insanely hard word porting JACK to OS X
(back when it was just jack1) and Windows and continually grappling
with some of the crazier aspects of OS X integration as part of his
work on JackOSX. I really did feel that it would be an improvement to
switch to his implementation and that things would all get better as a
result of this change (in the long run). However, these feelings have
not materialized for me. I don't know why. I don't find myself
regarding the code base of Jack2 as any easier to grapple with than
Jack1 (there are a few areas where portability is simpler because of
the use of C++ classes and inheritance). Like Torben, there are some
design decisions there that I have questions about. In spite of this,
I've continued to have a high regard for Stephane's work and for
Stephane, if for no other reason (and there are PLENTY of other
reasons) than that he had a clear vision of where JACK should go and
he took it there in a fairly time honored Unix/Linux tradition: rather
than convincing everyone working on/with Jack1, he created new
implementation. djbdns, hello?

Meanwhile, we had Torben's original NetJack protocol which was lacking
in some ways, and so a student/colleague of Stephane's implemented a
new version of NetJack to try to address them. This was done in the
context, the supposition, of an "experimental" or "research-y" type of
effort, rather than being part of a concerted, deliberate effort to
get audio-over-IP working for "the masses". It probably doesn't help
that there have been "expert" users of both versions of NetJACK since
they were created, testing it out, and voicing their satisfactions
over the majority of both implementations' feature set, along with
suggestions for improvements, giving an appearance that both protocols
had their benefits and making it harder to kill one of them or merge
them.

Regarding session management, there was basically almost nobody except
for Nedko who agreed with him about his designs for session
management. Torben finally got sick of the endless bickering about
session management when he felt that a solution was fairly readily
available. The design hasn't pleased everyone, and a few people would
have preferred that it hadn't been committed to Jack1, but more apps
every week are adding support for it and my guess is that it will
become useful. Could anyone have predicted this in January? No. Did we
know that session management was needed? Yes. Did we have a clue of
how we would get there? Maybe Nedko did, but I don't think anyone else
did. I've seen similar things happen with GTK (for example,
ExtendedLayout which has recently jumped off the "discussed for years"
list and turned into an implementation that is being tweaked and
evaluated in a very short time).

And then we have to face the gathering impact of:

    (a) more users, many of who don't fall neatly along the desktop /
pro-audio+music divide
    (b) more distros actively packaging JACK
    (c) the arrival of PulseAudio on many distributions

All of a sudden, what felt like peacefully co-existing worlds of
"trying stuff out and trying to keep as in-sync as possible given
limited man-power" are thrown into a decision in which only one of
them can blessed.

I have to say that I resent this. I understand why its happening, but
I resent it. We didn't write JACK to be part of the desktop
environment, we wrote it as a tool for people doing serious
audio&music work. But because a distribution can't handle a basic
concept like a "virtual package" (and that happens to be the distro
that has spawned more offspring than any other), all of a sudden, the
way that we've worked (or not worked - I'll grant its been a bit
dysfunctional for a while now) is threatened so that you guys can
package "one version".

The architecture of JACK (server plus shared library) makes it more
difficult for the right thing to happen - the right thing being that
anyone can implement their own version of JACK and if its compliant
then anyone can use it at any time. Those who use JACK *today*
understand this and my impression is that its actually a somewhat
valued feature that both JACK implementations exist. I can understand
why newcomers to this ecosystem would not share their opinion. And so
perhaps its right to at least have a more upfront discussion about the
future of JACK's versions. I tried to instigate this with NetJACK
several months ago, and although in the meantime, NetJACK1 has
improved in some subtle but important ways, we are no closer to a
single network protocol than we were then. Should we be? Is it a
requirement that we get there? Is it a requirement that users *must*
choose one of jack2 or jack1, when (almost) all the tools will work
just fine with either version? All the tools, that is, except for
debian's packaging system.

Clearly, we can't dispose of that. But to what extent should the
future development path of JACK be determined by the limitations of
packaging systems?

Does anyone really want to have to choose between JACK1 and JACK2 (and
tschak? perhaps) on a permanent basis? Does anyone want to step up and
make the hard decision about NetJACK1 or NetJACK2? Can that decision
even *be* made? Is that supposed to be my job?

--p
_______________________________________________
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: distros migrating to JACK2?

Gabriel M. Beddingfield-2
In reply to this post by Adrian Knoth

On Fri, 16 Apr 2010, Adrian Knoth wrote:

> Feel free to enlighten me how to provide both, jackd1 and jackd2 in
> Debian.
>
> I'm happy to please both camps, if possible.

I think I might have an idea how to do it.  But first:  Has
anyone else tried it yet?

Thanks,
Gabriel
_______________________________________________
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: [LAD] distros migrating to JACK2?

Ralf Mardorf
In reply to this post by Adrian Knoth
Adrian Knoth wrote:

> On Fri, Apr 16, 2010 at 09:55:56PM +0200, Ralf Mardorf wrote:
>
>  
>>>>> First, we can't have virtual packages for shared libraries in Debian, so
>>>>> we cannot provide two different versions of libjack.
>>>>>      
>>>>>          
>>>> i don't understand this. either i'm not understanding the point, or it
>>>> sounds likea debian-specific limitation. i use fedora+ccrma, which has
>>>>    
>>>>        
>>> It's debian-specific.
>>>      
>> No, I'm using a Debian and Ubuntu, were it's easy to build dummy  
>>    
>
> Feel free to enlighten me how to provide both, jackd1 and jackd2 in
> Debian.
>
> I'm happy to please both camps, if possible.
>  

Not both at the same time and of course I do have an outdated Debian
install, but I guess Ubuntu is equivalent to Debian. Am I mistaken?

And as I've written before, you need dummy packages or the other dirty
solution is to keep the packages, but to delete their files and to
over-install a self-build version.

>> JACK2 doesn't disconnect clients. The disadvantage: There might be  
>> phasing between the left and the right channel. The advantage: Even if  
>>    
>
> Could you elaborate on this? I don't understand it.
>  

Yes. On my machine JACK1 did and maybe does disconnect clients, thus I'm
running JACK2. Even if I don't have any messages by JACK2, e.g. xruns,
there are troubles regarding to the quality of the sound, e.g. sometimes
the left and right channel aren't in sync.
I don't need any measurement, I'm able to hear this, but of course I did
verify it by using a "Phasenkorellator", what ever it's called on
English. I solved this by using high latency.
I'm tired of discussing that. Believe me or don't believe it.

>> There's only one good solution. Every user must have the choice between  
>> JACK1 and JACK2.
>>    
>
>    http://linuxhaters.blogspot.com/2008/07/fallacy-of-choice.html
>  

Ok, I just read the first paragraphs. It's unimportant to me. I'm a
musician, I'm an audio engineer, I'm a user.

I'm free to use my favourite distro, I'm free not to use Linux ... I
Just like to report that there are some very experienced audio engineers
who don't have the time to care about this issues. I do have the time :).

Do what ever you like to do, think what ever you like to think and maybe
the day will come, you'll climb down the ivory tower and meet some
"accepted" audio engineers.

Don't care about my opinion, just care about those people who were
comfortable using JACK1 and who now are informed that for the future
they have to deal with issues because their distro will ship with JACK2
and that there is no comfortable way to keep JACK1.

IMO this can't be the right way. What ever the reason is to use JACK1 or
JACK2, some people might be neurotic and because of that they just can't
stand the index 1 or 2 ... What is the reason not to have a package for
JACK1 and another for JACK2? What is the reason to separate jackd from
libjack?

At the moment I do have a free jazz phase of life, I don't care much
about computers for music anyway. I'm sure there will be the time I like
to do sequencer based pop music again, if so I anyway won't care much
about JACK audio, but because of ALSA MIDI jitter.

However that be, Linux audio IMO is completely independent from any rule
because of Linux package management that makes sense for apps for the
averaged Linux user. Nobody but audio folks do need JACK. Whatever I do
report about any version of JACK is irrelevant, the only important issue
at the moment is to think about making JACK1 and 2 available for every user.

I'm sorry if I did miss the thread because of some notes. Be sure, we'll
have the chance to regard those issues for another thread at another time.

Perhaps we could write off-list on German regarding to some OT issues
... after the weekend ;).

For me it's good news that distros do ship with JACK2 in the future! But
I do sympathize with the people who like to use JACK1 and eventually the
day will come distros decide to ship with JACK1 again. Users just can't
relay to keep a stable system for their needs, while they stay at and
upgrade their favourite distro.

This is bad.

2 Cents
Ralf
_______________________________________________
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: [LAD] distros migrating to JACK2?

Ralf Mardorf
In reply to this post by Paul Davis
Paul Davis wrote:
> We didn't write JACK to be part of the desktop
> environment, we wrote it as a tool for people doing serious
> audio&music work.

Full ACK, from the standpoint of a user.

> the right thing being that
> anyone can implement their own version of JACK and if its compliant
> then anyone can use it at any time.

Full ACK, from the standpoint of a user.

> I can understand
> why newcomers to this ecosystem would not share their opinion.

Because users, even users who developed well known professional audio
equipment are dissed as idiots, from the standpoint of a developer of
well known professional audio equipment.

It seems to be that users are unimportant, resp. desktop users seems to
be important regarding to JACK.
_______________________________________________
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: distros migrating to JACK2?

Stéphane Letz
In reply to this post by michael noble-2
At Grame, we started working on JACK (jack1 at that time) in 2003 and our first commitment was to port the C code base on OSX. Even if the result was working, we rapidly felt that the C code base was not flexible enough to evolve in the direction we wanted to explore: multi-platforms support, SMP and glitch-free connections (among other ideas we had...) . Around 2004-2005 we had a new C++ based code base that was first developed on OSX, later ported in Linux (2005), on Windows (summer 2006) and Solaris (summer 2008 as a result of funding coming from RTL french radio). In 2004 we also found the way to better "integrate" JACK in the CoreAudio architecture on OSX (the JackRouter JACK/CoreAudio bridge) that allowed any CoreAudio application to become a JACK client, thus participating in the success we had on OSX with the JackOSX package.

I think the "about 3 years ago, the JACK mini-summit in Berlin" Paul told about, was actually during LAC 2008 in Kohn. It was my impression that most of the JACK community was interested to see jackdmp (renamed jack2 at that moment) become the future of JACK, and late 2008 and 2009 was an intense period of work to reach this goal. Nedko (mostly but some other) did a huge job of improving the build system, implement the so-called "JACK Control API" (or at least the server side of it) and helped in other areas. The D-Bus based server control code (Nedko) was also integrated at that time.  

In spring 2009 started this "D-Bus war" and after endless discussion with people with strong opinions (Fons, Nedko...) it appeared that no agreement could be found. The best that we could achieve (in my view) was to clearly define the "JACK Control API" as the "frontier" between the external world that wants to control the JACK server, and the server code itself, and report all more sophisticated control mechanism outside. At about the same time, some developers (Torben, Paul ...) started to rebirth the jack1 codebase, and it appeared more and more clear that the "jack2 become the official code base" idea start to become a vanishing goal.

I must say that I still don't have a clear understanding of why this happened. I still don't understand the sentence "Like Torben, there are some design decisions there that I have questions about." and I think explaining it in more details would really help. The fact that jack1 and jack2 are almost indistinguishable in everyday use is quite satisfactory, but at the same time the subtle difference that stay continue to cause some endless comments from users about the "real" advantages of each of the two implementations. I still see reports from "more xruns" here or a "bit less CPU use" there, but with no real data and clear "step by step way to reproduce issues" that would help to fix remaining bugs in jack2 codebase (for example jack2 still probably has issue with multi-cards support compared to jack1, but AFAICS this is in ALSA backend, and I cannot progress on that without the help of people with multi-cards and knowledge in ALSA backend code).

Concerning session management added in JACK codebase, I did not followed the discussion in details. I said to Paul in a private mail that I though it was not a good idea (but maybe I am completely wrong...) but I would certainly not oppose to a implementation for jack2. I remember someone volunteered to work on that ??

I have to say that I become quite tired of all that mess, since I don't see any clear way to solve the situation. After about 5 years of real commitment in JACK project, I decided to move back a bit and work on some other stuff. I still try to follow bug reports and jack1 changes, release a package from time to time and maintain JackOSX project. I still think some interesting ideas (like the "pipelining" mode that currently stay in a jack2 branch...) are of interest (especially since we now see with those "4 cores/threads" model in new laptops...) and should be pushed in mainline.

Stéphane
_______________________________________________
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: distros migrating to JACK2?

Patrick Shirkey
Hi,

I think it is reasonable for jack2 to become the default install for all
the mainstream distros. That won't stop people from using jack1 and it
won't stop development of jack in general. IMO it will simply make audio
a little more streamlined for normal users.

I have had to move to jack2 in order to get a stable system on my multi
core machines. If I wanted to use a single core machine I would probably
install jack1 on it. I have tried to use jack1 on my multicore machines
and the results were not as I was accustomed to on my single core
machines of the past.

It's a pity that there is no easy way to package and manage both options
but it is not the end of the world either. Great work will continue to
be done.  In a way it represents a new phase for jack-development as
jack2 has got to the point where it is reasonable to consider it the
default option.

All JACK developers should be proud of that achievement. As has been
done already by Paul and Stephane take a moment to acknowledge the
efforts that have got us to this point and the achievements that are
represented by the ever multiplying and expanding, creativity inspiring
platform that JACK has become.


Cheers.

Patrick Shirkey
Boost Hardware Ltd


_______________________________________________
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: distros migrating to JACK2?

James Warden
I should probably not speak up loud in this discussion but I'll do it anyway:

if the Jack Audio Connection Kit is fundamentally an API, then there can be as many implementations as one could provide. The so-called jack1 and jack2 iplementations are the two we already have, but anybody could come up with a 3rd one, etc.

I don't see why jack1 should be obsoleted by jack2 or jack2 given up because of jack1's use by power users / developers.

I switched to jack2 myself 1.5 year ago because I have a dual core based PC and I have no regret, no need for me to look at jack1. But jack1 is still more than relevant and in many ways seeing it fading from view because of distro packagers would be a great loss.

So if JACK truly is an API, jack1 and jack2 are perfectly able to coexist if one stops seeing one as the transcendental version of the other or whatever, which to my mind is a bit idiotic. But again, I am not into the jack development circle so I will shut up now.

J.


     
_______________________________________________
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: [LAD] distros migrating to JACK2?

torbenh
In reply to this post by Stéphane Letz
On Sat, Apr 17, 2010 at 12:10:10PM +0200, Stéphane LETZ wrote:

> Concerning session management added in JACK codebase, I did not followed the discussion in details. I said to Paul in a private mail that I though it was not a good idea (but maybe I am completely wrong...) but I would certainly not oppose to a implementation for jack2. I remember someone volunteered to work on that ??

yeah. paniq said he would do it. but he somehow disappeared.
i am working on it now.
gonna push what i have to repo.or.cz after i finish this mail.
its not finished yet. but please comment.



--
torben Hohn
_______________________________________________
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: [LAD] distros migrating to JACK2?

Stéphane Letz

Le 17 avr. 2010 à 15:08, torbenh a écrit :

> On Sat, Apr 17, 2010 at 12:10:10PM +0200, Stéphane LETZ wrote:
>
>> Concerning session management added in JACK codebase, I did not followed the discussion in details. I said to Paul in a private mail that I though it was not a good idea (but maybe I am completely wrong...) but I would certainly not oppose to a implementation for jack2. I remember someone volunteered to work on that ??
>
> yeah. paniq said he would do it. but he somehow disappeared.
> i am working on it now.
> gonna push what i have to repo.or.cz after i finish this mail.
> its not finished yet. but please comment.
>
>

Seems like session.h header is lacking.

Stéphane
_______________________________________________
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: distros migrating to JACK2?

Arnold Krille-3
In reply to this post by Patrick Shirkey
On Saturday 17 April 2010 12:40:37 Patrick Shirkey wrote:
> I have had to move to jack2 in order to get a stable system on my multi
> core machines. If I wanted to use a single core machine I would probably
> install jack1 on it.

The funny thing is that I get a better performance with more equalized cpu-
usage with jack2 on my uni-processor system...

Have fun,

Arnold

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

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] distros migrating to JACK2?

Arnold Krille-3
In reply to this post by Adrian Knoth
On Friday 16 April 2010 16:15:37 Adrian Knoth wrote:
> First, we can't have virtual packages for shared libraries in Debian, so
> we cannot provide two different versions of libjack.

Are you kidding me?

Surely that is a political decision, not a technical issue?
Why not make all the different jack-packages provide a name "jack-audio-
connection-kit" [*], have all the jack-apps depend on that and be done with
it?

The switching from jack1 to jack2 is totally transparent. My ubuntu think I am
running jack1 because thats what the packages installed in /usr. Actually I am
running jack2 installed in my homedir and with path and LD_LIBRARY_PATH
adapted to get the libs from there at runtime. Works like charm thanks to
binary compatibility on the jack site.

Have fun,

Arnold

[*] You could include an api/abi version in there. But I am not sure if jack
itself keeps track of api changes that way...

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

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] distros migrating to JACK2?

Gabriel M. Beddingfield-2


On Sat, 17 Apr 2010, Arnold Krille wrote:

> On Friday 16 April 2010 16:15:37 Adrian Knoth wrote:
>> First, we can't have virtual packages for shared libraries in Debian, so
>> we cannot provide two different versions of libjack.
>
> Are you kidding me?
>
> Surely that is a political decision, not a technical issue?

I think it's a reasonable misunderstanding, and that it
indeed appears to be technically feasible to do it.

Originally, when it was "officially" understood that Jack2
would replace Jack1, it didn't make sense to even try to do
this... so of course the answer was "it can't be done."
Now that Jack1, Jack2, tschack, jackdbus, and Jack3(?) are
all "officially" considered parallel implementations -- the
game changes for the distros.

Because it's libjack0 (and not jackd) that needs to be
virtual, it's not simple/trivial to do.  Neither is it a
common thing to do.  It also requires that *all* Jack
implementations be packaged in a way that's compatible (i.e.
patches to redirect libs).  It also means that the packaging
system won't be able to protect the user from a bad
upgrade/downgrade situation.  (Jack assures a
binary-compatable upgrade, but not a downgrade.)

That said, the discussion for Debian is now here:

     http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-April/008847.html
     http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-April/008854.html

Thanks,
Gabriel

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