traverso-devel
[Top][All Lists]
Advanced

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

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


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

Hi (Nicola),

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

Glad you mentioned this, as I thought of it as an extra 'useless' layer of 
configuration. But with different drivers and/or hardware it's a perfect way to 
manage this.

As was discussed earlier, it makes sense to be able to add channels even with 
the alsa (or other) driver, so could you please have this option always 
available in the AudioIODialog ?
(without a mention of jack, as it'll be transparent to the user)

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

Hmm, I wonder if the AudioIO configuration is per Project or per Sheet ?


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

More or less implemented, but Driver creates the AudioChannels, not 
AudioDevice.

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

Partially implemented

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

Done.

> 
> > 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 'works' but needs a much more robust implementation, it assumes transport 
was stopped.

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

This needs some serious thought :)

I.e. is the AudioIO configuration per Project or per Sheet? Do we want 
autoconnect work in jackdriver ?
In that case we need a bit more sophisticated way of creating a 
'busconfiguration' 

But that's for later.


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


Well, it's a bit working now. E.g. my first stereo out on my card is broken. 
Fortunately, I've more outs, so with the AudioIO Dialog configured that 
Playback Bus 1 should use playback channels 3 & 4 instead of 1 & 2
After clicking OK, there was suddenly sound of my speakers
(Clicking a next time on the OK button in the AudioIODialog equaled silence, 
but I don't dare to read through the dark magic of AudioIODialog :D )

It's in git, so you can play with it, but expect some crashes here and 
there.....

Greetings, Remon




reply via email to

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