Jack Audio Connection Kit Implementation Does not Follow Normal Behaviour

Since we use JACK through PortAudio there are limitations in how we can interact with JACK. We should work with PortAudio to expose more of the JACK API.

Would it be helpful if I filed a bug with Portaudio ?

Are you using Portaudio to make cross compiling easier ? When I last checked Jack Audio Connection Kit was in very early development on Windows and I'm not even sure how many or even if people use Jack on Windows. Would it make more sense to reserve Jack support for Linux ? That might make development of Jack for Mixxx easier.

It's partly for cross-platform support but mostly so we do not have to
support every API in Mixxx since PortAudio is a wrapper around each
individual OS's set of APIs (ALSA, OSS, JACK, DirectSound, ASIO, WASAPI,
WDMKS, CoreAudio, etc.). We would greatly prefer to solve this within
PortAudio rather than adding back in dedicated JACK support.

The problem is I don't have a solid description of what needs to change in
PortAudio so I'm not sure what your bug report would say.

On Thu, Apr 25, 2013 at 9:23 AM, DJ_Barney <email address hidden>wrote:

> Would it be helpful if I filed a bug with Portaudio ?
>
> Are you using Portaudio to make cross compiling easier ? When I last
> checked Jack Audio Connection Kit was in very early development on
> Windows and I'm not even sure how many or even if people use Jack on
> Windows. Would it make more sense to reserve Jack support for Linux ?
> That might make development of Jack for Mixxx easier.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1172299
>
> Title:
> Jack Audio Connection Kit Implementation Does not Follow Normal
> Behaviour
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1172299/+subscriptions
>

I have just read into JACK and Portaudio API.

I am afraid that the quested function is out of scope of Portaudio.
Port audio is a simple wrapper around many APIs for a common interface. The requested function, to expose static audio port to Jack, is a particularly Jack function. Once Implemented in Port audio it is only suitable for Jack.
But you can give it a try on the portaudio mailing list <email address hidden>.

If I have understand it right, there are two classes of Jack applications:
1) Instant port applications with self connecting like Mixxx/Portaudio
2) Static port applications like Meterbridge

Portaudio (1) is Looking for exposed Jack ports and registers the counter port instantly on connection. This way there is no external connection tool required. But if the Portaudio app is not connected it has no ports.

Meterbridge (2) does nothing without any connection but exposes all its ports to Jack just after startup.

But it is possible to trick Mixxx, if you create Mixxx Jack ports by connecting to random jack ports from the Mixxx config GUI.
And then change the connection by an external connection tool.

http://dis-dot-dat.net/index.cgi?item=/jacktuts/starting/

I think th Jack API is really easy. And since Jack is also OS independent it should be not hard to Implement a native SoundDeviceJack. But it is a lot of work anyway. We can toggle between our own hardware connection dialog and Simply expose all Mixxx Ports to jack.

Thanks for your confirmation RJ Ryan. I looked at some of the Mixxx code and into how Portaudio handles the ports. I'll take this to the Portaudio dev team when I can. I'll probably start with the numbering from zero.

So, thanks as well daschuer. By the look of it the Portaudio names HAVE to be "out_0, Out_1, ...", but at least we have the Mixxx client properly named now (I forgot I'd put in this bug that got that fixed :) - https://bugs.launchpad.net/mixxx/+bug/839547 ... This fixed the Jack client name from Portaudio to Mixxx.

The only other possiblity is if the Portaudio ports CAN simply ONLY BE OPENED in Jack, is there any way round Portaudio always forcing the connections ? Then they would instantly appear when Jack is selected in the drop down Sound API selection. But, if thats possible, then we seem to be in a catch 22 as all the ports can only be named (I think) "out_0, Out_1, ..." and its difficult for the user to find out what ports match to "Master, Headphones, Deck 1, Deck2, Vinyl Control 1, Vinyl Control 2, Microphone" ... BUT ... and maybe I just solved it. What if those port names, "out_0, Out_1, ...", are automatically filled in next to the Mixx input/output names in the Mixxx Sound Hardware Preferences API ?

Failing that maybe Mixxx could just give Portaudio ALL its inputs and outputs and let Portaudio do its stuff in Jack WITHOUT asking the user anything ? Then have the port numbers shown in the Mixxx GUI which gets round the naming confusion and would appear to be a more straight forward way of doing this more in line with normal Jack behaviour.

SEE ATTACHEMENTS FOR GUI MOCKUP

Second attachment ...

Hi Barney,

the Mixxx ports in Jack are instant ports created as counterparts to the connected ports. It is not intended to reconnect them by external Jack connection tools. So I am afraid your ideas are misleading.

If you have programming experience and bored from the TV programm ;-). I can give you a hand writing a SoundDeviceJack class. This is the best way to solve this issue.

The config GUI will just have a additional SondDevice selector:
1. Portaudio:
  like it is.
2. Jack:
nothing else except status infos, since everything is set by the jack server.
All mix channels are exposed to jack with proper names.

On Fri, Apr 26, 2013 at 5:52 PM, Daniel Schürmann <
<email address hidden>> wrote:

