Re: [Traverso-devel] Audio I/O dialog, and internals

[Nicola Döbelin]

Hi Remon,

Wow, great explanation, thanks! In case someone hasn't seen what it is all 
about: I'm trying to implement a flexible audio I/O routing, which is heavily 
inspired by StudioOne:

http://cdn.mos.musicradar.com/images/Computer%20Music/Issue%20146/studio-
one/presonus-studio-one-cue-460-100-460-70.jpg

and ProTools:

http://www.inventionen.de/Studio/ProTools/Fenster/I_O-Setup.gif

In the horizontal header of the matrix all hardware channels are listed 
(AudioChannels), and in the vertical header the user can create AudioBusses 
and assign them to hardware channels by checking the the checkboxes in the 
matrix. At first this seems like an additional (unnecessary) layer of 
configuration, because the AudioBusses still have to be assigned to tracks. But 
in my experience it has some important advantages:

- The user can map AudioChannels to mono or stereo AudioBusses as needed.
- If the hardware changes (e.g. a firewire device not plugged in), the number 
of AudioBusses doesn't have to change. We can still create all AudioBusses 
when loading a project, but some of them will not be connected to the correct 
AudioChannels. That's the best we can do if the hardware changes, because we 
provide a stable AudioBus interface to the project.
- The audio I/O dialog is the place where jack ports will be configured. Jack 
ports will be treated like hardware channels (AudioChannels).

Remon, back to your comments:

> If you have to change the configuration of the AudioBuses and/or Channels
>  you have to either:
> 
> * Stop the audio device thread from running, wait till it stopped, then
> (re)configure the AudioBuses/Channels and start the audiodevice thread.
> 
> or
> 
> * Create the new configuration, move this as an 'event' to the audiodevice
> thread, so moving the execution of the event (some function) from the GUI
> thread to the audio thread.
> This is probably what you want, so you can change the 'routing' of e.g. a
> playback channel on the fly, without any sound brakes.

In terms of thread safety I don't think we have to make it more complex than 
necessary. There is no need to provide gapless switching of AudioChannels. We 
could force transport to stop, or disable the AudioIODialog if transport is 
active. AudioIO configuration is rather low-level, like loading or configuring 
the driver.

> So, in order to properly support your idea I think this needs to happen:
> 
> 1) AudioDevice no longer let it's Driver decide how many
> AudioChannels/AudioBuses there are, it just creates as many as Traverso
>  tell's it to create

AudioBusses: Yes
AudioChannels: See below

> 2) After the Driver has inited, AudioDevice tries to map it's AudioChannels
> according to the configuration to the ones available in the Driver.
> 
> * In case the ALSADriver is in use, the mapping goes according to the
> configuration, and if no more hardware channels are available, don't map
>  them at all or map them to the first hardware channels available ?

Exactly.

> * In case of the JackDriver, the JackDriver will deal with creating as many
> jack ports as needed to make the mapping possible. So in this case, the
> JackDriver can 'fake' as much hardware channels as one would like to have.

Exactly.

> 3) Now AudioDevice signals that it's configuration has changed, just like
>  it does now, and Sheet/Track etc will update their AudioBus pointers as
>  usual. (But now we need to handle the case that a Sheet or Track no longer
>  can find it's AudioBus...)

Yes. To be honest, I haven't thought about how to handle this. But then again, 
there is no correct solution, either. The user has to re-configure his tracks 
when he deletes AudioBusses that were in use. So we just have to make sure 
that it doesn't crash, e.g. by automatically map tracks to the first AudioBus 
or a dummy AudioBus if the used one was deleted.

> This makes things much more transparent on the 'Traverso' side, no 'if jack
> then' or 'if alsa then' ...
> 
> It also gives the user this ability:
> Record using the ALSA driver since it's the Driver that has the least
>  overhead and chance of buffer underruns _and_ configure a future Project
>  with e.g. 20 AudioChannels on it's own machine which only has 2 real
>  hardware channels, carry the Project on e.g. an external hard disk to the
>  recording room (or send it by email or ... ) and start recording directly
>  after loading Traverso without the need to have to setup everything from
>  scratch there....

So we would save driver-dependent configurations in the project file? Sounds 
very cool, indeed! Could we do the same for specific hardware configurations, 
even if the same driver is used? E.g. if the firewire device is plugged in and 
we have 6 hardware channels, we would create config A. Next day the FW device 
is not plugged in and we only have the 2 onboard channels, we create config B. 
Next day the FW device is plugged in, and config A will load automatically.

All in all I think if we get this working reliably, it will be a quantum leap 
in the history of Traverso.

Greetings
Nicola