Subject: Re: [linux-audio-dev] stream buffering on EVO & pitchbend .... opinions ?
From: Josh Green (jgreen_AT_users.sourceforge.net)
Date: Sun Sep 17 2000 - 01:30:33 EEST
Benno Senoner wrote:
> 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 don't think probably any use it. I just recently saw mention of a pitch bend range
RPN message in MIDI. But how often this is implimented I wouldn't have a clue. I've
seen it in the ALSA source code.
> (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.
>
> 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.
>
Okay that makes sense, but its still left up to the user, that was what I wanted to
know :) Who knows where hardware will be in the next year.
> (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)
>
My misunderstanding.. That did sound kind of too good to be true..
>
> 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.
I think probably the best way to go about this, would not be to build patch loading
support directly into Smurf for a particular software wavetable program. But rather to
interface a software wavetable engine to ALSA with patch loading support. I have
attempted to find out on the status of patch loading in alsa before, and received no
response. In this manner though, any program could sequence the software wavetable
engine and Smurf would just load it with sound fonts and allow the user to edit them :)
Cheers,
Josh Green
This archive was generated by hypermail 2b28 : Sun Sep 17 2000 - 02:52:34 EEST