Subject: Re: [linux-audio-dev] fyi: whats going on with ardour
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Dec 15 2000 - 18:19:51 EET
>> in the meantime, ardour has gained a 64 bus architecture. tracks
>> can be assigned either to physical output channels or a bus. they
>> will soon be able to be assigned to multiple busses (read: panning
>> and surround sound).
>
>Arbitrary number of sends, controlled via various abstractions, such
>as direct individual send control, mono compatible pan, phase stereo
>pan, quad-pan, 5.1 pan, arbitrary size speaker array pan etc...? ;-)
All of the above. an Ardour track has the following members:
/* pan structures */
union {
double mono_out;
double stereo_out[2];
double surround_out[6];
double *custom_out;
};
enum OutputMode {
OutputMono,
OutputStereo,
OutputSurround,
OutputCustom
};
guint32 n_outs;
You set the output mode for the track, and then you can set the
pan structure. How you want to allow someone to edit the pan structure
is a different story altogether, and its there that clever tricks
can be played to implement specific panning systems. The OutputCustom
mode allows a single track to be sent to an arbitrary number of
outputs (both physical channels and any of the internal busses).
>> hell, i'm about to make [fragment size] changeable directly from the GUI!
>
>I've been thinking about how to make an engine capable of doing it on
>the fly... :-) It was a good while ago, however, so I can't remember
>exactly why I got the idea in the first place, or what it was
>supposed to be good for.
>
>One thing that springs to mind now is feedback loops involving
>external units, still sticking to my initial idea that the main
>engine thread should never stop until you shut down the audio
>workstation environment for a game of Q3A.
When changing the fragment size or the h/w sample rate, I consider it
acceptable to stop the audio engine. I also stop and restart it when
we encounter recoverable under- and overruns (i.e. ones that happen
while we're neither playing nor recording).
The reason why this is useful is that you can get more solid recording
performance by using a large fragment size (assuming you have h/w
monitoring so that latency isn't an issue). Conversely, for playback,
plugins, etc. its nicer to set it very small (i am using 128 samples
at 48kHz all the time right now, thats 2.6msec) so that response is
snappy. At the moment, Ardour doesn't allow this to be changed on the
fly, but it will very soon.
--p
This archive was generated by hypermail 2b28 : Fri Dec 15 2000 - 18:56:41 EET