On 10/04/2015 10:02 PM, michael noble wrote:

On Mon, Oct 5, 2015 at 8:25 AM, Ben Burdette <bburdette@gmail.com> wrote:

No one ever uses that portaudio mode in linux in the
supercollider world, so its something of a surprise that it works at
all.

This quote alone suggests you may be overstating the difficulty of getting a working JACK system up and running with the latencies you require. If JACK were as bad as you maintain, surely more people would be using the alternative? I'd thoroughly recommend you spend the time you will spend trying to get the portaudio backend running the way you want and use that time instead to learn how to set up and use JACK on your platform. In my experience, once JACK is set up and running, it is as hassle free as any other direct interface, but with the added bonus of future flexibility if required...

I think most people aren't running jack without a gui and on an arm computer. In that situation debian, for instance, has its dbus permissions completely hosed by default, from the standpoint of jack anyway. I had raspian working since last year, but a recent update made my dbus hacks no longer work.

Arch actually works out of the box with regards to dbus, although I had some trouble giving jack realtime priority starting it from systemd. From systemd jack mostly starts without xruns, if I 'sleep 30' first.

Recently I built a test app using faust and writing directly to alsa. Super responsive, low latency. Starts right up, no worries about -p256 or -p512 or etc. I am building an instrument and I don't need the flexibility of routing audio between applications. I do need low latency and reliability on startup. Jack, while no doubt powerful in a studio situation, is for me a needless complication which has produced lots of sysadmin headaches and no benefits.