[Top][All Lists]
[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
- [Traverso-devel] Audio I/O dialog, and internals,
Remon Sijrier <=
- Re: [Traverso-devel] Audio I/O dialog, and internals, Nicola Döbelin, 2010/01/16
- Re: [Traverso-devel] Audio I/O dialog, and internals, Remon Sijrier, 2010/01/18
- Re: [Traverso-devel] Audio I/O dialog, and internals, Remon Sijrier, 2010/01/18
- Re: [Traverso-devel] Audio I/O dialog, and internals, Remon Sijrier, 2010/01/19
- Re: [Traverso-devel] Audio I/O dialog, and internals, Remon Sijrier, 2010/01/20
- Re: [Traverso-devel] Audio I/O dialog, and internals, Remon Sijrier, 2010/01/20
- Re: [Traverso-devel] Audio I/O dialog, and internals, Nicola Döbelin, 2010/01/20