Subject: Re: [linux-audio-dev] fyi: whats going on with ardour
From: David Olofson (david_AT_gardena.net)
Date: Sun Dec 17 2000 - 02:41:47 EET
On Friday 15 December 2000 17:19, Paul Barton-Davis wrote:
> >> 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).
It seems to be required with most drivers and APIs anyway... How does
ALSA deal with it? Is it at all possible to change any of these
parameters on the fly, or gather enough information to fix the
buffering after an over/underrun?
> 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.
Changing the number of fragments used, but sticking to a constant
fragment size?
(That's the only reliable way I can see to do it with OSS, but ALSA
might have some other possibilities that I don't know of.)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sun Dec 17 2000 - 04:18:04 EET