That's perfect. The funny feeling I have is that I had
already realised that in the past, but forgot all about it,
as this issue did not arise on OSX (and Linux), which I
had been using more often in the past few months.

It might be worth mentioning it in the manual somewhere,
as a tip.

Victor

>
> On Friday 10 February 2006 19:07, Victor Lazzarini wrote:
>
> > Not having tested realtime IO on Windows for a while, I
> > was shocked to confirm that there is indeed some issue
> > with input audio. I was getting a train of clicks  when
> > running Csound5 with ASIO.
> >
> > But hey, I found out why!
> >
> > It just happens that -b has to be a multiple of ksmps. I
> > have not checked the code, but it's simple. With -b512
> > and ksmps=100, clicks are there, but with -b100 (or
> -b200), the sound is perfect.
>
> It is not unlikely that having an integer ratio of -b and
> ksmps improves real time audio, especially with double
> buffering, simply because of having the calls to the
> rtrecord and rtplay callbacks more evenly distributed. For
> example, with your example, using -b512 would mean there
> is an rtrecord call in the first control period, and then
> another rtrecord call followed by an rtplay call in the
> sixth control period. With -b500, however, the rtplay
> would be called in the fifth control period, avoiding the
> double calls to rtrecord at the beginning of performance.
> --
> Send bugs reports to this list.
> To unsubscribe, send email to
> csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini wrote:

>That's perfect. The funny feeling I have is that I had
>already realised that in the past, but forgot all about it,
>as this issue did not arise on OSX (and Linux), which I
>had been using more often in the past few months.
>
>It might be worth mentioning it in the manual somewhere,
>as a tip.
>
>Victor
>
>  
>


 From the latest windows .chm manual:

-b NUM, --iobufsamps=NUM

    Number of audio sample-frames per sound i/o /software/ buffer. Large
    is efficient, but small will reduce audio I/O delay. The default is
    1024. In real-time performance, Csound waits on audio I/O on /NUM/
    boundaries. It also processes audio (and polls for other input like
    MIDI) on orchestra /ksmps/ boundaries. The two can be made
    synchronous. For convenience, if NUM = -NUM (is negative) the
    effective value is /ksmps * NUM/ (audio synchronous with k-period
    boundaries). With NUM small (e.g. 1) polling is then frequent and
    also locked to fixed DAC sample boundaries.


Is what the manual is describing essentially what you guys have arrived 
at? Is -b -1 possible, as described above?

Also, -b does not then need to be a power of 2?

If this all gets me smooth audio in I'm going to kiss someone.

-Bill B


>>On Friday 10 February 2006 19:07, Victor Lazzarini wrote:
>>
>>    
>>
>>>Not having tested realtime IO on Windows for a while, I
>>>was shocked to confirm that there is indeed some issue
>>>with input audio. I was getting a train of clicks  when
>>>running Csound5 with ASIO.
>>>
>>>But hey, I found out why!
>>>
>>>It just happens that -b has to be a multiple of ksmps. I
>>>have not checked the code, but it's simple. With -b512
>>>and ksmps=100, clicks are there, but with -b100 (or
>>>      
>>>
>>-b200), the sound is perfect.
>>
>>It is not unlikely that having an integer ratio of -b and
>>ksmps improves real time audio, especially with double
>>buffering, simply because of having the calls to the
>>rtrecord and rtplay callbacks more evenly distributed. For
>>example, with your example, using -b512 would mean there
>>is an rtrecord call in the first control period, and then
>>another rtrecord call followed by an rtplay call in the
>>sixth control period. With -b500, however, the rtplay
>>would be called in the fifth control period, avoiding the
>>double calls to rtrecord at the beginning of performance.
>>--
>>Send bugs reports to this list.
>>To unsubscribe, send email to
>>csound-unsubscribe@lists.bath.ac.uk
>>    
>>

Actually it's funny you mention this because I only started using -b/-B 
as integer multiples of ksmps because of the JACK plugin on OS X and 
Linux. Csound would actually terminate if buffer-size is not an integer 
multiple of ksmps, so after getting used to that, there was no problem 
using realtime input on Windows.


-David

On Feb 10, 2006, at 3:39 PM, Victor Lazzarini wrote:

> That's perfect. The funny feeling I have is that I had
> already realised that in the past, but forgot all about it,
> as this issue did not arise on OSX (and Linux), which I
> had been using more often in the past few months.
>
> It might be worth mentioning it in the manual somewhere,
> as a tip.
>
> Victor
>
>>
>> On Friday 10 February 2006 19:07, Victor Lazzarini wrote:
>>
>>> Not having tested realtime IO on Windows for a while, I
>>> was shocked to confirm that there is indeed some issue
>>> with input audio. I was getting a train of clicks  when
>>> running Csound5 with ASIO.
>>>
>>> But hey, I found out why!
>>>
>>> It just happens that -b has to be a multiple of ksmps. I
>>> have not checked the code, but it's simple. With -b512
>>> and ksmps=100, clicks are there, but with -b100 (or
>> -b200), the sound is perfect.
>>
>> It is not unlikely that having an integer ratio of -b and
>> ksmps improves real time audio, especially with double
>> buffering, simply because of having the calls to the
>> rtrecord and rtplay callbacks more evenly distributed. For
>> example, with your example, using -b512 would mean there
>> is an rtrecord call in the first control period, and then
>> another rtrecord call followed by an rtplay call in the
>> sixth control period. With -b500, however, the rtplay
>> would be called in the fifth control period, avoiding the
>> double calls to rtrecord at the beginning of performance.