> Hi Barney,
>
> the Mixxx ports in Jack are instant ports created as counterparts to the
> connected ports. It is not intended to reconnect them by external Jack
> connection tools. So I am afraid your ideas are misleading.
>
> If you have programming experience and bored from the TV programm ;-).
> I can give you a hand writing a SoundDeviceJack class. This is the best
> way to solve this issue.
>

Yet again the Mixxx codebase goes in circles :). We used to have a sound
device for every API but PortAudio allowed us to rid ourselves of the
maintenance work of managing each individual one.

I really don't want to be back in the business of writing Sound
API-specific code (We were also talking about a PulseAudio SoundDevice to
get rid of pasuspender on Ubuntu!). Sure, each individual API seems simple
enough but when you add it all up it is way too much code to maintain. We
should check with PortAudio to make sure they won't support what we want
(the ability to create a device / endpoint in the case the API supports
it).

Also, I think there still may be some lingering assumptions about PortAudio
in SoundManager (other than the giant sections of ifdef's specific to
portaudio). We'll need to make sure it is truly generic.

> The config GUI will just have a additional SondDevice selector:
> 1. Portaudio:
> like it is.
> 2. Jack:
>

I think there's no reason to expose this detail to the user -- they surely
don't care. We could just make the API list of strings internally
represented by a (sound-device, API) tuple, so the intenral state of hte
API dropdown on linux would look like:

(PA, ALSA), (PA, OSS), (JACK, JACK)

and we would disable or blacklist JACK in PortAudio.

> nothing else except status infos, since everything is set by the jack
> server.
> All mix channels are exposed to jack with proper names.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1172299
>
> Title:
> Jack Audio Connection Kit Implementation Does not Follow Normal
> Behaviour
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1172299/+subscriptions
>

I don't feel that either of you have properly read my last posts. Did you look at my GUI mock ups ? I am a user of Mixxx and feel that I have put together a useful contribution that will improve Mixxx usability AND while KEEPING Portaudio.

Attaching my name to this to remind myself to have a look at it, feel free (whoever) to steal it.

I'm not totally convinced that this can't be accomplished with PortAudio (although comments do seem to suggest otherwise, and my memory is surely shoddy), I intend to look into it.

Hi Bill,
I am happy you (probably) picked it up.

I am still in favor a native SoundDeviceJack, but of cause a slick Portaudio solution would be an option.
It might be possible to expose our channels to PortAudio like PaJack_SetClientName and leave them unconnected, but this introduces a complete new philosophy to Portaudio and require heavily patching inside Portaudio and Mixxx.

Here some other arguments against:

On all Plattforms there are propper sound APIs without Jack. Jack is a wrapper like Protaudio but aims to to be very flexible in plugging together a sound setup and low latency.
So our case, wrapping Jack by Portaudio for a universal API is somehow wired.
You probably loose all key benefits of Jack.
It is something like double wrapped. Don't know what latency result this
produces. At least I see a copy from Jack buffer to the Portaudio ring
buffer in the Portaudio pa_jack.c. I think that is used to adapted th jack buffer size form the Jack settings to the Latency selected in Mixxx. A SoundDeviceJack would be simply run directly on the Jack buffer for synced Latency among all Jack clients.

IMHO only suitable way to use Jack in a way it is intended is to write a SoundDeviceJack.

Kind regards,

Daniel

Appreciate you comments, but, respectfully, I don't think you’re right about Jack being a "wrapper". I think you’re thinking of Jack as a traditional sound output API. It is very different from that, and could bring a lot of power to Mixxx if the devs decided to go that way. For example looks at JackEQ - http://djcj.org/jackeq/ - for something that Mixxx could be doing, although I realise that may not be in the goals that Mixxx has. As a user of Jack who (I think) has understood its revolutionary nature, I probably need to put something in a document for the Mixxx team to help clear up some of the confusion (?) here. Would that be a Blueprint or proposal of some kind ?

Hey DJ_Barney

Sorry if it seems like were ignoring your input :). A lot of us know JACK
quite well and do appreciate that it's a great paradigm to deal with audio
routing. I have used the JACK API a lot in other projects. We're just
trying to figure out what makes the most sense for mixxx architecturally
and project-wise.

Unfortunately we must figure out a nice way to deal with audio routing for
all of our users on windows mac and Linux. So whatever solution we come up
with will basically require cramming two different paradigms into one
backend and one UI. (I know JACK is cross platform but I have never heard
from a single user on windows or Mac that use it). Mixxx has to be "full
stack" so that anyone can just install it and get going with nothing else.

I have to agree with you Daniel that portaudio is not likely to want to put
in the effort. That said, before we go and do this work we should start a
discussion with Ross about it. I don't want to do it only to learn they
would have been happy to accommodate us. Code is a liability and I am just
trying to minimize our SLOC count because that is the easiest way to have
fewer bugs ;).

For example, pulseaudio support in portaudio is a much better place for it
than to make a pulseaudio sound device in Mixxx.
On Apr 28, 2013 8:30 AM, "DJ_Barney" <email address hidden> wrote:

