RFE regarding persistent information on Jack connections
Carl H Janson
First of all, thanks for providing JNA Jack. We (me on behalf of HD SoundLab AS) have been evaluating the AudioServers lib for a month or so, and are happy to report that integration with our own software was easy (a couple of hours work), and that the solution seems to offer a rock solid context for access to Jack from a Java audio application. Latency when using Jack is dramatically improved compared to the standard JavaSound api. On our MacBook pro , Jack provides acceptable lip-sync when watching video.
So far we are mostly concerned with Jack on the osx, as this particular Jack version offers the JackRouter that importantly can be used to capture all audio streams because it can be setup in the osx control panel as a virtual audio output device, literally leaving all control of audio to Jack. To our understanding, this feature – JackRouter - is missing in the Linux and Windows versions of Jack.
For the osx platform, we have written a “log” of our findings in this regard here: http://www.soundpimp.com/audioblog/combining-jack-and-soundflower-on-mac-osx/. Here is BTW also discussions about using SoundFlower (Bed) in order to capture all audio streams running on the computer, as an alternative to capturing “one stream at the time”. This is a need because SoundPimp is a general audio enhancer supposed to work on all sound running on the computer. It means Jack is used to flood all audio streams into SoundPimp, then send to output (whatever). To our understanding, the normal use of Jack is slightly different, i.e. to connect audio app A with audio app B.
SoundPimp is a product aiming to serve the audio-layman, and should preferably “just work” on all audio once installed and started, including but not limited to the acceptance and handling of status changes. Simplicity is however not the case p.t. as the configuration (of Jack, not JNA Jack) is non-trivial, in particular because the user needs to do manual re-configuration of connections from the Jack Pilot (on OSX). In other words, the Jack system seems to lack a little when it comes to persistency and the identification and reporting of status changes. There are perhaps 3 main categories of changes in this context, e.g. start & stop & restart of:
1. The audio source (iTunes, Spotify…), be it restart of the application itself or the audio stream it provides.
2. The Jack server
3. Your own app, in our case: SoundPimp audio enhancer
As it seems, any persistency features must be a part of your own application, as there is nothing of the sort offered from Jack itself. What seems to be needed as enhancement to JNA Jack, if we understand things correctly, is perhaps the jack_port_get_connections from the C api, in order to retrieve connection state of various apps currently connected, so as to be able to restore it later whenever configuration change 1,2 or 3 has occurred. It means the bare minimum is to be able to create a list of all current connections, and then your own app can take care of persistency.
One alternative to jack_port_get_connections would be to get a list of all ports currently connected because port ID also contain connection names, however JNA Jack is seemingly only reporting “own” ports, not ports of other applications connected to Jack. Correct ?
We salute also the suggestion of Bill Brown for a ”listener” feature, see his emails from 9th of December 2011.
When “current “ status is known this way, then the next step is obviously to be able to programmatically connect from own app to any other connection. Is this a part of Jack and JNA Jack p.t. ?
Perhaps there is a “auto-reconnect” feature available from Jack that we have not seen, that will have the effect of reconnecting all other connections to own application subsequent to 1 above ?
So we have a few questions as exemplified here. We will also ask in the forum for Jack OSX since we are a little uncertain whether lack of functionality is pointing to Jack or to JNA Jack.
Looking forward to any comments.
Kind regards
Carl
Neil C Smith
Comments below.
On 16 January 2012 10:18, Carl H Janson <c...@hdsoundlab.com> wrote:
> First of all, thanks for providing JNA Jack. We (me on behalf of HD SoundLab
> AS) have been evaluating the AudioServers lib for a month or so, and are
> happy to report that integration with our own software was easy (a couple of
> hours work), and that the solution seems to offer a rock solid context for
> access to Jack from a Java audio application. Latency when using Jack is
> dramatically improved compared to the standard JavaSound api. On our MacBook
> pro , Jack provides acceptable lip-sync when watching video.
>
Thanks! Now you've got the AudioServer API integrated, you should
also try out the JavaSound server. Oliver Bown (Beads) has reported a
stable 512 sample buffersize in a coming version of Beads that uses
JAudioLibs servers. That might actually be good enough for your
purposes (if the routing side of it is possible?)
> So far we are mostly concerned with Jack on the osx, as this particular Jack
> version offers the JackRouter that importantly can be used to capture all
> audio streams because it can be setup in the osx control panel as a virtual
> audio output device, literally leaving all control of audio to Jack. To our
> understanding, this feature – JackRouter - is missing in the Linux and
> Windows versions of Jack.
>
This is possible in Linux (in a few different ways, as per normal!
:-)) No idea about Windows.
>
> For the osx platform, we have written a “log” of our findings in this regard
> here:
> http://www.soundpimp.com/audioblog/combining-jack-and-soundflower-on-mac-osx/.
> Here is BTW also discussions about using SoundFlower (Bed) in order to
> capture all audio streams running on the computer, as an alternative to
> capturing “one stream at the time”. This is a need because SoundPimp is a
> general audio enhancer supposed to work on all sound running on the
> computer. It means Jack is used to flood all audio streams into SoundPimp,
> then send to output (whatever). To our understanding, the normal use of Jack
> is slightly different, i.e. to connect audio app A with audio app B.
>
Be careful about claiming anything is a "normal use of JACK"! I've
seen a few emails on the jack-devel list jumped on for that recently.
Your usage is not that uncommon.
>
> SoundPimp is a product aiming to serve the audio-layman, and should
> preferably “just work” on all audio once installed and started, including
> but not limited to the acceptance and handling of status changes. Simplicity
> is however not the case p.t. as the configuration (of Jack, not JNA Jack) is
> non-trivial, in particular because the user needs to do manual
> re-configuration of connections from the Jack Pilot (on OSX). In other
> words, the Jack system seems to lack a little when it comes to persistency
> and the identification and reporting of status changes. There are perhaps 3
> main categories of changes in this context, e.g. start & stop & restart of:
>
>
>
> 1. The audio source (iTunes, Spotify…), be it restart of the
> application itself or the audio stream it provides.
>
> 2. The Jack server
>
> 3. Your own app, in our case: SoundPimp audio enhancer
>
> As it seems, any persistency features must be a part of your own
> application, as there is nothing of the sort offered from Jack itself. What
> seems to be needed as enhancement to JNA Jack, if we understand things
> correctly, is perhaps the jack_port_get_connections from the C api, in order
> to retrieve connection state of various apps currently connected, so as to
> be able to restore it later whenever configuration change 1,2 or 3 has
> occurred. It means the bare minimum is to be able to create a list of all
> current connections, and then your own app can take care of persistency.
>
That would be a valid RFE. Please enter a new issue here -
http://code.google.com/p/java-audio-utils/issues/list You'll need to
sign up for a Google Code account if you haven't got one. Enter the
signatures of the C functions you need mappings to, and possibly a
(short!) description of what you're trying to achieve or the C code
you're trying to emulate. Sorry, but I don't want to track issues and
RFE's in the mailing list.
>
> One alternative to jack_port_get_connections would be to get a list of all
> ports currently connected because port ID also contain connection names,
> however JNA Jack is seemingly only reporting “own” ports, not ports of other
> applications connected to Jack. Correct ?
>
What code are you using that seems to only report "own" ports?
Jack.getPorts(...) should return everything.
> We salute also the suggestion of Bill Brown for a ”listener” feature, see
> his emails from 9th of December 2011.
>
I agree. Either add to your RFE, or I'll file one myself for these.
This won't be your typical Java listener - it will be a direct mapping
of JACK's callback mechanism.
>
>
> When “current “ status is known this way, then the next step is obviously to
> be able to programmatically connect from own app to any other connection. Is
> this a part of Jack and JNA Jack p.t. ?
>
Already achievable using Jack.connect(...), etc. You need to use the
full port names (eg. client_name:port_name)
If you're using the AudioServer API, you will currently have to create
your own temporary client (without ports) to pass in to these
functions. See the code from the deprecated version of these for an
example. They are deprecated because you should only create one
temporary client and use it for all connecting.
A planned enhancement to the AudioServer API in the near future will
give direct access to the JackClient that it uses, so there will be no
further need to create an additional client.
>
> Perhaps there is a “auto-reconnect” feature available from Jack that we have
> not seen, that will have the effect of reconnecting all other connections to
> own application subsequent to 1 above ?
>
No.
>
> So we have a few questions as exemplified here. We will also ask in the
> forum for Jack OSX since we are a little uncertain whether lack of
> functionality is pointing to Jack or to JNA Jack.
>
Yes, for some use cases, particularly any that are specific to OSX,
try asking on the JACK list first. Once you've got code that will do
what you want in C, then file an RFE for anything that seems missing
in JNAJack. Anything that is an optional part of the API will take
longer, as I need to find a way of mapping these in JNA without
failing if they're not there.
Best wishes,
Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
Carl H Janson
Rgds
Carl
Hi Carl,
Comments below.
[Carl Henrik ] I have the ambition to look into this server as well, as time
allows.
> So far we are mostly concerned with Jack on the osx, as this particular
Jack
> version offers the JackRouter that importantly can be used to capture all
> audio streams because it can be setup in the osx control panel as a
virtual
> audio output device, literally leaving all control of audio to Jack. To
our
> understanding, this feature – JackRouter - is missing in the Linux and
> Windows versions of Jack.
>
This is possible in Linux (in a few different ways, as per normal!
:-)) No idea about Windows.
[Carl Henrik ] Any links or hints regarding these features on Linux is
appreciated.
>
> For the osx platform, we have written a “log” of our findings in this
regard
> here:
>
http://www.soundpimp.com/audioblog/combining-jack-and-soundflower-on-mac-osx
/.
> Here is BTW also discussions about using SoundFlower (Bed) in order to
> capture all audio streams running on the computer, as an alternative to
> capturing “one stream at the time”. This is a need because SoundPimp is a
> general audio enhancer supposed to work on all sound running on the
> computer. It means Jack is used to flood all audio streams into
SoundPimp,
> then send to output (whatever). To our understanding, the normal use of
Jack
> is slightly different, i.e. to connect audio app A with audio app B.
>
Be careful about claiming anything is a "normal use of JACK"! I've
seen a few emails on the jack-devel list jumped on for that recently.
Your usage is not that uncommon.
[Carl Henrik ] OK, if anything I wrote caused escalations, thanks for
notifying me. I am not intentionally stepping on other peoples toes here :-)
[Carl Henrik ] Actually, the getPorts seems to require knowledge of clients,
but this is exactly what we are searching ?
For example, the outs variable of method JackAudioServer.autoConnect() only
contains 2 strings even if I have connected all sorts of audio applications
to the Jack server. Anyway, filed a RFE requesting
jack_port_get_connections.
> We salute also the suggestion of Bill Brown for a ”listener” feature, see
> his emails from 9th of December 2011.
>
I agree. Either add to your RFE, or I'll file one myself for these.
This won't be your typical Java listener - it will be a direct mapping
of JACK's callback mechanism.
[Carl Henrik ] Better that you do that.
>
>
> When “current “ status is known this way, then the next step is obviously
to
> be able to programmatically connect from own app to any other connection.
Is
> this a part of Jack and JNA Jack p.t. ?
>
Already achievable using Jack.connect(...), etc. You need to use the
full port names (eg. client_name:port_name)
[Carl Henrik ] Yes.
If you're using the AudioServer API, you will currently have to create
your own temporary client (without ports) to pass in to these
functions. See the code from the deprecated version of these for an
example. They are deprecated because you should only create one
temporary client and use it for all connecting.
A planned enhancement to the AudioServer API in the near future will
give direct access to the JackClient that it uses, so there will be no
further need to create an additional client.
[Carl Henrik ] I am going to await the new version, then.
>
> Perhaps there is a “auto-reconnect” feature available from Jack that we
have
> not seen, that will have the effect of reconnecting all other connections
to
> own application subsequent to 1 above ?
>
No.
>
> So we have a few questions as exemplified here. We will also ask in the
> forum for Jack OSX since we are a little uncertain whether lack of
> functionality is pointing to Jack or to JNA Jack.
>
Yes, for some use cases, particularly any that are specific to OSX,
try asking on the JACK list first. Once you've got code that will do
what you want in C, then file an RFE for anything that seems missing
in JNAJack. Anything that is an optional part of the API will take
longer, as I need to find a way of mapping these in JNA without
failing if they're not there.
[Carl Henrik ] yes, I have dialogue also with the osx team, but have been
hesitant to start running around in the various user groups prior to having
a minimum of understanding of Jack in all its variants.
Best wishes,
Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
--
JAudioLibs - http://code.google.com/p/java-audio-utils/
You received this message because you are subscribed to the Google
Groups "JAudioLibs" group.
To post to this group, send email to jaudi...@googlegroups.com
To unsubscribe from this group, send email to
jaudiolibs+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jaudiolibs?hl=en?hl=en
Neil C Smith
On 17 January 2012 10:40, Carl H Janson <c...@hdsoundlab.com> wrote:
> Thanks Neil. I filed RFE. See also a few comments below.
Noted and accepted.
>
> This is possible in Linux (in a few different ways, as per normal!
> :-)) No idea about Windows.
> [Carl Henrik ] Any links or hints regarding these features on Linux is
> appreciated.
>
There is at least one ALSA -> JACK bridge that allows the default ALSA
output to route through JACK. I think there is also an output for
PulseAudio that will route through JACK.
> Be careful about claiming anything is a "normal use of JACK"! I've
> seen a few emails on the jack-devel list jumped on for that recently.
> Your usage is not that uncommon.
> [Carl Henrik ] OK, if anything I wrote caused escalations, thanks for
> notifying me. I am not intentionally stepping on other peoples toes here :-)
>
It was nothing *you* wrote! I was just saying - don't assume your use
case is unusual. JACK is used in lots of different scenarios.
> What code are you using that seems to only report "own" ports?
> Jack.getPorts(...) should return everything.
> [Carl Henrik ] Actually, the getPorts seems to require knowledge of clients,
> but this is exactly what we are searching ?
Not true! Anything in the Jack class (as opposed to JackClient)
refers to the whole server. The code requires a JackClient as JACK
requires a client pointer to contact the server (there can be more
than one server running btw). Jack.getPorts(...) will return all
ports in the server, not just those on the provided client.
> For example, the outs variable of method JackAudioServer.autoConnect() only
> contains 2 strings even if I have connected all sorts of audio applications
> to the Jack server. Anyway, filed a RFE requesting
> jack_port_get_connections.
>
Two things -
* The autoconnect function in the JackAudioServer is useless in your
case. It is for the common case where you want to connect a client to
the soundcard (inputs and outputs). There is already a plan to allow
specification of outputs only for autoconnect, but for now you'll have
to handle the connections yourself using the JNAJack API.
* Use the code in JackAudioServer as a starting point. However, you
will have to remove the flag for JackPortIsPhysical. This filters the
results to just the soundcard, which is probably why you never see
anything else. You will also have to create a temporary client so
that you've got something to pass into the various methods.
>> We salute also the suggestion of Bill Brown for a ”listener” feature, see
>> his emails from 9th of December 2011.
>>
>
> I agree. Either add to your RFE, or I'll file one myself for these.
> This won't be your typical Java listener - it will be a direct mapping
> of JACK's callback mechanism.
>
> [Carl Henrik ] Better that you do that.
OK. Anything further on that will be tracked in the same issue.
>
> [Carl Henrik ] yes, I have dialogue also with the osx team, but have been
> hesitant to start running around in the various user groups prior to having
> a minimum of understanding of Jack in all its variants.
Probably better asking a lot of this there than here though! As
JNAJack is purely a wrapper to JACK functionality, you're more likely
to get detailed knowledge of the JACK API and server on the jack-devel
mailing list.
Carl H Janson
being unaware of the need for a temp client and the proper setting of the
flag JackPortIsPhysical, etc. This is most likely the reason for receiving a
list of own ports only, then.
Anyway, it seems doable to maintain dynamically a complete list of
connections to the Jack server in use, then to connect to whatever of these
connections as they are currently connected or not. We shall look into this.
Carl
-----Original Message-----
From: jaudi...@googlegroups.com [mailto:jaudi...@googlegroups.com] On
Behalf Of Neil C Smith
Sent: 17. januar 2012 18:54
To: jaudi...@googlegroups.com
Subject: Re: [jaudiolibs] RFE regarding persistent information on Jack
connections
Hi,
Noted and accepted.
Two things -
Best wishes,
Neil
--