Hello

I'm writing a small Max patch to use Csound with Max for Live, and I
wonder how the csound~object works with regards to audio buffers.
Does Csound use the command line options when run in a csound~object ?
The console print seems to indicate that the -b flag is read, as it
says e.g. "audio buffered in 128 sample-frame blocks ", however, I
can't seem to hear any difference in latecy no matter how big or small
software buffers I use.

Is Csound's buffer size automatically related to Max's signal vector
size perhaps ?

Also, is it correct to assume that I get an extra buffering layer when
running Csound inside Max (so the latency will be equal ti Csound's
buffer size + the Max signal vector size) ?

best
Oeyvind

The -b flag will have no effect.  csound~ communicates directly
with Csound.  Think of Max's DSP settings as replacing the need
for -b and -B.  Don't pay attention to the "audio buffered in 128
sample-frame blocks" messages.

However, there is buffering.  Here's a short explanation:

When csound~ receives vectors of audio from Max, it will try to
fill up Csound's input buffers.  The size of these input buffers = ksmps.
When they're full, Csound processes one k-cycle and outputs ksmps 
sized vectors.  csound~ will fill the Max output buffers with data from 
these output vectors.   For any given set of vectors received from
Max, Csound may process zero or more k-cycles.

So, the only way this buffering can induce latency is by making
ksmps > Max signal vector size.  An extreme example would be
Max signal vector size = 1 and ksmps = 44100.  If sr = 44100, then
the latency would be 1 second.

Remember, to prevent latency between Max and csound~, make sure
ksmps <= Max signal vector size.  I hope this clears up any confusion.

Davis

-- 
View this message in context: http://www.nabble.com/csound%7E-question-tp25643571p25654833.html
Sent from the Csound - General mailing list archive at Nabble.com.

Thanks a lot, this is clear.

... well, but there is one more thing I can't get my head around:
Why do we not get added latency when ksmps < vectorsize ?
I understand that this is probably the same reason as why we don't get
added latency when patching signals through jack, but I haven't been
able to understand that either. Hope someone could have the patience
to try to explain this, as I really would like to know.

best
Oeyvind


2009/9/29 dp51 :
>
> The -b flag will have no effect.  csound~ communicates directly
> with Csound.  Think of Max's DSP settings as replacing the need
> for -b and -B.  Don't pay attention to the "audio buffered in 128
> sample-frame blocks" messages.
>
> However, there is buffering.  Here's a short explanation:
>
> When csound~ receives vectors of audio from Max, it will try to
> fill up Csound's input buffers.  The size of these input buffers = ksmps.
> When they're full, Csound processes one k-cycle and outputs ksmps
> sized vectors.  csound~ will fill the Max output buffers with data from
> these output vectors.   For any given set of vectors received from
> Max, Csound may process zero or more k-cycles.
>
> So, the only way this buffering can induce latency is by making
> ksmps > Max signal vector size.  An extreme example would be
> Max signal vector size = 1 and ksmps = 44100.  If sr = 44100, then
> the latency would be 1 second.
>
> Remember, to prevent latency between Max and csound~, make sure
> ksmps <= Max signal vector size.  I hope this clears up any confusion.
>
> Davis
>
> --
> View this message in context: http://www.nabble.com/csound%7E-question-tp25643571p25654833.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

My previous reply contains some errors.  It seems I forgot what my own code
does :|

csound~ ALWAYS adds latency = ksmps samples (regardless of Max's vector
size).
This applies to all versions up to and including v1.0.6.  You can verify
this by creating
a simple audio pass-thru orchestra and trying to achieve phase cancellation
(using
inversion and sample accurate delay).

I could make csound~ capable of zero-latency if vectorsize/ksmps = n and n
is a
positive integer.  For example:

Max vector size: 32
Possible ksmps values: 32, 16, 8, 4, 2, 1

If the above holds, then every time Max gives us vectorsize frames, we can
process
Csound n times and be guaranteed to have vectorsize output frames to match
the
vectorsize input frames (zero-latency).

DAvis



-- 
View this message in context: http://www.nabble.com/csound%7E-question-tp25643571p25673003.html
Sent from the Csound - General mailing list archive at Nabble.com.

Hey Davis,

Just to clarify, you're saying that if n is a positive integer, zero 
latency is possible, but this is not actually implemented in [csound~]? 
Because it would be awesome for those situations where sample accuracy 
is necessary.

adsr,
.mmb

