Subject: Re: [linux-audio-dev] fyi: whats going on with ardour
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Sun Dec 17 2000 - 06:17:30 EET
>> 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.
>> 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?
Well, given that with my card of choice, the Hammerfall, only has one
possible number of fragments (2), no, the fragment size. Remember the
stuff I've been repeating here for a year: input event latency is
related to fragment size, output event latency is related to total
buffer size. if you want them both to be good, you want low numbers of
small sized fragments.
--p
This archive was generated by hypermail 2b28 : Sun Dec 17 2000 - 06:41:59 EET