Subject: Re: [linux-audio-dev] stream buffering on EVO & pitchbend .... opinions ?
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sun Sep 17 2000 - 23:40:45 EEST
On Sun, 17 Sep 2000, Ruben van Royen wrote:
>
> I own a Roland JV80, and it can pitch bend 48 semitones down (which
> would not be a problem), and 12 semitones up. I also have an Alesis
> QS8, which can pitch-bend 12 semitones up/down. So for pitchbend
> purposes you are completely safe if you limit to 12 semitones.
> But pitchbending is not the only place where up/down sampling occurs.
> You also want to have the ability to play the same sample acros a
> section of the keyboard. This is often done because you need less
> samples that way. It is quite uncommen that an instrument is sampled
> at every pitch. (Although the best samples out there do this more and
> more often). For the disk sampler this still makes sence, since you
> must buffer the beginning of every sample. Plus it gives you the
> ability to create strange effects.
I fully agree, certain instruments have very few keyzones,
thus the resampling code must upsample/downsample several semitones.
The final pitch is as you said calculated by the
(midi pitch-rootkey) * pitchbend_factor, and can indeed easily cross the
+12 semitones mark.
> This could ofcourse be limited to 12 semitones, but I think that
> restriction is harder than the 12 semitones for pitchbending. plus,
> when you allow pitch bend +12 and map the sample to the keyboard at
> +12 you still have the posibility of +24, or a 4 times shortening of
> the buffer.
> Could the buffer allocation be made dynamic, so that samples the might
> be played at a higher speed get a larger buffer? But this could
> ofcourse only be done for the initial buffer, so thats not really a
> solution. Perhaps the editing software should be capable of
> automaticaly generating resampled samples every octave or so.
The buffers could be made bigger at note-on time,
(based on the (midipitch-rootkey) value,
(assume we allocate from a pool of preallocated 256KB areas)
In that case we would need to find two consecutive blocks in order to get
a 512KB area, but that may fail under certain circumstances because of
fragmentation (eg of 100 available voices, all even voices are active,
thus making the allocation of a 512KB block impossible)
Another strategy is to use "fragments" (eg a list of let's say 32-64KB blocks)
like Paul does in Ardour (not sure if this is still actual, but on his initial
releases he posted some infos about it).
The fragments approach allows flexible allocation
(and in theory you could alloc the buffersize based on the initial playback
speed), but it makes fast interpolation (resampling) harder since you can't use
the wraparound trick I'm using right now (basically I am replicating the buffer
beginnings at the end of ringbuffer so that the interpolation code can cross the
bounds and get the correct samples, the same which are located at the beginning
of the buffer, kinda cool and very efficient (no changes in the interpolation
code over interpolating from linear memory segments)).
One solution would be to
make the fragments bigger to that you can copy the wraparound data at the end
of each one, but, then with the increasing of fragmentsizes and max up-pitch
values, you begin to waste quite some mem. And the initial buffer problem
remains: you have to determine in advance how much to hold in mem in order to
overcome to filesystem latencies. But as said before, loading too much initial
data, will limit the number of of samples you can "load" and play.
I am not sure if the fragments approach would ease EVOs life,
what's certain is that it would complicate the code in certain areas quite a
bit, and perhaps even make it slower since you have continuously to check
for boundary crossings in both disk streamer and audio rendering code.
(where right now the audio code basically can live with and "inc" and an "and",
on buffers with size = power of two , you can do very fast increments with
wraparound)
As for the soundeditor, one could easily generate a multisample
out of only a few or one single sample mapped on the whole keyboard.
The only drawback is some wasted diskspace (but that is very cheap these
days).
The advantages are:
- you can use high quality sinc (bandlimited) interpolation to render
the multisample, thus getting rid of any aliasing noise even at extreme
pitches.
- the engine uses much less CPU/diskbandwidth because the pitch
is only moderately shifted, and thus the buffersizes can be kept constant
like I do right now.
comments ?
> Also, if I find some time I'll hack wav import for Evo, so that I can
> play my 1 Gig piano sample in linux :-)
Do you have a 1GB piano in .WAV format ?
(I thought that at the present, there is only the gigapiano which is that big ?)
Anyway .WAV import will be mandatory for the instrument editor, or where
else would you get the samples from ?
Benno.
This archive was generated by hypermail 2b28 : Sun Sep 17 2000 - 23:03:00 EEST