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

On Thu, May 31, 2012 at 3:02 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Jun 1, 2012 at 4:03 AM, Philip Jägenstedt <philipj@opera.com>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?
>

I think it's ok to require a DelayNode.  In the teleconference we talked
about how to deal with the case where there is no DelayNode and yet a
feedback loop has been created.  I had suggested that we would throw an
exception when the connect() method is called, which is one solution.
 Opera had concerns about the overhead of checking this constraint for
every connect() call and proposed an alternate solution of rendering
silence for any loops not containing delays.  In other words, if I
understand Opera's model, the feedback loop (without delay) would be
detected internally during audio rendering and this connection would be
ignored (silence generated).  I think either approach is ok.


>
>
>> 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.
>

Yes, I tend to agree.


>
> (BTW is there any implementation difficulty using block sizes as low as
> 16? I can't think of one, other than reduced efficiency.)
>

No, it's not that hard to implement very small block sizes, but performance
given today's hardware is important to consider if the block size is small
*and* the sample-rate is high.  But, I think your point is that for low
sample-rates (like the example of 8KHz), this performance hit does not
happen.  So I think I agree with you there.



>
>  (Another approach is to just not allow loops, and I'm looking forward to
>> hear what Robert O'Callahan has to say on that.)
>>
>
> Chris said loops were an essential feature, and I believe him. They do
> interact poorly with many other features though. It's a problem.
>
> We already have the constraint that loops must contain a certain amount of
> delay. We will probably have to add more constraints on loops, e.g. that
> certain high-latency processing can't be used in a loop.
>

Maybe so.  But I think we should be able to define the behavior well if all
nodes are internal given some further discussion.

Cheers,
Chris


>
> Rob
> --
> “You have heard that it was said, ‘Love your neighbor and hate your
> enemy.’ But I tell you, love your enemies and pray for those who persecute
> you, that you may be children of your Father in heaven. ... If you love
> those who love you, what reward will you get? Are not even the tax
> collectors doing that? And if you greet only your own people, what are you
> doing more than others?" [Matthew 5:43-47]
>
>