10 Aug
2005
10 Aug
'05
7:34 a.m.
Hi,
i played around with extra buffering the input/output of libconvolve
(new tarball [1] and updated jack_convolve [1] (understands the
--partitionsize=frames argument now which makes it use the specified size
for the partition size instead of the jack buffersize), and like
expected this doesn't do CPU usage any good.
Easy to see in this example:
jack_buffersize = 1024
partitionsize = 2048
Now the convolution code is executed only every second jack process()
cycle. If the previous DSP usage was like 20% in every process cycle
then it's ca. 25% in every other cycle now (estimate).
The solution to even out the load is to use an extra thread [2].
For best performance i would assume that the DSSI needs an extra thread
with RT scheduling (if available) and an RT prio which should be lower
than all the other jack and midi threads of i.e. the DSSI host and other
jack clients.
So i got basically two questions:
a] is it possible to use threading in a DSSI?
b] would a RT prio of 1 (for the convolution thread) be an OK
compromise? It will be lower than all audio stuff on a typical jack
system? What is jackd's default RT prio again?
Regards,
Flo [3]
[1] - http://tapas.affenbande.org/?page_id=5
[2] - yes, i'm aware that this needs again some extra buffering ;) But
this whole larger-partitionsize-than-jack-buffersize-thing is all about
trading latency for cpu niceness. If the convolution is used as non RT
effect [like i.e. in a DAW for prerecorded material], then latency
doesn't matter as long as the host compensates for it.
[3] - i'll probably be offline from the 12th on, as i can't pay my phone
bill, so be quick with answers ;)
--
Palimm Palimm!
http://tapas.affenbande.org
10 Aug
10 Aug
8:01 a.m.
On Wed, Aug 10, 2005 at 11:34:39AM +0200, Florian Schmidt wrote:
a] is it possible to use threading in a DSSI?
I've done this in some LADSPAs, it works.
b] would a RT prio of 1 (for the convolution thread)
be an OK
compromise? It will be lower than all audio stuff on a typical jack
system? What is jackd's default RT prio again?
When running in JACK, you can obtain JACKS thread id and then
look up its priority. Otherwise, you can query the thread's prio
the first time your process() is called and then create a thread
just below it.
[2] - yes, i'm aware that this needs again some
extra buffering ;)
It doesn't need to: the extra buffering can be absorbed into the
buffers you need anyway - zero overhead. I've got a C++ implementation
of this, just drop me a line if you want it.
--
FA
8:28 a.m.
On Wed, 10 Aug 2005 12:01:17 +0200
Alfons Adriaensen <fons.adriaensen(a)alcatel.be> wrote:
Great tips. Thanks.
Let's play this through with an example. For simplicity's sake let's
assume the host always calls the plugins run() method with a constant
buffersize of 1024 frames (there's still no requirement for this though
- important to keep in mind) and the internal partitionsize of the
convolution is 2048 frames. Let's further assume the convolution thing
has internal input and output buffers of 2048 frames each. The input
buffer is initially empty and the output buffer is initially full
(filled with 0's)
- run() 1: 1024 frames are filled into the input buffer. Also 1024
frames are output from the output buffer
- run() 2: 1024 frames are filled into the input buffer and 1024 frames
are consumed from the output buffer. The input buffer is now full and
the output buffer empty. We have enough data now to do tha thang. So we
somehow (how? [1]) communicate to the convolution thread that it should
start to do process the input buffer now. We don't know yet when it will
finish, but to meet any sort of deadline it should finish before another
2048 frames have arrived.
- run() 3: 1024 frames are filled into the input buffer -> ouch. The
input buffer is what the convolution thread operates on right now. 1024
frames are consumed from the output buffer -> ouch, it's empty, plus
this is where the convolution thread puts its output.
The problem i see should be clear now. The solution i would use would be
to make both input and output buffers twice the partition size (you can
probably fill in the blanks :). I have also ignored the remaining
synchronization issues.
Damn, need to run to university now. I'll read up lateron..
Flo
[1] - the typical
rt-safe-kicking-off-another-thread-to-do-something-problem raises
its ugly head again. What other options are there? sleeping for short
intervals and lay down again when nothing to do?
--
Palimm Palimm!
http://tapas.affenbande.org
On Wed, Aug 10, 2005 at 11:34:39AM +0200, Florian
Schmidt wrote:
Great..
a] is it possible to use threading in a DSSI?
I've done this in some LADSPAs, it works. b] would a RT prio of 1 (for the convolution
thread) be an OK
compromise? It will be lower than all audio stuff on a typical jack
system? What is jackd's default RT prio again?
When running in JACK, you can obtain JACKS thread id and then
look up its priority. Otherwise, you can query the thread's prio
the first time your process() is called and then create a thread
just below it. [2] - yes,
i'm aware that this needs again some extra buffering ;)
It doesn't need to: the extra buffering can be absorbed into the
buffers you need anyway - zero overhead. I've got a C++ implementation
of this, just drop me a line if you want it.
10:09 a.m.
On Wed, Aug 10, 2005 at 12:28:01PM +0200, Florian Schmidt wrote:
Let's play this through with an example. For
simplicity's sake let's
assume the host always calls the plugins run() method with a constant
buffersize of 1024 frames (there's still no requirement for this though
...
Sorry, I didn't express myself correctly. There is indeed more delay,
but what I'd wanted to say is: there is no need for copying your signal
into one more layer of intermediate buffers.
The problem i see should be clear now. The solution i
would use would be
to make both input and output buffers twice the partition size (you can
probably fill in the blanks :). I have also ignored the remaining
synchronization issues.
For th input you could use two buffers of the FFT size each. When one is
half full, you hand it over to the lower priority thread and start using
the other. Or you could use just one and do the forward FFT on the input
in the original thread. This will probably be just a small part of the
total work to be done for that input, so it should work, but will give
an somewhat uneven load as seen from the caller.
On output you probably already have a circular buffer to keep the
partial results in between processing calls for one partition. If you
make it one partition size longer than what it would normally be,
and set the initial output pointer one partition size before the end,
there is no need to make extra copies.
The result of this all is that if period_size >= partition_size, you
have one more partition delay than strictly necessary. In that case
just advance the initial output pointer to the start of the circular
buffer.
For synchronisation, you need to wake up the worker thread somehow
when a partition of input is available. A Posix sema or condition
variable will do. Assuming the system is not overloaded, there is
no need to sync in the other direction - just assume that your
worker thread has done its job and read the results.
--
FA
11 Aug
11 Aug
7:31 a.m.
On Wed, 10 Aug 2005 14:09:55 +0200
Alfons Adriaensen <fons.adriaensen(a)alcatel.be> wrote:
Hi,
thanks for your answer.
Sorry, I didn't express myself correctly. There is
indeed more delay,
but what I'd wanted to say is: there is no need for copying your signal
into one more layer of intermediate buffers.
Right.
On output you probably already have a circular buffer
to keep the
partial results in between processing calls for one partition. If you
make it one partition size longer than what it would normally be,
and set the initial output pointer one partition size before the end,
there is no need to make extra copies.
Yep..
The result of this all is that if period_size >= partition_size, you
have one more partition delay than strictly necessary. In that case
just advance the initial output pointer to the start of the circular
buffer.
I plan to have two modes.
a] 0 - latency, where Partitionsize == periodsize and without any extra
buffering, etc.. This is practically zero latency but with the expected
cpu usage.
b] buffered/threaded - where Partitionsize > periodsize, and the
buffering/threading scheme we talk about here is used.
The case where periodsize is > partition_size is really not common i'd
reckon. The user could use the 0 - latency mode here.
For synchronisation, you need to wake up the worker
thread somehow
when a partition of input is available. A Posix sema or condition
variable will do. Assuming the system is not overloaded, there is
no need to sync in the other direction - just assume that your
worker thread has done its job and read the results.
Sounds good. Thanks for the info.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
10 Aug
10 Aug
11:20 a.m.
Florian Schmidt <mista.tapas(a)gmx.net> writes:
So i got basically two questions:
a] is it possible to use threading in a DSSI?
Probably. It works in LADSPA.
b] would a RT prio of 1 (for the convolution thread)
be an OK
compromise? It will be lower than all audio stuff on a typical jack
system? What is jackd's default RT prio again?
For your example, I suggest a prio 1 lower than the JACK process
thread. In general I recommend setting the priority one lower for
each extra power of two in the helper thread's cycle time (so longer
cycles run at lower priority).
I think JAMin (src/io.c) does something very similar to what you want.
--
joq
7073
days inactive
7074
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
3 participants
participants (3)
-
Alfons Adriaensen -
Florian Schmidt -
Jack O'Quin