6:09 a.m.
On Sun, December 10, 2017 14:03, Filipe Coelho wrote:
On 10.12.2017 12:24, Thomas Brand wrote:
+1 for windows build! so that we have the same shiny version on linux and
windows. I hope that non-critical pull-requests will find the way into the
release.
Cheers
Thomas
Can we get a non-RC release for X-Mas, please?
I don't see why not :)
I was trying to get windows builds working, but got sidetracked with
other stuff. The release notes are already done, I will do this soon.
6:11 a.m.
On 10.12.2017 14:09, Thomas Brand wrote:
On Sun, December 10, 2017 14:03, Filipe Coelho wrote:
I think I was not clear enough.
I was not able to get windows builds. I don't even got to update my
mingw build.
1.9.12 is kinda tagged already (just not officially).
So 1.9.12 *will not have windows or macOS builds*.
Maybe next time, but focus right now goes on the source tarball for the
linux distros.
On 10.12.2017 12:24, Thomas Brand wrote:
+1 for windows build! so that we have the same shiny version on linux and
windows. I hope that non-critical pull-requests will find the way into the
release. Can we get a non-RC release for X-Mas, please?
I don't see why not :)
I was trying to get windows builds working, but got sidetracked with
other stuff. The release notes are already done, I will do this soon.
6:19 a.m.
On Sun, December 10, 2017 14:11, Filipe Coelho wrote:
On 10.12.2017 14:09, Thomas Brand wrote:
hm, ok ..
I'm speculating that
"Kjetil Matheussen" <k.s.matheussen(a)gmail.com>
could help you there. It would make most sense to have at least one other
supported platform so that it's "multi"-platform. For an audio abstraction
layer like JACK it's even more important since multi-platform makes the
abstraction complete.
Cheers
On Sun, December 10, 2017 14:03, Filipe Coelho
wrote:
I think I was not clear enough.
I was not able to get windows builds. I don't even got to update my
mingw build. 1.9.12 is kinda tagged already (just not officially).
So 1.9.12 *will not have windows or macOS builds*.
On 10.12.2017 12:24, Thomas Brand wrote:
+1 for windows build! so that we have the same shiny version on linux
and windows. I hope that non-critical pull-requests will find the way
into the release. Can we get a non-RC release for X-Mas, please?
I don't see why not :)
I was trying to get windows builds working, but got sidetracked with
other stuff. The release notes are already done, I will do this soon.
Maybe next time, but focus right now goes on the source tarball for the
linux distros.
6:24 a.m.
On 10.12.2017 14:19, Thomas Brand wrote:
On Sun, December 10, 2017 14:11, Filipe Coelho wrote:
True, but I don't agree with some of the ideas Kjetil proposed regarding
windows builds.
I do not want to do a refactoring of jack2 code.
So likely I will end up doing the windows builds myself.
Something for next year.
I think I was not clear enough.
I was not able to get windows builds. I don't even got to update my
mingw build. 1.9.12 is kinda tagged already (just not officially).
So 1.9.12 *will not have windows or macOS builds*.
hm, ok ..
I'm speculating that
"Kjetil Matheussen" <k.s.matheussen(a)gmail.com>
could help you there. It would make most sense to have at least one other
supported platform so that it's "multi"-platform. For an audio abstraction
layer like JACK it's even more important since multi-platform makes the
abstraction complete.
Cheers
6:29 a.m.
On Sun, December 10, 2017 14:24, Filipe Coelho wrote:
On 10.12.2017 14:19, Thomas Brand wrote:
I don't know what Kjetil proposed but so or so it should be possible in
the future to use sort of an official build tool chain for windows (and
mac, probably less cumbersome since it's ~POSIX) so that anyone interested
can build.
2 cent
On Sun, December 10, 2017 14:11, Filipe Coelho
wrote:
True, but I don't agree with some of the ideas Kjetil proposed regarding
windows builds. I do not want to do a refactoring of jack2 code.
So likely I will end up doing the windows builds myself.
Something for next year.
I think I was not clear enough.
I was not able to get windows builds. I don't even got to update my
mingw build. 1.9.12 is kinda tagged already (just not officially). So
1.9.12 *will not have windows or macOS builds*.
hm, ok .. I'm speculating that
"Kjetil Matheussen" <k.s.matheussen(a)gmail.com>
could help you there. It would make most sense to have at least one
other supported platform so that it's "multi"-platform. For an audio
abstraction layer like JACK it's even more important since
multi-platform makes the abstraction complete. Cheers
6:31 a.m.
On 10.12.2017 14:28, Thomas Brand wrote:
On Sun, December 10, 2017 14:24, Filipe Coelho wrote:
Yes, I agree completely.
And this is how I plan to do these builds.
No commercial IDEs to build stuff (Visual Studio or XCode), but use the
provided waf system instead.
There were quite a few commits (coming from pull requests) regarding
this, but I haven't tested them too much.
On 10.12.2017 14:19, Thomas Brand wrote:
I don't know what Kjetil proposed but so or so it should be possible in
the future to use sort of an official build tool chain for windows (and
mac, probably less cumbersome since it's ~POSIX) so that anyone interested
can build.
2 cent On Sun, December 10, 2017 14:11, Filipe Coelho
wrote:
True, but I don't agree with some of the ideas Kjetil proposed regarding
windows builds. I do not want to do a refactoring of jack2 code.
So likely I will end up doing the windows builds myself.
Something for next year.
I think I was not clear enough.
I was not able to get windows builds. I don't even got to update my
mingw build. 1.9.12 is kinda tagged already (just not officially). So
1.9.12 *will not have windows or macOS builds*.
hm, ok .. I'm speculating that
"Kjetil Matheussen" <k.s.matheussen(a)gmail.com>
could help you there. It would make most sense to have at least one
other supported platform so that it's "multi"-platform. For an audio
abstraction layer like JACK it's even more important since
multi-platform makes the abstraction complete. Cheers
6:34 a.m.
On Sun, December 10, 2017 14:31, Filipe Coelho wrote:
On 10.12.2017 14:28, Thomas Brand wrote:
nice..
as an easy vision to understand, when calling jackaudio.org it'd be
inviting to see trustful direct download links for all major platforms,
same version :)
enjoy the weekend
On Sun, December 10, 2017 14:24, Filipe Coelho
wrote:
Yes, I agree completely.
And this is how I plan to do these builds.
No commercial IDEs to build stuff (Visual Studio or XCode), but use the
provided waf system instead. There were quite a few commits (coming from
pull requests) regarding this, but I haven't tested them too much. On 10.12.2017 14:19, Thomas Brand wrote:
I don't know what Kjetil proposed but so or so it should be possible in
the future to use sort of an official build tool chain for windows
(and
mac, probably less cumbersome since it's ~POSIX) so that anyone
interested can build. 2 cent
On Sun, December 10, 2017 14:11, Filipe Coelho
wrote:
> I think I was not clear enough.
>
>
>
>
> I was not able to get windows builds. I don't even got to update
> my mingw build. 1.9.12 is kinda tagged already (just not
> officially). So 1.9.12 *will not have windows or macOS builds*.
>
>
>
hm, ok .. I'm speculating that "Kjetil Matheussen"
<k.s.matheussen(a)gmail.com>
could help you there. It would make most sense to have at least one
other supported platform so that it's "multi"-platform. For an
audio abstraction layer like JACK it's even more important since
multi-platform makes the abstraction complete. Cheers
True, but I don't agree with some of the ideas Kjetil proposed
regarding windows builds. I do not want to do a refactoring of jack2
code.
So likely I will end up doing the windows builds myself.
Something for next year.
12:16 p.m.
On 12/10/2017 02:34 PM, Thomas Brand wrote:
On Sun, December 10, 2017 14:31, Filipe Coelho wrote:
Just having the files hosted in a sensible place would be
marvellous.
For example on the GitHub releases/tags, then linking to them would
be the trivial part.
On 10.12.2017 14:28, Thomas Brand wrote:
nice..
as an easy vision to understand, when calling jackaudio.org it'd be
inviting to see trustful direct download links for all major platforms,
same version :)
enjoy the weekend On Sun, December 10, 2017 14:24, Filipe Coelho
wrote:
Yes, I agree completely.
And this is how I plan to do these builds.
No commercial IDEs to build stuff (Visual Studio or XCode), but use the
provided waf system instead. There were quite a few commits (coming from
pull requests) regarding this, but I haven't tested them too much. On 10.12.2017 14:19, Thomas Brand wrote:
> On Sun, December 10, 2017 14:11, Filipe Coelho wrote:
>
>
>> I think I was not clear enough.
>>
>>
>>
>>
>> I was not able to get windows builds. I don't even got to update
>> my mingw build. 1.9.12 is kinda tagged already (just not
>> officially). So 1.9.12 *will not have windows or macOS builds*.
>>
>>
>>
> hm, ok .. I'm speculating that "Kjetil Matheussen"
> <k.s.matheussen(a)gmail.com>
> could help you there. It would make most sense to have at least one
> other supported platform so that it's "multi"-platform. For an
> audio abstraction layer like JACK it's even more important since
> multi-platform makes the abstraction complete. Cheers
>
True, but I don't agree with some of the ideas Kjetil proposed
regarding windows builds. I do not want to do a refactoring of jack2
code.
So likely I will end up doing the windows builds myself.
Something for next year.
I don't know what Kjetil proposed but so or so it should be possible in
the future to use sort of an official build tool chain for windows
(and
mac, probably less cumbersome since it's ~POSIX) so that anyone
interested can build. 2 cent
6:33 a.m.
On Sun, Dec 10, 2017 at 2:19 PM, Thomas Brand <tom(a)trellis.ch> wrote:
On Sun, December 10, 2017 14:11, Filipe Coelho wrote:
The windows versions of Radium has included a custom version of jack 1.9.12
since october. If you want to manually upgrade jack on your windows
machine, it might work just to replace the old jack files with the one
included in Radium. As I've expressed before, the installer should be
removed, and jack should be installed locally for all programs wanting to
use it. This will not break any programs. Radium partly does this already.
Radium first checks if Jack is installed globally, and if not, it uses the
version of jack installed in the "jack_local" directory. But for this to
work properly with more than one client, jack needs to inform where the
currently used libraries are placed so that different clients aren't using
different versions of the jack libraries.
On 10.12.2017 14:09, Thomas Brand wrote:
hm, ok ..
I'm speculating that
"Kjetil Matheussen" <k.s.matheussen(a)gmail.com>
could help you there. It would make most sense to have at least one other
supported platform so that it's "multi"-platform. For an audio abstraction
layer like JACK it's even more important since multi-platform makes the
abstraction complete.
Cheers
On Sun, December 10, 2017 14:03, Filipe Coelho
wrote:
I think I was not clear enough.
I was not able to get windows builds. I don't even got to update my
mingw build. 1.9.12 is kinda tagged already (just not officially).
So 1.9.12 *will not have windows or macOS builds*.
On 10.12.2017 12:24, Thomas Brand wrote:
> Can we get a non-RC release for X-Mas, please?
>
>
I don't see why not :)
I was trying to get windows builds working, but got sidetracked with
other stuff. The release notes are already done, I will do this soon.
+1 for windows build! so that we have the same shiny version on linux
and windows. I hope that non-critical pull-requests will find the way
into the release.
6:39 a.m.
On Sun, December 10, 2017 14:33, Kjetil Matheussen wrote:
On Sun, Dec 10, 2017 at 2:19 PM, Thomas Brand
<tom(a)trellis.ch> wrote:
This sound sort of crazy, but why not just wrap an nsis installer around
your 1.9.12 build?
On Sun, December 10, 2017 14:11, Filipe Coelho
wrote:
The windows versions of Radium has included a custom version of jack
1.9.12
since october. If you want to manually upgrade jack on your windows
machine, it might work just to replace the old jack files with the one
included in Radium. As I've expressed before, the installer should be
removed, and jack should be installed locally for all programs wanting to
use it. This will not break any programs. Radium partly does this
already. Radium first checks if Jack is installed globally, and if not, it
uses the version of jack installed in the "jack_local" directory. But for
this to work properly with more than one client, jack needs to inform
where the currently used libraries are placed so that different clients
aren't using different versions of the jack libraries.
On 10.12.2017 14:09, Thomas Brand wrote:
hm, ok .. I'm speculating that
"Kjetil Matheussen" <k.s.matheussen(a)gmail.com>
could help you there. It would make most sense to have at least one
other supported platform so that it's "multi"-platform. For an audio
abstraction layer like JACK it's even more important since
multi-platform makes the abstraction complete. Cheers
On Sun, December 10, 2017 14:03, Filipe Coelho
wrote:
> On 10.12.2017 12:24, Thomas Brand wrote:
>
>
>
>> Can we get a non-RC release for X-Mas, please?
>>
>>
>>
> I don't see why not :)
>
>
>
>
> I was trying to get windows builds working, but got sidetracked
> with other stuff. The release notes are already done, I will do
> this soon.
>
+1 for windows build! so that we have the same shiny version on
linux and windows. I hope that non-critical pull-requests will find
the way into the release.
I think I was not clear enough.
I was not able to get windows builds. I don't even got to update my
mingw build. 1.9.12 is kinda tagged already (just not officially). So
1.9.12 *will not have windows or macOS builds*.
6:42 a.m.
On Sun, Dec 10, 2017 at 2:39 PM, Thomas Brand <tom(a)trellis.ch> wrote:
On Sun, December 10, 2017 14:33, Kjetil Matheussen
wrote:
advantage of installing jack globally? If all jack programs provide jack
themselves, the user can easily choose which version of jack to run, just
by starting qjackctl (or a similar program) compiled for the version of
jack you want to use.
On Sun, Dec 10, 2017 at 2:19 PM, Thomas Brand
<tom(a)trellis.ch> wrote:
it
On Sun, December 10, 2017 14:11, Filipe Coelho
wrote:
The windows versions of Radium has included a custom version of jack
1.9.12
since october. If you want to manually upgrade jack on your windows
machine, it might work just to replace the old jack files with the one
included in Radium. As I've expressed before, the installer should be
removed, and jack should be installed locally for all programs wanting to
use it. This will not break any programs. Radium partly does this
already. Radium first checks if Jack is installed globally, and if not, On 10.12.2017 14:09, Thomas Brand wrote:
> On Sun, December 10, 2017 14:03, Filipe Coelho wrote:
>
>
>> On 10.12.2017 12:24, Thomas Brand wrote:
>>
>>
>>
>>> Can we get a non-RC release for X-Mas, please?
>>>
>>>
>>>
>> I don't see why not :)
>>
>>
>>
>>
>> I was trying to get windows builds working, but got sidetracked
>> with other stuff. The release notes are already done, I will do
>> this soon.
>>
> +1 for windows build! so that we have the same shiny version on
> linux and windows. I hope that non-critical pull-requests will find
> the way into the release.
I think I was not clear enough.
I was not able to get windows builds. I don't even got to update my
mingw build. 1.9.12 is kinda tagged already (just not officially). So
1.9.12 *will not have windows or macOS builds*.
hm, ok .. I'm speculating that
"Kjetil Matheussen" <k.s.matheussen(a)gmail.com>
could help you there. It would make most sense to have at least one
other supported platform so that it's "multi"-platform. For an audio
abstraction layer like JACK it's even more important since
multi-platform makes the abstraction complete. Cheers
uses the version of jack installed in the
"jack_local" directory. But for
this to work properly with more than one client, jack needs to inform
where the currently used libraries are placed so that different clients
aren't using different versions of the jack libraries.
This sound sort of crazy, but why not just wrap an nsis installer around
your 1.9.12 build?
If you know how, please do. But it's the wrong way forward. What's the
6:48 a.m.
On Sun, December 10, 2017 14:42, Kjetil Matheussen wrote:
On Sun, Dec 10, 2017 at 2:39 PM, Thomas Brand
<tom(a)trellis.ch> wrote:
The JACK API didn't change much so it makes sense to have that server as a
system-wide library IMHO. Not sure about ABI. This won't prevent to
package it along with the application, but this should be looked at as a
special case.
I've done some stuff with nsis in the past, it's pretty straight forward.
I can provide the install script if needed at some point in time.
Greetings
On Sun, December 10, 2017 14:33, Kjetil
Matheussen wrote:
advantage of installing jack globally? If all jack programs provide jack
themselves, the user can easily choose which version of jack to run, just
by starting qjackctl (or a similar program) compiled for the version of
jack you want to use.
On Sun, Dec 10, 2017 at 2:19 PM, Thomas Brand
<tom(a)trellis.ch> wrote:
it
On Sun, December 10, 2017 14:11, Filipe Coelho
wrote:
> On 10.12.2017 14:09, Thomas Brand wrote:
>
>
>
>> On Sun, December 10, 2017 14:03, Filipe Coelho wrote:
>>
>>
>>
>>> On 10.12.2017 12:24, Thomas Brand wrote:
>>>
>>>
>>>
>>>
>>>> Can we get a non-RC release for X-Mas, please?
>>>>
>>>>
>>>>
>>>>
>>> I don't see why not :)
>>>
>>>
>>>
>>>
>>>
>>> I was trying to get windows builds working, but got
>>> sidetracked with other stuff. The release notes are already
>>> done, I will do this soon.
>>>
>> +1 for windows build! so that we have the same shiny version on
>> linux and windows. I hope that non-critical pull-requests will
>> find the way into the release.
>
> I think I was not clear enough.
>
>
>
>
> I was not able to get windows builds. I don't even got to update
> my mingw build. 1.9.12 is kinda tagged already (just not
> officially). So 1.9.12 *will not have windows or macOS builds*.
>
>
>
hm, ok .. I'm speculating that "Kjetil Matheussen"
<k.s.matheussen(a)gmail.com>
could help you there. It would make most sense to have at least one
other supported platform so that it's "multi"-platform. For an
audio abstraction layer like JACK it's even more important since
multi-platform makes the abstraction complete. Cheers
The windows versions of Radium has included a custom version of jack
1.9.12
since october. If you want to manually upgrade jack on your windows
machine, it might work just to replace the old jack files with the
one included in Radium. As I've expressed before, the installer should
be removed, and jack should be installed locally for all programs
wanting to use it. This will not break any programs. Radium partly
does this already. Radium first checks if Jack is installed globally,
and if not, uses the version of jack installed in the
"jack_local" directory. But
for this to work properly with more than one client, jack needs to
inform where the currently used libraries are placed so that different
clients aren't using different versions of the jack libraries.
This sound sort of crazy, but why not just wrap an nsis installer
around your 1.9.12 build?
If you know how, please do. But it's the wrong way forward. What's the
6:56 a.m.
On Sun, Dec 10, 2017 at 2:48 PM, Thomas Brand <tom(a)trellis.ch> wrote:
On Sun, December 10, 2017 14:42, Kjetil Matheussen
wrote:
My point is that when the jack server is started, it writes the path to the
jack libraries somewhere global, and removes it when it shuts down. This
way all clients will use the same libraries.
On Sun, Dec 10, 2017 at 2:39 PM, Thomas Brand
<tom(a)trellis.ch> wrote:
The JACK API didn't change much so it makes sense to have that server as a
system-wide library IMHO. Not sure about ABI. This won't prevent to
package it along with the application, but this should be looked at as a
special case.
I've done some stuff with nsis in the past, it's pretty straight forward.
I can provide the install script if needed at some point in time.
Greetings
On Sun, December 10, 2017 14:33, Kjetil
Matheussen wrote:
advantage of installing jack globally? If all jack programs provide jack
themselves, the user can easily choose which version of jack to run, just
by starting qjackctl (or a similar program) compiled for the version of
jack you want to use.
On Sun, Dec 10, 2017 at 2:19 PM, Thomas Brand
<tom(a)trellis.ch> wrote:
> On Sun, December 10, 2017 14:11, Filipe Coelho wrote:
>
>
>> On 10.12.2017 14:09, Thomas Brand wrote:
>>
>>
>>
>>> On Sun, December 10, 2017 14:03, Filipe Coelho wrote:
>>>
>>>
>>>
>>>> On 10.12.2017 12:24, Thomas Brand wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Can we get a non-RC release for X-Mas, please?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> I don't see why not :)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I was trying to get windows builds working, but got
>>>> sidetracked with other stuff. The release notes are already
>>>> done, I will do this soon.
>>>>
>>> +1 for windows build! so that we have the same shiny version on
>>> linux and windows. I hope that non-critical pull-requests will
>>> find the way into the release.
>>
>> I think I was not clear enough.
>>
>>
>>
>>
>> I was not able to get windows builds. I don't even got to update
>> my mingw build. 1.9.12 is kinda tagged already (just not
>> officially). So 1.9.12 *will not have windows or macOS builds*.
>>
>>
>>
>
> hm, ok .. I'm speculating that "Kjetil Matheussen"
> <k.s.matheussen(a)gmail.com>
> could help you there. It would make most sense to have at least one
> other supported platform so that it's "multi"-platform. For an
> audio abstraction layer like JACK it's even more important since
> multi-platform makes the abstraction complete. Cheers
>
>
>
The windows versions of Radium has included a custom version of jack
1.9.12
since october. If you want to manually upgrade jack on your windows
machine, it might work just to replace the old jack files with the
one included in Radium. As I've expressed before, the installer should
be removed, and jack should be installed locally for all programs
wanting to use it. This will not break any programs. Radium partly
does this already. Radium first checks if Jack is installed globally,
and if not,
it
uses the version of jack installed in the
"jack_local" directory. But
for this to work properly with more than one client, jack needs to
inform where the currently used libraries are placed so that different
clients aren't using different versions of the jack libraries.
This sound sort of crazy, but why not just wrap an nsis installer
around your 1.9.12 build?
If you know how, please do. But it's the wrong way forward. What's the
7:09 a.m.
My point is that when the jack server is started, it writes the path to
the jack libraries somewhere global, and removes it when it shuts down.
This way all clients will use the same libraries.
And to clarify some more: The only difference for the user compared to the
current situation, is that the user doesn't have to install jack. If the
user wants to upgrade jack, the user only have to download the latest
version of qjackctl (or similar software). Normal clients doesn't have to
include the jack libraries, only programs that wants to start the server
have to include the jack libraries.
7:13 a.m.
On Sun, Dec 10, 2017 at 3:09 PM, Kjetil Matheussen <k.s.matheussen(a)gmail.com
And of course, it should be like this for Linux and OSX as well. I'm mainly
just proposing this as a way to work around the problem with the current
installer in windows which (most probably) can't be cross-compiled.
wrote:
My point is that when the jack server is started,
it writes the path to
the jack libraries somewhere global, and removes it when it shuts down.
This way all clients will use the same libraries.
And to clarify some more: The only difference for the user compared to the
current situation, is that the user doesn't have to install jack. If the
user wants to upgrade jack, the user only have to download the latest
version of qjackctl (or similar software). Normal clients doesn't have to
include the jack libraries, only programs that wants to start the server
have to include the jack libraries.
11 Dec
11 Dec
5:04 a.m.
On Sun, Dec 10, 2017 at 3:13 PM, Kjetil Matheussen <k.s.matheussen(a)gmail.com
wrote:
>
>
> On Sun, Dec 10, 2017 at 3:09 PM, Kjetil Matheussen <
> k.s.matheussen(a)gmail.com wrote:
>
>>
>>> My point is that when the jack server is started, it writes the path to
>>> the jack libraries somewhere global, and removes it when it shuts down.
>>> This way all clients will use the same libraries.
>>>
>>>
>> And to clarify some more: The only difference for the user compared to
>> the current situation, is that the user doesn't have to install jack. If
>> the user wants to upgrade jack, the user only have to download the latest
>> version of qjackctl (or similar software). Normal clients doesn't have to
>> include the jack libraries, only programs that wants to start the server
>> have to include the jack libraries.
>>
>>
> And of course, it should be like this for Linux and OSX as well. I'm
> mainly just proposing this as a way to work around the problem with the
> current installer in windows which (most probably) can't be cross-compiled.
>
>
Sorry for replying to myself again. Just to avoid misunderstanding,
although this is proposed as a workaround, it's also a far better solution
the the current one. If anyone thinks this is a bad idea, I would be
interested in knowing why.
10 Dec
10 Dec
6:51 a.m.
By the way, here is my Makefile for compiling cross-compiling jack for
windows under mxe:
http://users.notam02.no/~kjetism/Makefile.mingw.jack_local
Just install mxe first, and then run Makefile -f Makefile.mingw.jack
6:39 a.m.
On Sun, Dec 10, 2017 at 2:33 PM, Kjetil Matheussen <k.s.matheussen(a)gmail.com
This will not break any programs.
Not sure what I was thinking here. It might not be necessary to break
programs, i.e. they have to be recompiled for the new jack, but considering
how few programs using jack on windows, it's probably not very important to
care about backwards compatibility.
wrote:
2567
days inactive
2568
days old
jackaudio@lists.linuxaudio.org
19 comments
4 participants
participants (4)
-
Filipe Coelho -
Kjetil Matheussen -
Markus Seeber -
Thomas Brand