Subject: Re: [linux-audio-dev] stream buffering on EVO & pitchbend .... opinions ?
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sat Sep 16 2000 - 23:56:30 EEST
On Sat, 16 Sep 2000, Josh Green wrote:
> > (And as far as I know, the normal pitchbend range (at least on general MIDI is
> > +2/-2 semitones))
> >
> This is actually set on the target MIDI device. It looks like the AWE card will
> only pitch shift up by 2 octaves, down shifting doesn't seem to have a limit
> (makes sense to me). Of course its not using a hard disk for its samples.
But I was wondering how many MIDI songs make use of this big
pitchshifting range.
(I owned a Roland SoundCanvas some time ago but cannot remember
what the max pitchbend value was (default was +-2semitiones, and seems
that most MIDI songs use this value (plus it seems that there is no MIDI
standard cmd that allows you to change the pitchbend range from within
a MIDI song).
But we can always allow extreme shifts in EVO:
just keep all in RAM and you are ok.
>
> >
> > So does the limiting to +12 semitones sound reasonable ?
> > (from a MIDI instrument POV ?)
>
> I don't think I understand why larger buffers don't make sense. Why not? Except
> that the delay between changing the pitch shift and when it actually occurs will
> increase. You could always provide the ability to upshift faster, and if the user
> happens to have hardware that can handle it, then so be it. Probably want to give
> them warning though :) I know the reverse case (seeking in a file in reverse,
> playing samples backwards, sounds pretty cool, can scratch and stuff) is much
> worse on Linux than forward. Probably from the look ahead loading mechanism of the
> ext2 file system, not real sure myself.
No the buffering issue is another one:
Assume you want to be able to play 100 simultaneous voices (and a PIII is
capable of this):
you need one streambuffer for each voice.
You can't do runtime allocation because it's non-deterministic.
That means 256KB x 100 = 25MB only for the streambuffers,
plus you need to keep the beginnings of all samples in RAM
to overcome disk latencies. You can see that even if you stream from disk,
the needed amount of RAM is quite big.
(I'd say that when loading huge instruments ( 1-2GB) an amount of RAM
of less than 256MB is going to limit you becuase the above buffering
requirements.
All buffersizes are configurable, and therefore if you have tons of RAM,
(512MB+) no one stops from using bigger initial and streambuffers, in order
to improve reliability while playing samples with huge pitchbend shifts.
My goal is to make EVO work reasonably well on 128-256MB machines.
And I think the current values I'm using are a good tradeoff.
BTW you mentioned:
>Except
> that the delay between changing the pitch shift and when it actually occurs will
> increase.
This is not an issue in EVO, since the large buffers are only needed for the
disk streaming code. The audio engine itself uses only a few msec of buffers,
thus the pitchshift changes occur almost delayfree (with a lowlatency kernel
you achieve a MIDI-to-audio latency of about 3-5msecs)
>
> > (PS: but it is too funny making the HD go crazy with the simple movement of
> > the pitchbender :-) )
>
> I've done the same with a simple editing tool I wrote, but with a joystick, and it
> was only one sample not 16!
(16 is the speedup factor I used, and I was not able to stream 16 tracks,
because that would be like streaming 16x16=256 tracks from my poor IBM 16GB
EIDE drive. I guess the limits lie around 4-5 tracks (=60-80 normal tracks)
PS:
Josh, I looked at your Soundfont editor, and it looks quite cool !
And I am sure that there are many out here which do not own a SB AWE/Live
with big RAM amounts on it, but want to play their Soundfonts on their PCs.
What we could to is a tool which takes Soundfonts and translate it in EVO
instruments, playable without any additional hardware.
Benno.
> Josh Green
This archive was generated by hypermail 2b28 : Sat Sep 16 2000 - 23:04:02 EEST