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 _______________________________________________ beast mailing list [email protected] https://mail.gnome.org/mailman/listinfo/beast
