[linux-audio-user] Re: [Jackit-devel] Re: [linux-audio-dev] [ANNOUNCE] jack_convolve-0.0.1
29 Jan
2005
29 Jan
'05
11:51 a.m.
oops, sent to fons only.. here's the mail to the lists, too. sorry for
duplicate, fons:
On Sat, 29 Jan 2005 16:16:04 +0100
Fons Adriaensen <fons.adriaensen(a)skynet.be> wrote:
ack!
The real cost is in the complex multiplications though. So if anyone
knows how to speed that up with a nifty function using
assembler, prefereably following this interface:
// computes n complex multiplications and _add_s the results to the out buffer
void complex_multiply(unsigned int n,
fftwf_complex *in1,
fftwf_complex *in2,
fftwf_complex *out);
i would be oh so greatful.
So the TODO list as grown to:
- fix error checking
- add multiple response file support as explained above
- add libsamplerate supprt for converting response files to jack samplerate
- optimize the complex multiplication
flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
On Sat, Jan 29, 2005 at 03:43:46PM +0100, Florian
Schmidt wrote:
ack!
Now i grok it.
As a stereo impulse file is a response to a mono impulse placed
somewhere in the room, one needs two stereo response files with the
impulses created at different points in the room.
Yep, that's it. Even for a stereo output, you could have more than
two inputs, each one corresponding to one place in the room. I will adapt the convolver to be able to load
more than one response
file and provide an input for each. And as many outputs as the response
files have channels (for two stereo response files, that's two channels
'cause they are stereo)..
That would do it. And then of course the input transform is done only
once, and the additions can be done in the F-domain, so there's also
only one output transform for each output.
29 Jan
29 Jan
1:13 p.m.
On Sat, 29 Jan 2005 16:57:04 +0100
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
- fix error checking
- add multiple response file support as explained above
- add libsamplerate supprt for converting response files to jack samplerate
- optimize the complex multiplication
forgot an important one:
- decouple the partitioned convolution chunk size from the jack buffer
size. This will allow to run a 2048 frames chunk sized partitioned
convolution in a i.e. 256 frames jack graph. Of course the latency of
the chunksize remains, but i will set the jack port latency, so DAW's
like ardour can compensate for it.
Btw: All help appreciated. So if anyone wants to join in, feel free
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
30 Jan
30 Jan
12:22 p.m.
Florian Schmidt <mista.tapas(a)gmx.net> writes:
forgot an important one:
- decouple the partitioned convolution chunk size from the jack buffer
size. This will allow to run a 2048 frames chunk sized partitioned
convolution in a i.e. 256 frames jack graph. Of course the latency of
the chunksize remains, but i will set the jack port latency, so DAW's
like ardour can compensate for it.
There's code in JAMin to do this. It's a bit of a hack, but look at
the DSP thread logic in `src/io.c'. If the JACK buffersize is at
least 256 frames (our preferred FFT window size), io_process() calls
process_signal() directly in the JACK thread. Otherwise it queues the
data to a separate lower-priority DSP thread which calls it there. It
updates the port latencies accordingly and even handles bufsize
changes.
One simple improvement I'd recommend. JAMin runs its DSP thread at a
RT priority one less than the JACK process thread. It would be better
to add (log2(bufsize)-log2(chunksize)) to the JACK priority (only when
negative). Then, multiple JACK client helper threads could share RT
scheduling cooperatively, so the ones with lower scheduling deadlines
get to run first. I think that works for any collection of sizes,
assuming the total CPU bandwidth is sufficient.
So, assuming I make a compatible change in JAMin, with a JACK bufsize
of 64 frames we'd get...
JAMin DSP thread priority (7) = (9+log2(64)-log2(256))
jack_convolve thread priority (4) = (9+log2(64)-log2(2048))
Maybe we should invent a new JACK thread service to encapsulate this
concept for clients with cooperating realtime helper threads. I've
thought about doing that before, but there wasn't much point with
JAMin the only user.
Btw: All help appreciated. So if anyone wants to join
in, feel free
I can answer questions about the JAMin implementation. But, I don't
have time to actively help you right now. Maybe later.
Nice project, good luck!
--
joq
11:34 p.m.
New subject: [linux-audio-user] Re: [Jackit-devel] Re: [linux-audio-dev] [ANNOUNCE] jack_convolve-0.0.1
On Sat, 29 Jan 2005 18:20:02 +0100
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
Btw: All help appreciated. So if anyone wants to join
in, feel free
Hi,
Ok, i reworked the code as library (reimplemented in C, too, instead of
C++). It _should_ support several response files each providing one
input channel (only tested with a single repsonse file yet). Each
response file must have the same number of channels. The number of
channels determines how many output channels you get. These outputs
carry the output of each convolution mixed together (that's the reason
why each response file must have the same channel count). If you need to
convolve response files with different channel counts or need each the
channels of each convoluted output seperatly, just use multiple
different convolutions (the library should allow that, not yet tested).
I decided to incorporate the special (though rather common) case of all
response files having the same channel count and their output mixed
since it saves some cycles.
I decided against implementing a decoupling of the process size from the
partition size in the library, as there exist various approaches and it
is better left to the user to choose one that suites him. I don't know
yet if i'll add it to the jack cli client. we'll see.
The jack_convolve command line client in the current tarball is heavily
broken, but the convolvetest program kinda took its place.. It has even
less error checking than the original jack_convolve client (segfaults if
no filename is specified for example ;).. It seems though it has become
a little bit more cpu friendly (0.8s stereo response file at 10 - 12%
dsp load on my 1.2ghz athlon box with 2048 buffer size. around 33% with
512 frames), so it actually starts to get quite usable.
So if anyone wants to wrap it in DSSI, go ahead :) I'll keep on
improving the jack cli client (loading multiple responses, libsamplerate
support).
http://www.affenbande.org/~tapas/jack_convolve/jack_convolve-0.0.3.tgz
The interface consists of 3 api calls :)
convolution_init(...) // initialize, pass repsonses to it, etc..
convolution_process // process one chunk of audio
convolution_destroy // clean up (not implemented yet)
I will have to do some cleaning up, etc.. but if you want to try it with
some of your response files, go ahead and let me know how it works for
you..
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
7291
days inactive
7292
days old
linux-audio-user@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
Florian Schmidt -
Jack O'Quin