Subject: [linux-audio-dev] Re: disksampler ...
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Jul 13 2000 - 21:06:39 EEST
On Thu, 13 Jul 2000, xfm_AT_free.fr wrote:
>
> I may be of help, but what you mean here is of course a LADSPA hook+tons of
> good ladspa plugins, or am I wrong ? Anyway, do you want to keep the thing lean
> & mean (KISS) or do you want to make it a full featured (bloated) thing ? I may
> sound negative here, but I would (suprisingly) be very in favor of a simple ,
> screaming "sample playing kernel".
Yes I plan to keep the structure quite simple, therefore plugins will do a good
job to encapsulate the complexity in modules.
>(the performance you gave are astounding.
> Which hardware has it been tested on ? solid state HD + Alpha 1GHz chip & 1GB
> RAM ?) Just a personal opinion, though.
nothing special:
PII400 128MB RAM , IBM EIDE 16GB (1.5-2 years old) + SB AWE64
running on 2.2.10/15 + lowlatency patch ( it works on a regular kernel too
but sometime you hear small clicks because of the suboptimal scheduler of
standard linux)
>
> As a side note, am i writing a (yet another ?) composition tool in python (the
> beauty of that language made me use it overnight ), which aim is to have non
> realtime plugins (read python DSP & interfaces scripts) for composing great
> sounds, and render them to .wav. Intermediary buffers would be stored on disk
> (read non destructive editing), and linux would cache them in memory as he
> wishes. Processing will be done with python's numerical extensions (read basic
> blocks would be arrays of samples, a la Matlab). That would leave a simple, yet
> EASILY EXTENDABLE ground to build in. Nothing new or exciting here, but I
> intend to make this a really fine thing to play with, i.e. most effort will go
> to the GUI interface, modularity, and CLEAR and SIMPLE CODE : you have (quite
> high level) building blocks, a mouse and a fat hard drive, then you play with
> this app, connecting things together and rendering you wav as you are finished.
Sounds kinda cool, something similar to the GDAM LADSPA plugin maker but
more elaborated ? ( http://www.ffem.org/gdam/ladspa.html )
> I needed a way to play those samples (I intend to toy with signal
> processing, "high level" programming and GUI, ___not___ system optimizations.
> You guys are too far away in that ground for me) and this soft sampler is be
> THE thing I wanted to happen. Bravo, Benno, bravo.
thanks, and yes, these "system optimizations" are a big pain in the ass,
it takes looong experience and failures to get all pieces together.
Applications like the disksampler are one of the reasons why I am advocating
the low-latency patches so much. Without them reliable realtime audio would
never be possible.
Think about that I spent only 3 days laying out the basic engine (which IS
simple).
Ok I recycled the lock-free fifos and stream classes from hdrbench, but you see
that it is much easier to stay in userspace and using C++, than writing
such engines in kernel space and in assembly as it happens under windows.
I recall a statement of an engineer of Seersystems (Reality Synth), which
said that about 50% of the development time was spent on dealing with
windows drivers issues in order to drive the latencies down to acceptable
levels (Reality runs within the soundcard driver in order to achieve the
required latencies).
I hate these kludges because it is just a waste of time, I prefer to focus on
real algorithms instead how to trick out the OS.
And with high probabilty these kludges will backwire at some point.
(incompatibilities with other drivers , new OS versions, certain hardware etc)
>
> Another thing is, I think gnome (yes, it will be a bloated-yet-userfriendly-
> whatever-this-word-means gnome-app) is looking for a replacement for esound
> (though i'm not sure of it - don't flame). That app may fill the need here : a
> very solid sample playing proggy with not too many bells and whistles - for
> now, let's hope :) .
The soundserver is a big dilemma because if you want low-latency among multiple
applications running simultaneously, the only way to go is like I described in
my other mail , but that required the application to be designed to fit in this
model.
"normal" applications can use soundservers ala esound, but
for us high-end people, we have to control every part of the audio signal path
from the userapplication down to the kernel audio API.
So the gnome folks and KDE folks can not wait forever for our soundserver
model. (and applications can not be forced to adopt ir)
I think that meanwhile , the GNOME and KDE folks should continue to use their
existing soundservers or develop their own ones, but they will not fullfill our
requirements.
Benno.
This archive was generated by hypermail 2b28 : Thu Jul 13 2000 - 20:56:37 EEST