Subject: Re: [linux-audio-dev] fyi: whats going on with ardour
From: David Olofson (david_AT_gardena.net)
Date: Mon Dec 18 2000 - 23:49:20 EET
On Sunday 17 December 2000 05:17, Paul Barton-Davis wrote:
> >> 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?
>
> i don't know any hardware that would this the fragment size or the
> number of fragments to be changed on the fly. its too fundamental
> to the entire operation of the h/w - you're essentially
> reprogramming the DMA controller on the audio interface.
Yep, however, some carefully designed chipsets of the past actually
didn't look at DMA and buffers as init only stuff. For example, the
good ol' Amiga had 4 voices with indepentent dividers for the sample
rate, and one DMA channel each. The DMA control registers were
latched right after the first few samples of a fragment had been
read, and then an IRQ was issued, indicating that you could set up a
new fragment to be played after the current one has finished. If you
did nothing, the current fragment would loop. Fragment sizes could be
anything between ~6 samples (it took 4 sample periods before the chip
accepted new parameters, IIRC) and 128 kSamples.
Oh, well, times have changed; we used to have smart hardware with
poor performance - now we have utterly stupid hardware with
incredible performance. :-)
Anyway, there's one way to "cheat" on the user space side - provided
you can use or at least fake more than 2 fragments. First, make sure
you have enough fragments for the highest latency you want, and then
prewrite the desired number of fragments before entering the main
loop. Block on read() instead of write().
To adjust the latency, just adjust the number of fragments by writing
extra output fragments, or by skipping output fragments. Obviously,
there will be some kind of doppler-like effect when doing that
(except through paths that are fixed at a certain input->output
latency, using extra buffering) - but you don't have to restart the
driver or even depend on it to do anything special after
initialization.
//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 : Tue Dec 19 2000 - 00:22:23 EET