traverso-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Remon Sijrier
Subject: [Traverso-devel] Audio I/O dialog, and internals
Date: Sat, 16 Jan 2010 16:19:55 +0100
User-agent: KMail/1.12.4 (Linux/2.6.31-17-generic; KDE/4.3.4; i686; ; )

Hi Nicola

(I'm sending this email to the list as others might have a (strong) opinion on 
this as well)


I've been reading through your code changes in AudioDevice, and I think I get 
the idea of what you want to do.

Do I get the principal of your idea when I say that the AudioIODialog is 
basically the same functionality as the 'connect' dialog of qjackctl ?

Then I'm a bit puzzled by this concept/idea, because, if you change something 
in the AudioIO, let's say you remove an AudioBus, how does a Track that uses 
that AudioBus know it's capture Bus has vanished ?


For more insight in how Traverso deals with AudioBuses/AudioChannels here a 
short explanation:

There are 3 'modules' that use and know about AudioBuses:

* the Driver (AlsaDriver, or JackDriver or ....)
* the AudioDevice
* Traverso itself (Sheet, Track, etc)


The flow is as follows:

1) AudioDevice initializes it's Driver. The Driver tries to configure the real 
hardware, or connect to the jack server or...
When that's finished, the _Driver_ knows how much real hardware channels are 
available, and creates an AudioChannel object for each hardware channel. (or 
port or slot if you want to call them that)
This AudioChannel has the real buffer where the audio is written to or read 
from.

2) AudioDevice 'attaches' to the inited Driver and the Driver tells 
AudioDevice how many AudioChannels it created. AudioDevice groups them in 
AudioBuses, 2 AudioChannels for each AudioBus, so by default I assumed the 
hardware grouped the channels in stereo, hence the AudioBus 'concept'

3) AudioDevice now can represent the 'real hardware' and signals Traverso 
(Sheets) to update their AudioBus _pointers_ to the real AudioBus objects, by 
requesting them from the AudioDevice by their name.

After that, the AudioDevice starts the audiodevice thread, which periodically 
reads/writes the buffers from the AudioChannels to the corresponding 'real 
hardware channels' either by using ALSA, or jack server or .....

So after this point, you never ever want the GUI to start changing the 
AudioBus or AudioChannel objects!!!!!!

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.


This moving from the GUI thread to the Audio Thread is done by the Tsar class. 
The AddRemove class [1] shows an example how this is done with adding/removing 
a Track too/from a Sheet.

In this case we don't have to use AddRemove, but can use Tsar directly, or by 
using one of it's convenience defines like:
THREAD_SAVE_INVOKE(caller, argument, slotSignature)



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

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 ?

* 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.

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...)


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....


Hmm, still a long story. Hopefully you guys got the idea :)

Greetings, Remon

[1]: http://traverso-daw.org/developerdocumentation/classAddRemove.html




reply via email to

[Prev in Thread] Current Thread [Next in Thread]