Re: Limit in sample or ms for circular routing (Re: Minutes of Audio WG Teleconference, 2012-05-30)

On Fri, 01 Jun 2012 00:02:36 +0200, Robert O'Callahan  
<> wrote:

> On Fri, Jun 1, 2012 at 4:03 AM, Philip Jägenstedt <>  
> wrote:
>> To be specific, if one tries to create a loop with 0 delay, it will be
>> clamped up either to a fixed number of samples (probably 64 or 128, to  
>> be
>> defined) or to a fixed number of milliseconds.
> What do you mean by "a loop with zero delay"? A loop with no DelayNodes
> can't be rescued since you don't know where to put the delay. How is this
> "clamp up" supposed to work?

First we need to define what it means to be in a loop. Let's assume that  
after every modification the strongly connected components [1] of the  
graph are found. For each of those components:

1. If there is no DelayNode in the component, mark all nodes in that  
component as disabled, such that they will not process their input, nor  
produce any output. Any script/worker nodes in the component will not  
receive callbacks at all.

2. If there are delay nodes in the component, set an "in loop" flag on  
those nodes.

Finally, remove the "in loop" flag on any DelayNodes which are not part a  
strongly connected component, since they may previously have been.

When the audio graph is running, for each DelayNode, for each time the  
k-rate delayTime is sampled (every 128 samples, presumably), calculate the  
delay in samples as:

delaySamples = round(delayTime * sampleRate) // sampleRate of context
if (in_loop && delaySamples < 128)
   delaySamples = 128

Note the round(), which makes it clear exactly how many samples to shift  
the input by. I presume that no one wants to resample to support  
sub-sample delays.

The output y of the input x is then:

y[k] = x[k-delaySamples]

The implementation must buffer enough to fulfill this. ISSUE-47 will also  
require defining how the smoothing works, presumably the above is not what  
Chris has implemented.


>> Defining it in milliseconds breaks for low sample rates, e.g. a 3 ms  
>> clamp
>> at 8 KHz is just 24 samples, below the block size any implementation  
>> will
>> want to use.
> So, give your implementation a minimum sample rate.
> (BTW is there any implementation difficulty using block sizes as low as  
> 16?
> I can't think of one, other than reduced efficiency.)

It seems plausible to me that one wants fixed-size blocks, and that there  
will be some book-keeping overhead memory usage. Given that, it's just a  
question of picking the biggest size that doesn't limit the useful effects  
one can perform, I'm guessing.

Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 4 June 2012 10:18:00 UTC