Subject: Re: [linux-audio-dev] variable samplerate plugins, streaming etc. Was: back to the API
From: David Olofson (audiality_AT_swipnet.se)
Date: ti loka 19 1999 - 21:26:37 EDT
On Wed, 20 Oct 1999, Benno Senoner wrote:
> 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).
True. I wouldn't recommend using it for this purpose. I meant to
support it as a framework far communication between the streamer and
the interpolator, so that both (or at least one) can be plugins
without working around the API.
> 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).
Or a faster CPU, or two. :-)
Plug in some quad G4 466 boards? *drewl* (Uhm, sorry... :-)
> I think the variable sample-rate proposal of David will save us a lot of
> troubles later.
That was the idea. It can do some other neat tricks as well, and the
plugin doesn't have to know much about it. There will be some "fun"
stuff around the lookahead handling, though. It'll have to be done as
with the "old" system, but (still) for each buffer. Oh, the engine
can still use circular buffers or whatever - the plugin just wants to
know where the data is, just as before.
> 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).
There are some synths that do this... Not exactly in the "affordable"
price class, IIRC. Would be very cool, handy and useful.
> 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 don't know if this is the right approach, really... As we have
timestamps, it's safe to send the data as individual events, _at
least they are true real time, and timestamped_. There *is* a problem
with out-of-band events, but those shouldn't really be used for this
anyway.
For performance reasons, however, array events and other
optimizations are still interesting.
> 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.
Problem: What if you only want to change a few parameters? Indexing
the sound sources like synth voices seems sensible to me, and makes
it possible to control each sound source dynamically.
However, what about video and other nasty things? If we are to use
fixed size events, we'd better make sure we don't hit the wall as
soon as people start using the API...
> If we can, we sould avoid the MAX_EVENT_SIZE value,
> or at least keep this on acceptable values.
Not really possible, but what about 1024 bytes or so? Ok, I wouldn't
recommend pumping that kind of events through the system at high
rates, but you can use them if you have to.
BTW, even with fixed size event structs, it should be possible to
tell the exact size of events, so that gateways or proxys don't have
to copy the full struct all the time.
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST