Hi!
I have a problem with the latency between some parts of my patches - some of them are delayed by 64 samples (=block size). I think I've created some [r~]s before other [s~]s, which would lead to this behaviour. But: I don't know which objects are affected and I've got more than 50 [s~]s and [r~]s ;-)
The structure of the signal path is something like that:
main patch "mypatch": [pd PLAY] [pd DAC]
subpatch "PLAY": [play sig1] [play sig2] ... [play sigN]
abstraction "play.pd":
[readsf~]
|
|
[s~ $1]
subpatch "DAC":
[dac dac1] [dac dac2] ... [dac dacN]
| | |
| | |
[dac~ 1] [dac~ 2] [dac~ 3]
abstraction "dac.pd":
[r~ sigX]
|
|
[outlet~]
(playX will be set in real time to the necessary signal sigX)
Then, I want to start each of the readsf~ with different delays. To achieve that I use [1( with many [delay]s, with different delay values for each [readsf~]. Even if I quantize all delay values to the block size, I've got an additional delay of the block size on some channels, which only depends on the delay values and is not a jitter on DAC buffers!
Is it possible to determine the order of [s~] and [r~] having a look to the patch files?
I'd like to apply the suggestion of Miller to delete and recreate all [r~]s, but what I don't know is what should I do:
- recreate the single [r~] object in the abstraction "dac.pd" or
- recreate all "dac.pd "abstractions in the subpatch "DAC" or
- recreate the subpatch "DAC" itselft in the main patch or
- something else?
thanx in advance,
Piotr Majdak
Piotr Majdak wrote:
Hi!
I have a problem with the latency between some parts of my patches - some of them are delayed by 64 samples (=block size). I think I've created some [r~]s before other [s~]s, which would lead to this behaviour. But: I don't know which objects are affected and I've got more than 50 [s~]s and [r~]s ;-)
Is it possible to determine the order of [s~] and [r~] having a look to the patch files?
now, because they are not connected
I'd like to apply the suggestion of Miller to delete and recreate all [r~]s, but what I don't know is what should I do:
- recreate the single [r~] object in the abstraction "dac.pd" or
- recreate all "dac.pd "abstractions in the subpatch "DAC" or
- recreate the subpatch "DAC" itselft in the main patch or
- something else?
forget it...
the solution is order-forcing, as described in 3.audio.examples/G05.execution.order.pd
mfg.a.sdr IOhannes
Hi there,
IOhannes m zmoelnig wrote:
forget it...
the solution is order-forcing, as described in 3.audio.examples/G05.execution.order.pd
Thanks for your suggestions, it took some time to process them.
It was a heap of work and testing, but now I know definitively that I don't have any order-forcing problems.
It seems like [readsf~] or [delay] have some timing problems. I reduced my patches to something like that:
[bang( | | | | [delay X1] [delay X2] [delay X3] .... [delay Xn] [1( [1( [1( [1( [readsf~ 1] [readsf~ 1] [readsf~ 1] [readsf~ 1] [dac~ 1] [dac~ 2] [dac~ 3] [dac~ n]
(all delays are connected to the same bang!)
Assuming X1==X2==X3==Xn all dac~'s play synchronously. That's the good news.
Now let's set the delay to 140; 649.333; 789.333; 1300; 1440 (all these values are integer in block size units) and look at the outputs, relatively to the delay values. Channels 3 and 4 won't be delayed by 789.333 or 1300, but they will be played 64 samples earlier than expected. (Or all others 64 samples later).
Something really strange: just change a delay value (and don't forget to quantize it to 64 samples) and the situation will change: another channels will be played earlier. Unfortunetaly, I can't see any pattern.
Do you have an idea, what's wrong with readsf~ or delay?
regards, Piotr Majdak
Hi!
Piotr Majdak wrote:
It seems like [readsf~] or [delay] have some timing problems. I reduced my patches to something like that:
I found a solution for my delay-problems: to get accurate delays the value for the [delay]-object must be a little bit greater than the block size delay, because it will be always truncated to the smaller block size without any rounding.
E.g. set delay to 8 to get a delay of 8ms. Set delay to 9.33333333, which is the next possible delay using 48kHz and 64samples/block, and you won't get 9.333333 - you'll still get 8ms! Set delay to 9.334 and you'll get 9.333ms.
I think, the problem is a combination of float-double casting without rounding in delay_ft1() (x_time.c) and using if(sys_time < setticks) somewhere in m_shed.c.
Truncation and not rounding: is this a bug or a feature? ;-) I propose to insert a rounding operation in clock_delay() (m_shed.c).
br, Piotr Majdak
hi Piotr,
the problem is block-wise handling of 'start' by readsf~, which could (should?) be changed. The delay's output is correctly time-stamped. See the test patch, attached.
Krzysztof
Piotr Majdak wrote: ...
I think, the problem is a combination of float-double casting without rounding in delay_ft1() (x_time.c) and using if(sys_time < setticks) somewhere in m_shed.c.
Truncation and not rounding: is this a bug or a feature? ;-) I propose to insert a rounding operation in clock_delay() (m_shed.c).
#N canvas 341 331 607 420 12; #N canvas 0 0 450 300 graph4 0; #X array t 64 float 3; #A 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63; #X coords 0 63 63 0 200 140 1; #X restore 342 42 graph; #X obj 119 338 vsnapshot~; #X floatatom 119 373 5 0 0 0 - - -; #X obj 119 296 tabreceive~ t; #X msg 46 296 bang; #X obj 93 251 del; #X floatatom 39 180 5 0 0 0 - - -; #X obj 115 31 loadbang; #X obj 155 147 samplerate~; #X floatatom 151 251 0 0 0 0 - - -; #X obj 115 180 /; #X msg 115 69 1000; #X obj 115 111 t 0 b; #X obj 93 213 *; #X connect 1 0 2 0; #X connect 3 0 1 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 13 0; #X connect 7 0 11 0; #X connect 8 0 10 1; #X connect 10 0 13 1; #X connect 11 0 12 0; #X connect 12 0 10 0; #X connect 12 1 8 0; #X connect 13 0 5 0; #X connect 13 0 9 0;
Hi Krzysztof,
Krzysztof Czaja wrote:
the problem is block-wise handling of 'start' by readsf~, which could (should?) be changed. The delay's output is correctly time-stamped.
This could be the explanation why delay works exactly in all other cases. I've always tested the combination of delay and readsf~ - see my test-patch. In this patch, setting delay to 9.333333ms causes a delay of 8ms, until you set it to 9.334ms :-(
And that's my current solution: add 0.001ms to every delay. Thus, I send 8.001ms for 6 blocks and 9.334 for 7 blocks delay (SR=48kHz). Not very elegant solution, but it works for me (with some limitations).
Thanx,
Piotr
I have a problem with the latency between some parts of my patches - some of them are delayed by 64 samples (=block size). I think I've created some [r~]s before other [s~]s, which would lead to this behaviour. But: I don't know which objects are affected and I've got more than 50 [s~]s and [r~]s ;-)
see /doc/3.audio.examples/G05.execution.order.pd
it depends on the way the dsp chain is sorted ... the solution is, well, not really clean imo... (expecially, because it can add a computation overhead for an unneeded connection)
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
see /doc/3.audio.examples/G05.execution.order.pd
it depends on the way the dsp chain is sorted ... the solution is, well, not really clean imo... (expecially, because it can add a computation overhead for an unneeded connection)
But isn't that just a minor overhead?
Ciao
Frank Barknecht _ ______footils.org__
it depends on the way the dsp chain is sorted ... the solution is, well, not really clean imo... (expecially, because it can add a computation overhead for an unneeded connection)
But isn't that just a minor overhead?
sure, the overhead isn't big (maybe there is even some kind of weird optimization i haven't found) ... still when running a performance patch, i'd like to have as little overhead as possible ...
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
But isn't that just a minor overhead?
sure, the overhead isn't big (maybe there is even some kind of weird optimization i haven't found) ... still when running a performance patch, i'd like to have as little overhead as possible ...
Understandable. However for one, it's not necessary to take care of ordering everywhere, only at critical locations like delays, and second: If I'd have to choose between structuring my patch, so I can understand it better, using abstractions and subpatches or on the other hand optimizing my patch, I would always choose readability optimization over speed optimization first. Unless of course I reach my computer's limits, in which case I would probably optimize in other places rather than deleting subpatches (like using or writing externals etc.)
Just my 2ct.
Ciao
Frank Barknecht _ ______footils.org__
Hallo, Piotr Majdak hat gesagt: // Piotr Majdak wrote:
I have a problem with the latency between some parts of my patches - some of them are delayed by 64 samples (=block size). I think I've created some [r~]s before other [s~]s, which would lead to this behaviour. But: I don't know which objects are affected and I've got more than 50 [s~]s and [r~]s ;-)
The structure of the signal path is something like that:
main patch "mypatch": [pd PLAY] [pd DAC]
subpatch "PLAY": [play sig1] [play sig2] ... [play sigN]
abstraction "play.pd": [readsf~] | | [s~ $1]subpatch "DAC":
[dac dac1] [dac dac2] ... [dac dacN] | | | | | | [dac~ 1] [dac~ 2] [dac~ 3] abstraction "dac.pd": [r~ sigX] | | [outlet~] (playX will be set in real time to the necessary signal sigX)Then, I want to start each of the readsf~ with different delays. To achieve that I use [1( with many [delay]s, with different delay values for each [readsf~]. Even if I quantize all delay values to the block size, I've got an additional delay of the block size on some channels, which only depends on the delay values and is not a jitter on DAC buffers!
One problem might be, that [del] is quantized to I think, 64 samples. You cannot go below that with a [del] object. You might try the t3 objects instead.
Is it possible to determine the order of [s~] and [r~] having a look to the patch files?
Yes, somehow at least. Take a long(!) look at doc/3.audio.examples/G05.execution.order.pd
Ordering involves using subpatches which force your objects to be in a certain dsp-ordering. Maybe dummy-connecting your PLAY and DAC subpatches as shown in the example file will already help in your case.
Ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
IOhannes m zmoelnig -
Krzysztof Czaja -
Piotr Majdak -
Tim Blechmann