Subject: [linux-audio-dev] drumset questions etc... Was: Re: disksampler 0.03 released, several fixes (non-blocking MIDI,ALSA,..)
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sun Jul 16 2000 - 16:22:03 EEST
[ drummers, drumsample experts, please read at least the drum related part ]
On Sun, 16 Jul 2000, Chris Baugher wrote:
> On Sat, 15 Jul 2000, Benno Senoner wrote:
> >
> > PS: Chris let me know if it work of for you.
> >
> > Benno.
> >
>
> The new version works great! The midi errors are gone and the response
> time seems good to me. It works much better when I set the fragment size
> to 256. With a fragment size of 128 I can't switch consoles while the
> program is running. The sound will distort like it's clipping or
> something.
What was your HW exactly ? Pentium 250 , right ? (I guess P200 or P233
overclocked) ( not PII)
Yes, 128byte fragments means IRQ time periods of 700usec ,
which is 1428 IRQs/sec , which can cause increase the load a bit on
not so recent boxes (that is a problem of every software sampler no
matter how it is implemented (kernel mode , userspace etc)
But at 3x128 is the sound distorted only during console switching or
always ?
Is the machine still usable using 3x128 or does your PC become very
slow ?
Anyway console switching should be avoided because the console
handling code is a bit problematic. (I did not measure exactly how Ingo's
patch behaves on heavy console switching, but in theory the latencies should
be low).
Perhaps using a fragsize of 256 in your case is enough to overcome to the
latencies caused by console switches.
(are you running fbcon ?)
Anyway I think it is not a big problem, since most of us will run the audio
workstation in Xwindows mode, or it the engine going to be an embedded one
(eg a rack which contains a headless PC), the console switching problem does
not arise too.
>
> CPU usage is fairly low, only about 15% with me laying on the keyboard.
> OTOH the hard disk goes nuts! Of course it's old and slow so that's to be
> expected.
Notice that as soon you overload your harddisk with too many streams,
the app exits with an error like:
"Sorry diskstream not ready"
in this case the audiothread wants to stream off the disk
(using the ringbuffer) but sees that the associated diskstream was not
initialized yet.
I will change this so that the app will not exit (simply mix silence to the
audio output) , but I do not like when these situations do happen.
Another dropout condition caused by the HD could be a ringbuffer which
is not refilled in time, this error is not currently detected and is too a
consequence of HD bandwidth/seek performance overbooking.
(I will add some debug code which will detect these dropouts)
So if the user does not want to risk dropouts, he has to provide an adequate
saefty margin (eg do MIDI stresstests on his harddisk) before trying to go
into the production phase.
This apllies to (the) other disksampler(s) too.
Anyway to increase the number of tracks you can do the following:
a)buy a faster harddisk
b) use multiple harddisk and spread the various instruments around the different
HDs so that the load is balanced across disks.
c) use software/hardware RAID ( RAID0 is the most suitable from a performance
POV, since the diskbandwidth scales almost linearly (but not the seek
performance)
I think though a bit messy (you have place different instrument files
to differen harddisks in order to distribute the load)
with b) you get out the most of your hardware, since not only the disk
bandwidth is increased but the seek performance too since the N disks are
completely independent.
>
> So... cool! What's next?
I plan to add flexible layering/splitting , amplitude/filter envelopes ,
crossfading etc, I will describe this in a separate mail (within the next
days or perhaps even today :-) )
and see what your proposals/ideas/comments will be.
Anyway I have a question now to you drummers / experts in drumsets on samplers.
You know that when you play a drum set, pressing first the open hihat key and
then the closed hihat key, will cause the open hihat to stop abruptly even if
you did not released the open hihat key yet.
I plan to include this feature or drumsets will not get very usable.
But I need suggestions what kind of features traditional samples have in this
area.
eg. Would it be ok to say: the press of key Z will stop note triggered by key
X and Y.
Would this be ok ? So that every key press can stop n other notes arbitrarily
choses.
What does mean stopping a note ?
Normall the open HiHat when you release the key will decay relatively slow,
but stopping it abruptly (eg when you press the closed hihat, the open sample
stops playing without any decay) does not seem the perfect solution to me.
How about instead of stopping it abruptly, forcing the note in decay
mode (like releasing the key) and change it's decay volume envelope curve ?
So that for example you can set a decay envelope from normal to very fast.
let me know your thoughts.
Benno.
>
> Chris|
This archive was generated by hypermail 2b28 : Sun Jul 16 2000 - 16:25:38 EEST