> Appreciate you comments, but, respectfully, I don't think you’re right
> about Jack being a "wrapper". I think you’re thinking of Jack as a
> traditional sound output API. It is very different from that, and could
> bring a lot of power to Mixxx if the devs decided to go that way. For
> example looks at JackEQ - http://djcj.org/jackeq/ - for something that
> Mixxx could be doing, although I realise that may not be in the goals
> that Mixxx has. As a user of Jack who (I think) has understood its
> revolutionary nature, I probably need to put something in a document for
> the Mixxx team to help clear up some of the confusion (?) here. Would
> that be a Blueprint or proposal of some kind ?
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1172299
>
> Title:
> Jack Audio Connection Kit Implementation Does not Follow Normal
> Behaviour
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1172299/+subscriptions
>

It's OK. I don't think I was explaining my concept particularly clearly to begin with :)

I'm so glad that you have perceived the paradigm shifting nature of Jack ! As you can probably tell I start drooling over the possibilities every time I start getting ideas of what Jack could bring to Mixxx; Jack audio inputs into each deck ? Send and Receive FX routing (as many professional hardware Mixers have) out to Jack-rack; no need to worry about writing a custom FX part ot Mixxx any more (?) - just hand that out to applications specially written for that purpose. Jack MIDI inputs allowing multiple control surfaces to control Mixxx at once ? Anyway, I could go on ...

... I understand that its SO important to maintain focus for a project such as this. If Mixxx is easier to use and port to as many different OS'es as possible, but Jack support suffers, then so be it. But I think its worth defining what Jack could potentially bring to Mixxx, and how that could allow Mixxx to fit into Jack Audio set ups, as other solutions may present themselves in the future (Ross may be willing to make the changes that will help Mixxx, design goals may change, etc, etc). I intend to do that in a Blueprint. If there are any other brainstorming Jack users out there then I suggest you put in a Blueprint as well.

Hi DJ_Barney,

A lot of what you want to do is already possible in Mixxx, and I do it. I use the individual deck outputs in Mixxx to forward the audio to a set of jack-racks that handle effects and crossfading. (There's not even a need to bring the altered output back in to mixxx). Even though Mixxx connects jack devices itself, I have a script that disconnects the devices and then reconnects them to my racks. You can still use qjackctl! Mixxx already supports multiple control surfaces so we don't need JACK for that. And with the passthrough code that we'll be checking in shortly (to trunk), you can have external inputs from other programs.

Yes, the naming is a little inconvenient, but the actual functionality you are looking for is already there.

Hello. I disagree. Its great that Mixxx has these functions but the entire point of Jack is that it provides a common standard for doing these things. Plus it would make perfect sense having an FX return bus. Why do you think professional hardware mixers do it this way ? Its so there are a common set of easy to use controls ... not Jack apps spread all over the place that are difficult to switch to in the middle of live performances. Anyway, I'll stop there before this bee in my bonnet starts buzzing a little too much ! I'm gonna lay this all down in a blueprint.

This is still worth to fix.

Sure, though we're swimming in these "someday" bugs and I'm trying to close as many of them as I can. :)

As I said 2 years ago, code is a liability and I can't support a direct dependence on JACK as a solution to this bug from a code and project maintenance perspective. There would have to be an extremely compelling product use case for that to make sense.

If we can work with PortAudio to improve their JACK-specific customization that would be a great solution to this bug.

I am afraid the PortAudio interface will never suit for this (Or needs mayor re factoring).

I think to a solution where Mixxx exposes all streams to Jack and get reported back if the stream is used or not.
In case it is used, Mixxx should start processing automatically.

A solution using the Jack API should be very straight forward.

I noticed, that starting up mixxx shuts down my jackdbus server. I'll try to fish from logs why this happens. I'm on Arch and building from master (75de8d6 currently).

There is definitely something wrong with naming.

Jack aborts or dies when mixxx/portaudio tries to register a new client with really suspicious name.

I have attached the jackdbus log where the funny naming is visible.

Here is edited mixxx console output about the previous error.

I'm able to use jack only after these steps:

1. start mixxx (jack dies)
2. change all outputs to None
3. shutdown mixxx
4. run jack_control start
5. start mixxx (jack dies)
6. press continue in the hw config box
7. run jack_control start
8. reconfigure output hw (works)

It seems like the hw device list is populated only on startup, which leads to this extra juggling with jack.

The next restart of mixxx leads to same problem.
I am guessing that part of the problem is in restoring previous state from saved configuration.

There is also no need to use alsa layer for jack connectivity, but this could be result of my own configuration and default alsa device setting rather than portaudio behaviour.
I have alsa_jack_sink of type jack as a default pcm target in my asound config.

Every time, when the output connections are altered, the names for jack output channels are incremented.
Is this an PortAudio behavior?

When I start and configure a clean mixxx with jack (and this is the only audio-setup that I'll use) with Master Mix enabled, the output jack channels are named out_1 and out_2.
If I add a additionally jack-audio-device and connect to a output, previously out_1 and out_2 will now be out_3 and out_4, the additional outs will by out_5 and out_6 and so on.

I think this is unfavourable...
I'm very glad, if this can be fixed!
Thanks for your wok on mixxx!

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6998