Subject: [linux-audio-dev] variable samplerate plugins, streaming etc. Was: back to the API
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ti loka 19 1999 - 19:34:05 EDT
I was a bit busy the last 3 weeks, but
I followed the API discussion.
One of the important things is the vaiable samplerate issue:
I thought about this some time ago, when I was experimenting
with sample interpolation.
In the case of streaming buffers with variable samplerate,
you have to deal with odd buffer sizes which might continuously change.
For example in the case of quadratic interpolation we have to look ahead
at least 2 samples.
But what if the user wants to resample the data at 10times the original pitch ?
That means in the worst case we have to look ahead 10+2 = 12 samples
in order to be able to perform the interpolation.
If we assume that we use a 3rd order cubic spline interpolator, maybe combined
with a high -order lowpass filter (to eliminate/reduce aliasing when playing at
high pitches), and suppose that there is a user which wildly drives on his MIDI
keyboard's pitch wheel, then you will quickly realize that
streamed variable samplerate / interpolation, is not a trivial task anymore.
(Opposed to doing linear interpolation on a continuous array of samples).
I'm actually following a DSP course at our university, and maybe I could
design/implement such an interpolator as mini-thesis for the exam.
The goal would be to have an interpolator which works well in a RT enviroment,
and tries to maximize audio quality.
(Of course if you need a very high number of voices, you have to use a less
expensive method).
I think the variable sample-rate proposal of David will save us a lot of
troubles later.
For example changing the resampler with a pitch shifter would be very useful.
If you have enough CPU power just use a very high quality pitch shifter instead
of the resampler, for your sample playback engine.
( in our case the resampler reads the source sample at variable rate,
depending on the actual pitch, while pitch shifter has a constant input data
rate).
As for the data streamer daemon, there is no problem to implement variable
sample-rate support:
just tell the daemon to periodically check how many samples are left in each
channel buffer, and sort this data.
Refill the most empty channel first.
Using this approach, the streamer daemon, automatically gives bigger priority
to channels which are played at higher pitches, (or higher samplerates).
Of course this works as long as you don't overload the disk.
( ie playing track1 at 200x speed would not work since it would generate a disk
load of 30MB/sec ( 150x200). )
Using one streaming thread per disk would work best, since you can minimize
seeking overhead (by using large buffers).
The only thing which still worries me is user interaction:
If an external program does medium disk I/O on the audio disk, then we will
miss deadlines, since we don't have a guaranteed rate I/O subsystem.
Perhaps some people will come up with a solution in not too distant future.
I'm very curious if BeOS is able to handle this.
( run a harddisk recorder , and in background a large file copy which tries
to disturb the hd recorder).
PS: Paul , 32 bytes max event size seems to little to mee too.
Just assume I have a custom made 3d speaker system consisting of 16 speakers,
where I can control the volume , and 4 eq bands for each speaker.
I want at least float precision:
16 * (1+4) * sizeof(float) = 320 bytes
I want to send a quite dense stream of 3d events to simulate accurate movements
of objects in the 3d audio space.
Of course I want to send the status of the whole 3d configuration in one event
without messing event splitting etc.
If we can, we sould avoid the MAX_EVENT_SIZE value,
or at least keep this on acceptable values.
comments ?
regards,
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST