Support for other audio backends (ALSA/JACK)

[Teteros]

Searching around in the repo it looks like ALSA and JACK were supported early on in Kunquat.

Was wondering if Kunquat will be PulseAudio only for now, or if there are any plans to support one of those APIs again It would likely be a step towards possibly supporting MIDI inputs/controllers and such.

[cyberixae]

Here are some of my thoughts on the subject. This pile of thoughts is by no means any kind of official policy. Also it is lacking in technical detail regarding Jack and Alsa specifically.

Different audio APIs provide varying support for different use cases (audio output, audio input, midi output, midi input, synchronizing applications). In addition different audio APIs have varying level of support for different platforms (Ubuntu, Mac OS X, Windows).

So far Kunquat has had only one use case (audio output) and has supported only one platform (Ubuntu). As you pointed out we spent some time trying to find a good way of taking care of that use case and ended up with PulseAudio. Our process was some kind of survival of the fittest. PulseAudio just seemed to work well enough for audio output so there was no need for further experimentation.

I don't think we have done any experimentation with MIDI inputs. However we have discussed the use case sometimes in the past. If someone was to do experimentation with implementing MIDI input I'd recommend them to use a similar process. Trying to implement it using what ever APIs available. Perhaps one of them is good enough to make it work. Perhaps Ubuntu is promoting one of them as the recommended way of doing MIDI input on Ubuntu? Perhaps some MIDI API has good developer documentation? Perhaps some MIDI API is easier to get up and running than others? We won't really know before experimentation.

If MIDI input experimentation leads to Kunquat using Jack or Alsa or ... for MIDI input, then it might make sense to revisit the audio output experimentation and see if we wish to use the same API for audio output. Using the same API for MIDI input and audio output would perhaps make the installation instructions simpler and reduce the amount of memory footprint by reducing the amount of dependencies. However, this is just an optimization and not strictly necessary for things to work.

We have also had some discussions about supporting some other audio APIs since this might make Kunquat work better on other platforms (Mac OS X, Windows). This might mean for example shorter installation instructions, shorter installation time, lower memory footprint or more robust operation. This kind of support for serveral audio APIs would not require user interaction since we could select the best APIs that are most likely to work flawlessly based on user's platform.

Some audio applications provide some kind of user interface that the user can use to experiment with different audio APIs regardless of platform. I'm personally not a huge fan of this approach but I see how it might be necessary for supporting some less popular GNU/Linux platforms that do not provide the user with a working audio API out of the box.

[kagu]

MIDI input support is something that I have had on my mental backlog for quite a while, and I would definitely like to see Kunquat support it at some point.

Proper JACK support might turn out to be difficult to add since the tracker is implemented in Python and is therefore not well-suited for low-latency operation. It may not be as bad as I suspect, though; it would require some testing.

In any case, we will definitely consider supporting additional APIs if there's a clear need that they can help us meet. For MIDI input, my (admittedly rather uneducated) guess is that we will probably include ALSA support.

[mxmilkiib]

JACK support would be neat as it provides graph routing/patching between all JACK clients, plus it supports audio-rate control "CV" patches which can be used to build a giant modular synth.

Stop by #lad and/or #jack on Freenode if you're so inclined! :)