Comment 5 for bug 1172299

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