5 Oct
2015
5 Oct
'15
8:38 a.m.
On 10/04/2015 10:02 PM, michael noble wrote:
On Mon, Oct 5, 2015 at 8:25 AM, Ben Burdette <bburdette(a)gmail.com
<mailto: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.