dp51 wrote:
> My previous reply contains some errors.  It seems I forgot what my own code
> does :|
>
> csound~ ALWAYS adds latency = ksmps samples (regardless of Max's vector
> size).
> This applies to all versions up to and including v1.0.6.  You can verify
> this by creating
> a simple audio pass-thru orchestra and trying to achieve phase cancellation
> (using
> inversion and sample accurate delay).
>
> I could make csound~ capable of zero-latency if vectorsize/ksmps = n and n
> is a
> positive integer.  For example:
>
> Max vector size: 32
> Possible ksmps values: 32, 16, 8, 4, 2, 1
>
> If the above holds, then every time Max gives us vectorsize frames, we can
> process
> Csound n times and be guaranteed to have vectorsize output frames to match
> the
> vectorsize input frames (zero-latency).
>
> DAvis
>
>
>
>   

Yes, that's correct.  It hasn't been implemented, but I am willing to try.
I'll start messing with it next month.

To be honest, I should have implemented something like this ages ago.
It's just that I always use ksmps = some really small # and always in
a live situation.  Sample accuracy was never a concern and nobody
ever complained.  Oh well.  I guess we all have Oeyvind to thank for
getting to me actually re-read my code with a magnifying glass. 

Davis



Mike Moser-Booth wrote:
> 
> Hey Davis,
> 
> Just to clarify, you're saying that if n is a positive integer, zero 
> latency is possible, but this is not actually implemented in [csound~]? 
> Because it would be awesome for those situations where sample accuracy 
> is necessary.
> 
> adsr,
> .mmb
> 
> dp51 wrote:
>> My previous reply contains some errors.  It seems I forgot what my own
>> code
>> does :|
>>
>> csound~ ALWAYS adds latency = ksmps samples (regardless of Max's vector
>> size).
>> This applies to all versions up to and including v1.0.6.  You can verify
>> this by creating
>> a simple audio pass-thru orchestra and trying to achieve phase
>> cancellation
>> (using
>> inversion and sample accurate delay).
>>
>> I could make csound~ capable of zero-latency if vectorsize/ksmps = n and
>> n
>> is a
>> positive integer.  For example:
>>
>> Max vector size: 32
>> Possible ksmps values: 32, 16, 8, 4, 2, 1
>>
>> If the above holds, then every time Max gives us vectorsize frames, we
>> can
>> process
>> Csound n times and be guaranteed to have vectorsize output frames to
>> match
>> the
>> vectorsize input frames (zero-latency).
>>
>> DAvis
>>
>>
>>
>>   
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/csound%7E-question-tp25643571p25674574.html
Sent from the Csound - General mailing list archive at Nabble.com.

Thanks for the excellent explaination,
and looking forward to the zero latency csound~ too.

best
Oeyvind

2009/9/30 dp51 :
>
> Yes, that's correct.  It hasn't been implemented, but I am willing to try.
> I'll start messing with it next month.
>
> To be honest, I should have implemented something like this ages ago.
> It's just that I always use ksmps = some really small # and always in
> a live situation.  Sample accuracy was never a concern and nobody
> ever complained.  Oh well.  I guess we all have Oeyvind to thank for
> getting to me actually re-read my code with a magnifying glass.
>
> Davis
>
>
>
> Mike Moser-Booth wrote:
>>
>> Hey Davis,
>>
>> Just to clarify, you're saying that if n is a positive integer, zero
>> latency is possible, but this is not actually implemented in [csound~]?
>> Because it would be awesome for those situations where sample accuracy
>> is necessary.
>>
>> adsr,
>> .mmb
>>
>> dp51 wrote:
>>> My previous reply contains some errors.  It seems I forgot what my own
>>> code
>>> does :|
>>>
>>> csound~ ALWAYS adds latency = ksmps samples (regardless of Max's vector
>>> size).
>>> This applies to all versions up to and including v1.0.6.  You can verify
>>> this by creating
>>> a simple audio pass-thru orchestra and trying to achieve phase
>>> cancellation
>>> (using
>>> inversion and sample accurate delay).
>>>
>>> I could make csound~ capable of zero-latency if vectorsize/ksmps = n and
>>> n
>>> is a
>>> positive integer.  For example:
>>>
>>> Max vector size: 32
>>> Possible ksmps values: 32, 16, 8, 4, 2, 1
>>>
>>> If the above holds, then every time Max gives us vectorsize frames, we
>>> can
>>> process
>>> Csound n times and be guaranteed to have vectorsize output frames to
>>> match
>>> the
>>> vectorsize input frames (zero-latency).
>>>
>>> DAvis
>>>
>>>
>>>
>>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
> --
> View this message in context: http://www.nabble.com/csound%7E-question-tp25643571p25674574.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>