Hi, I'm attempting to figure out how a different block size in a subpatch promotes latency. The parent is actually fixed at a block of 64 as it would be reasonable, and then I'm trying bigger block sizes inside a subpatch.
What I can detect is that the delay is always blocksize - 64. So yeah, a block of 64 or smaller promote no latency, but it increases to 64 samples for a 128 block, 192 for 256 block and so on... But I don't understand why as my intuition was that the latency should be the whole block of audio, and not that minus 64! Plus, I also find something weird about how it works... keep reading.
As the test signal, I have a sample count that starts counting from 1. When it receives a bang, the count gets reset to 1 and restarts. With that, I can print the input/output plus the subpatch block and check them out.
See the attached test file. It has a block of 128 inside the subpatch. When it is loaded, the subpatch waits 64 samples filled with zeros before it receives the sample count signal. You can click on the bang and redo the test and you may find that the subpatch can behave in the same way, where the first half of samples have not restarted the count yet *OR* you may have been lucky enough to sync them up and find that the subpatch's block actually starts counting from 1 as well!!!
Weird thing is that, even so, the output gets still delayed somehow.
I'm not sure if I can make myself clear or that you follow me, but the bottom line is that I'm still quite confused on how different block sizes behave in Pd!
Where can I read more about this, has someone done similar tests and have figured this out completely?
Thanks
actually it's quite simple: if both subpatch and parent patch have the same block size there's obviously no latency involved, only if the subpatch blocksize is larger than the parent blocksize you start to get latency, so you have to look at the *difference* in block size.
the reason is that a reblocked subpatch has to wait for (subpatch blocksize - parent blocksize) samples until it has enough samples to process its first block. before that it will output zeroes.
Gesendet: Freitag, 11. Januar 2019 um 17:47 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: [PD] understanding block latency
Hi, I'm attempting to figure out how a different block size in a subpatch promotes latency. The parent is actually fixed at a block of 64 as it would be reasonable, and then I'm trying bigger block sizes inside a subpatch. What I can detect is that the delay is always blocksize - 64. So yeah, a block of 64 or smaller promote no latency, but it increases to 64 samples for a 128 block, 192 for 256 block and so on... But I don't understand why as my intuition was that the latency should be the whole block of audio, and not that minus 64! Plus, I also find something weird about how it works... keep reading. As the test signal, I have a sample count that starts counting from 1. When it receives a bang, the count gets reset to 1 and restarts. With that, I can print the input/output plus the subpatch block and check them out. See the attached test file. It has a block of 128 inside the subpatch. When it is loaded, the subpatch waits 64 samples filled with zeros before it receives the sample count signal. You can click on the bang and redo the test and you may find that the subpatch can behave in the same way, where the first half of samples have not restarted the count yet OR you may have been lucky enough to sync them up and find that the subpatch's block actually starts counting from 1 as well!!! Weird thing is that, even so, the output gets still delayed somehow. I'm not sure if I can make myself clear or that you follow me, but the bottom line is that I'm still quite confused on how different block sizes behave in Pd! Where can I read more about this, has someone done similar tests and have figured this out completely? Thanks _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em sex, 11 de jan de 2019 às 18:23, Christof Ressi christof.ressi@gmx.at escreveu:
the reason is that a reblocked subpatch has to wait for (subpatch blocksize - parent blocksize) samples until it has enough samples to process its first block. before that it will output zeroes.
Ok, my intuition was telling me that it needs to wait for "subpatch's blocksize" samples until it has enough samples to process its first block. But trying to make sense, it seems that for the first processing round it waits and fills with zeros until it can receive the block of 64 samples from the parent so it completes its block size, so we actually have the first bigger block of samples containing the 64 sample block from the parent! If you measure the difference, the latency is actually a bit shorter. Yeah, that makes sense in the end, phew...
The confusion comes from expecting that the larger reblocked subpatch needed to start and get its first samples from the incoming signal sent by the parent. Then you'd have to wait until a whole block is filled until it gets output next. Then the delay would be the block size, right?
Now onto the other part, which I can't figure out yet. Cause in my attached example, what I just mentioned in the last paragraph actually happens. You can have the blocks synced up and you can see in the output of print~ that the incoming block from the parent counts from 1 to 64, here's the console print.
*input:* 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 64
The reblocked subpatch then counts from 1 to 128!
*subpatch:* 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 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128
But the output is actually still delayed by (blocksize - 64). In the output I need a [delay 1 64 samp] object to get the same incoming block.
And I can't actually get my head around that, just seems weird and I can't make sense.
Cheers
Hmmm... It seems that occasionally, the bang into the subpatch doesn't get there in the actual start of the block, but in the middle of it. Hence it gives us the illusion of being synced up with the parent. But it's not, it's just that the printed output is in fact delayed already. But that doesn't mean the actual block is delayed, of course.
Now I made sense of it, right? :)
thanks!
Em sex, 11 de jan de 2019 às 18:57, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex, 11 de jan de 2019 às 18:23, Christof Ressi christof.ressi@gmx.at escreveu:
the reason is that a reblocked subpatch has to wait for (subpatch blocksize - parent blocksize) samples until it has enough samples to process its first block. before that it will output zeroes.
Ok, my intuition was telling me that it needs to wait for "subpatch's blocksize" samples until it has enough samples to process its first block. But trying to make sense, it seems that for the first processing round it waits and fills with zeros until it can receive the block of 64 samples from the parent so it completes its block size, so we actually have the first bigger block of samples containing the 64 sample block from the parent! If you measure the difference, the latency is actually a bit shorter. Yeah, that makes sense in the end, phew...
The confusion comes from expecting that the larger reblocked subpatch needed to start and get its first samples from the incoming signal sent by the parent. Then you'd have to wait until a whole block is filled until it gets output next. Then the delay would be the block size, right?
Now onto the other part, which I can't figure out yet. Cause in my attached example, what I just mentioned in the last paragraph actually happens. You can have the blocks synced up and you can see in the output of print~ that the incoming block from the parent counts from 1 to 64, here's the console print.
*input:* 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 64
The reblocked subpatch then counts from 1 to 128!
*subpatch:* 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 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128
But the output is actually still delayed by (blocksize - 64). In the output I need a [delay 1 64 samp] object to get the same incoming block.
And I can't actually get my head around that, just seems weird and I can't make sense.
Cheers
Hi,
IIRC the first block is wrote at the end thus in a 256 reblocked sub-patch you have:
First vector:
X X X A
Then:
B C D E
That probably explains the latency to be (256 - 64).
HTH.
-
Alexandre Torres Porres -
Christof Ressi -
Nicolas Danet