jack-driver updated

[Stefan Westerfeld <stefan space twc de>]

   Hi!

After a few improvements recently added, the jack-driver branch should be ready
to use; I've tested and polished the code to the degree that things should just
work.

Currently, the driver assigns itself the highest priority, but doesn't start a
jack server. This means that

 - if jackd is running: the jack driver will be used automatically
 - if jackd is not running: open will fail, and the next best driver
   gets used instead

I'll go through the things that could be improved. Most of the time there is a
corresponding FIXME in the code. Although there are some things that could be
done better, IMHO none of these issues is so critical that it is a blocker for
merging. I.e. even if we ship jack-driver as-is, we're still better off than
without it.

1.) signal handling

SIGPIPE must be blocked in our thread, because otherwise if the jack server
dies, BEAST will die receiving SIGPIPE - see FIXME - this should not be done
in our driver code, but BEAST should setup SIGPIPE handling globally

2.) keeping the connection open

Currently, we reconnect to the JACK server every time the user presses play.
Since we auto-connect to the hardware device, this should be ok for simple
cases. However, if the user wishes to connect the BEAST input/output to one or
more programs (visualization or effects), he will have to do it over and over
again each time he presses play.

Most other programs do not behave this way, but keep the connection to the jack
server open all the time; this way connections set up between JACK clients will
be persistent across play|stop. This probably requires deeper changes in BEAST.

3.) jack device latency

The driver API is suboptimal here (see FIXME).

4.) handling jack server down

It can happen that during play, the JACK server dies (user can manually stop
server, server can crash). When that happens, currently the play position
pointer will no longer advance. BEAST will stay responsive, so the user can
press stop, and next time he presses play the next-best driver would be used.

However, it would be better if BEAST reported something like "JACK server was
shutdown" and automatically stopped "play" mode instead of hanging.

It could be done by changing the check_io function, so that an error code could
be reported.

5.) auto connect should be configurable

Auto connecting to the hardware device (which is what the driver currently
does) is often but not always the desired thing to do. Other JACK applications
allow disabling auto connect, so that external programs (such as qjackctl) can
manage connections for the client.

So we should have a way of somehow disabling auto connect. Ideally at the UI.

6.) jack server name

We currently don't support connecting to a specific JACK server, if more than
one is running. See FIXME. Ideally this could be added at the UI.

7.) xrun reporting

We currently report xruns (for our internal ringbuffer) on stdout. Not sure if
that is the right thing to do, maybe we should just ignore xruns alltogether or
report them using PDEBUG() - so that developers can see them, but not users.

   Cu... Stefan
-- 
Stefan Westerfeld, http://space.twc.de/~stefan