23 Jan
2017
23 Jan
'17
3:22 p.m.
Hi,
after some research and help from the ffado list i think that the JACK 2's
firewire backend implementation does not honor the -d command line flag to
set a specific interface.
The effect is that when multiple devices are present, no matter what -d is
set to, all devices are aggregated. In most cases this fine and wanted.
However there is no warning or error message for bogus -dhw arguments and
it's not possible to start one specific interface only without
workarounds.
With the following diff (just 3 lines from JACK 1 codebase) it works as
expected, even using guid:xxx (which is a very nice feature).
Please review and consider merge.
Thanks,
Thomas
8:11 a.m.
On Tue, January 24, 2017 14:45, Adrian Knoth wrote:
On 01/23/2017 11:21 PM, Thomas Brand wrote:
thank you Adi!
A related note or rather a question popped up when i visited the pull
requests and issues entries for JACK 2 on github. Some of which are
several years old even if they sound critical, seemingly nobody cares
about them. I wondered why? Some look "merge"-ready without side-effects.
Best regards
Thomas
With the following diff (just 3 lines from JACK 1
codebase) it works as
expected, even using guid:xxx (which is a very nice feature). Please
review and consider merge.
Thanks for the patch, applied and pushed.
2:02 p.m.
On Tue, Jan 24, 2017 at 04:10:30PM +0100, Thomas Brand wrote:
I tried to go over them recently. Wherever trivial and correct, I've
merged them.
With others, I failed to understand all the implications and hence
didn't feel comfortable merging them, especially since I've lost touch
with the codebase over the last years.
And then there's this whole category of OSX. I don't know what the
situation there is, but it seems that Sierra changed the device API and
jack no longer works? Or maybe I'm reading this wrong?
Let me CC sletz for his view. I haven't seen him lately neither, maybe
also swamped with work.
That said, if you want to provide code reviews on the PRs, please go
ahead and mark those that look good to you. Then re-assign to me, and
I'll merge them in. The more eyes the merrier.
Cheers
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
Thanks for the
patch, applied and pushed.
thank you Adi!
A related note or rather a question popped up when i visited the pull
requests and issues entries for JACK 2 on github. Some of which are
several years old even if they sound critical, seemingly nobody cares
about them. I wondered why? Some look "merge"-ready without side-effects.
25 Jan
25 Jan
8:31 a.m.
On Tue, January 24, 2017 22:02, Adrian Knoth wrote:
And then there's this whole category of OSX. I
don't know what the
situation there is, but it seems that Sierra changed the device API and
jack no longer works? Or maybe I'm reading this wrong?
Let me CC sletz for his view. I haven't seen him lately neither, maybe
also swamped with work.
That said, if you want to provide code reviews on the PRs, please go
ahead and mark those that look good to you. Then re-assign to me, and I'll
merge them in. The more eyes the merrier.
I don't think i could do that in a nice way for pull requests since i've
only a very rough insight in JACK 2's code base.
However i could possibly help to categorize issues by labels.
Please have a look at this example:
https://github.com/andrewrk/libsoundio/issues
I think it makes great use of labels to get a quick overview if an issue
is a bug or a feature or related to OSX etc. The first step would be to
define a set of labels.
What is the general opinion, would that help in any ways? Could it help to
plan releases too (using milestones)?
Greetings
Thomas
8:37 a.m.
Not much time for JACK2 right now. Merging big PR is almost impossible if they affect
common code and cannot be tested on OS X and Windows. PR that deal with limited/easy to
review changes or Linux/ALSA specific ones can possibly be merged. PR review is a good
idea, but I would prefer to keep an eye on final merge...
The reasonable goal for me will be to finally do a official jackdmp 1.9.1 release,
hopefully in february.
Stéphane
Le 25 janv. 2017 à 16:29, Thomas Brand
<tom(a)trellis.ch> a écrit :
On Tue, January 24, 2017 22:02, Adrian Knoth wrote:
And then there's this whole category of OSX.
I don't know what the
situation there is, but it seems that Sierra changed the device API and
jack no longer works? Or maybe I'm reading this wrong?
Let me CC sletz for his view. I haven't seen him lately neither, maybe
also swamped with work.
That said, if you want to provide code reviews on the PRs, please go
ahead and mark those that look good to you. Then re-assign to me, and I'll
merge them in. The more eyes the merrier.
I don't think i could do that in a nice way for pull requests since i've
only a very rough insight in JACK 2's code base.
However i could possibly help to categorize issues by labels.
Please have a look at this example:
https://github.com/andrewrk/libsoundio/issues
I think it makes great use of labels to get a quick overview if an issue
is a bug or a feature or related to OSX etc. The first step would be to
define a set of labels.
What is the general opinion, would that help in any ways? Could it help to
plan releases too (using milestones)?
Greetings
Thomas
8:47 a.m.
On Wed, January 25, 2017 16:37, Stéphane Letz wrote:
Not much time for JACK2 right now. Merging big PR is
almost impossible if
they affect common code and cannot be tested on OS X and Windows. PR that
deal with limited/easy to review changes or Linux/ALSA specific ones can
possibly be merged. PR review is a good idea, but I would prefer to keep
an eye on final merge...
The reasonable goal for me will be to finally do a official jackdmp 1.9.1
release, hopefully in february.
Stéphane
That sounds good!
Windows and OSX testing: wouldn't it be easy if Windows and OSX users
could get a "nightly" build of bleeding edge JACK2 to actually test it? If
that would happen it would be safer to assume that merged PRs will not
pose any problems on these platforms when the effective release takes
place.
Having a continuous build system would also help to not have peaks for big
releases, they would "just" be on out of a linear series.
Ardour switched to this kind of build system some time ago (others already
have it) and after the inital work i'm practically sure it would help the
mid- to longterm development of JACK. Let me know it this is BS :)
Greetings
Thomas
8:58 a.m.
Le 25 janv. 2017 à 16:46, Thomas Brand
<tom(a)trellis.ch> a écrit :
On Wed, January 25, 2017 16:37, Stéphane Letz wrote:
It is not BS it takes *time* to put in practice….
Stéphane
Not much time for JACK2 right now. Merging big PR
is almost impossible if
they affect common code and cannot be tested on OS X and Windows. PR that
deal with limited/easy to review changes or Linux/ALSA specific ones can
possibly be merged. PR review is a good idea, but I would prefer to keep
an eye on final merge...
The reasonable goal for me will be to finally do a official jackdmp 1.9.1
release, hopefully in february.
Stéphane
That sounds good!
Windows and OSX testing: wouldn't it be easy if Windows and OSX users
could get a "nightly" build of bleeding edge JACK2 to actually test it? If
that would happen it would be safer to assume that merged PRs will not
pose any problems on these platforms when the effective release takes
place.
Having a continuous build system would also help to not have peaks for big
releases, they would "just" be on out of a linear series.
Ardour switched to this kind of build system some time ago (others already
have it) and after the inital work i'm practically sure it would help the
mid- to longterm development of JACK. Let me know it this is BS :)
Greetings
Thomas
3050
days inactive
3052
days old
jackaudio@lists.linuxaudio.org
7 comments
3 participants
participants (3)
-
Adrian Knoth -
Stéphane Letz -
Thomas Brand