Comment 11 for bug 1172299

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