Subject: [linux-audio-dev] Re: drumset questions etc... Was: Re: disksampler 0.03 released, several fixes (non-blocking MIDI,ALSA,..)
From: Chris Baugher (baugher_AT_enteract.com)
Date: Mon Jul 17 2000 - 21:56:56 EEST
On Sun, 16 Jul 2000, Benno Senoner wrote:
> On Sun, 16 Jul 2000, Chris Baugher wrote:
> > 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)
It's a Pentium 233MMX running at 250MHz (2.5 x 100MHz bus) on a
Microstar-5169 Super7 motherboard, 64MB PC100 ram, and a 3.2gig Quantum
fireball (IDE) disk. I don't have DMA turned on because the motherboard
uses an ALI chipset that isn't supported (yet).
>
> 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 ?
In more detail...
In console #1 start disksampler: disksampler --fragmentsize 128 sine.sam
press a note and hold it down.
switch to console #2, sound is now distoted.
At this point all notes from now on will be distorted. Although sometimes
if I hold down a note and switch between consoles enough times, eventually
the sound will "fix" itself and will sound normal again.
This behaviour ONLY happens when using ALSA native mode with a fragment
size of 128. ALSA with OSS emulation does NOT have this problem.
It's almost as if a buffer is getting out of sync or something, maybe
because of lost interrupts?
>
> Is the machine still usable using 3x128 or does your PC become very
> slow ?
I haven't noticed any slowdown at all.
>
> 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).
I agree.
>
> 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.
I'm not using framebuffer consoles.
>
> >
> > 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 haven't seen that error 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)
This is more like what happens. When a lot of notes are pressed the sound
just drops out. Setting the fragment size to 256 makes this go away, or at
least makes it happen much less frequently(slow hard disk again).
Chris|
This archive was generated by hypermail 2b28 : Mon Jul 17 2000 - 22:33:27 EEST