Subject: Re: [linux-audio-dev] Reverbs... and the usual whinings
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: Fri Sep 22 2000 - 15:56:23 EEST
Hey, maintainers, could you turn the [linux-audio-dev] to a simple [LAD]?
In Emacs I can see only a couple of first letters of the real subject.
If that is possible, thanks!
Below after reverb matters I have some whinings about recording problems,
(yes, again) and so on, and so on. I also request a help <wink>.
>From: Paul Winkler <slinkp23_AT_yahoo.com>
>
>Well, my impression is that with reverb, the details of
>implementation can make a big difference, so maybe Mikelson
>didn't get it quite right.
I will clone them to my system later and check what is going on.
Since they are running on Csound, the problem could be the inaccuraties
in Csound.
>> The freeverb binary Ladspa release sounded ok, but when I reimplemented
>> it and close-listened, it didn't sound that good. Or my implementation
>> is not exactly the same
>
>That's my guess. Or you have more discerning taste!
Have been busy this week -- I have not yet rewritten (second time)
the Freeverb. I will use slightly different approach this time and will
rewrite my delay line codes.
I got the impulse response, by the way. Thanks.
>I think this is the waveguide reverb Sean Costello
>implemented in csound. It sounds quite nice in that version.
Heh, I will clone that too later-later.
>> little birds have told me that you will soon have one very good reverb
>> as a Csound opcode. Its implementation can be a realtime even its present
>> implementation is not. The same algorithm is used in a few commercial
>> plug-in reverbs.
>
>Interesting. What's your algorithm like?
CUD mailing list had just announce that it will be released tomorrow or so.
It is Rocchesso's Babo (Ball in a box) algorithm. It uses CFDN structure
which is documented in Julius O. Smith's homepage (paper by Rocchesso and
JOS). The fast implementation is described in Rocchesso's own paper
in Signal Processing Letters. I have the second paper on-line for curious
readers.
There is a FDN patent by Jean-Marc Jot (at Creative) but I'm quite sure
it doesn't make harm here. Rocchesso's maximally flat design is quite
an invent in its own and FDN (as we know it now) has been described by
Stautner and Puckette. (Miller, could you please make that paper available
on-line?)
This is not the end of reverb business: I'm working on my own plate reverb
algorithm and there are yet unimplemented those non-exponential decay
reverbs by amazing HUT Acoustics lab guys here in Finland. And my low-latency
granular reverb algorithm still sounds good but I have to time to finish my
implementation. And don't forget FFT-based bandsplitted reverbs by those
German guys. Further, I plan to implement a convolution based reverb
in which impulses are generated with noise (a la Moorer, 1979).
-*-
Unfortunately all this needs time. And unfortunately I have to make a break
in my reverb development because I need a reliable recorder program
_yesterday_. Yet again Linux/Alsa/arecord gave dropouts even when I did
nothing. It so unreliable. (Of course, arecord is just an example code
which just happen to be located at /usr/bin/ instead of more correct place
/usr/doc/alsa-examples/ ;-) (As an example, aplay/arecord is too messy
hacked code.) The fact is I have now three dropouts in three recordings;
or even more because Alsa seems to not report all dropouts (merely 1 reported
dropout when half minute audio is completely jumping). Does sound good
for Steinberg and others if 98% of Linux users has similar system than
I have. Sad thing is that I have not succeeded to compile other recorders
because they need some newer libraries (and I have Debian from last fall,
not any older version!). The same thing with audio wave editor: there is
no editor which has a proper editing tool with crossfades _and_ compiles
in my not so old Debian. I have to back up those dropouted recordings
for future editing.
What about my own wave editor or recorder? I started writing my reliable
recorder yesterday for some unknown reason... ;-) Wave editor is waiting
for some utils.
And I would need a help in writing those utils. Here is a short descriptions
about what I have been writing:
-A message system for sending commands from any process/thread
to any other process. For example, I have a waveform drawing service
in one process --- any future wave editor running in its own process
should be able to connect to the graphing service. This would be relatively
easy with threads but my routines will support both threads and processes
transparently. (I'm using fork() only.)
-A system for forking child processes. With threads, it could be easier
(but may not be). With processes, we have to carry message systems and
all that kind of systems with us explicitly. My routines will do it
transparently.
-An FD-server which listens to an FD. User defines callbacks for defined
messages.
-Socket-server for implementing socket-services without pain. Callbacks
as well.
-Simple routines for opening Alsa for 16-bit/stereo/44100 Hz
etc. recordings/playings. Alsaplayer code could be good but it is in
C++, and is for playing only.
-Simple common front end for GTK drawing areas and images (callbacks must
be changeable from another process).
There are some more routines for shared memory, message queues, lock-free
buffers, RT scheduling, etc. I have initial code for many of these and above
mentioned. If you would like to look at them, please mail me privately.
I plan to put them freely available (but I'm not even suggesting others
should use them too). I have used closure/object model in writing these.
Thus, it should be easy to support more complex object-oriented techniques
later (in C, that is).
Simple dicussions here would be okay too. I can post detailed descriptions.
Best Regards,
Juhana
This archive was generated by hypermail 2b28 : Fri Sep 22 2000 - 16:49:20 EEST