Re: [PD] most efficient use of [partconv~]

2008-05-20 Thread Roman Haefeli
On Mon, 2008-05-19 at 09:12 +0200, Frank Barknecht wrote:
> Hallo,
> Roman Haefeli hat gesagt: // Roman Haefeli wrote:
> 
> > i made a patch, that uses several instances of an abstraction based on
> > the partconv~ external in order to do binaural spatialization of sounds
> > using a set of hrtf tables.  the hrtf files are all loaded on loadbang
> > into tables, so that they can be accessed quickly. it is part of the
> > patch, that a 'set ' message to all [partconv~]s is sent
> > quite often, which leads to dropouts on the box, where the installation
> > is meant to run (for some reason not on my personal laptop). i also
> > noticed a difference in performance between an old version of partconv~
> > (0.1) and the current svn version, whereas the latter is more likely to
> > cause dropout at high 'set' message rates. 
> 
> I had a quick look at the partconv~ source code and found that
> everytime a "set" message is sent, partconv~ does quite a bit of
> memory allocation to configure itself for the new convolution core.
> This may be a reason for the dropouts if you "set" the objects with a
> high rate, as memory allocation is not very realtime friendly. You
> could try to avoid some of the "set"s by creating more partconv~
> objects that statically refer to their tables. Of course that's a bit
> tricky with 1400 tables ...

thanks for confirming, what i guessed. so one (probably not the
smartest) solution is to use a computer with fast memory access. in my
case, lowering the message rate and increasing jackd buffersize a bit
already helped.

roman



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] most efficient use of [partconv~]

2008-05-19 Thread Frank Barknecht
Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:

> i made a patch, that uses several instances of an abstraction based on
> the partconv~ external in order to do binaural spatialization of sounds
> using a set of hrtf tables.  the hrtf files are all loaded on loadbang
> into tables, so that they can be accessed quickly. it is part of the
> patch, that a 'set ' message to all [partconv~]s is sent
> quite often, which leads to dropouts on the box, where the installation
> is meant to run (for some reason not on my personal laptop). i also
> noticed a difference in performance between an old version of partconv~
> (0.1) and the current svn version, whereas the latter is more likely to
> cause dropout at high 'set' message rates. 

I had a quick look at the partconv~ source code and found that
everytime a "set" message is sent, partconv~ does quite a bit of
memory allocation to configure itself for the new convolution core.
This may be a reason for the dropouts if you "set" the objects with a
high rate, as memory allocation is not very realtime friendly. You
could try to avoid some of the "set"s by creating more partconv~
objects that statically refer to their tables. Of course that's a bit
tricky with 1400 tables ...

Ciao
-- 
 Frank Barknecht _ __footils.org__

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


[PD] most efficient use of [partconv~]

2008-05-17 Thread Roman Haefeli
hi again

i made a patch, that uses several instances of an abstraction based on
the partconv~ external in order to do binaural spatialization of sounds
using a set of hrtf tables.  the hrtf files are all loaded on loadbang
into tables, so that they can be accessed quickly. it is part of the
patch, that a 'set ' message to all [partconv~]s is sent
quite often, which leads to dropouts on the box, where the installation
is meant to run (for some reason not on my personal laptop). i also
noticed a difference in performance between an old version of partconv~
(0.1) and the current svn version, whereas the latter is more likely to
cause dropout at high 'set' message rates. 

there are some things, that i don't know, which might affect
performance. for instance, what is the recommended blocksize of the
subpatch, that contains an object [partconv~]? is the optimal blocksize
dependent on the size of the impulse response? is using [partconv~]
generally not the best option to implement hrtf? if so, what are better
ways?

thanks in advance for any help.

roman





___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list