I finally discovered what was causing my sensekey "zipper" noise: bad buffer
size (-b).

Recently I've been working with -b128 and -B8192, since latency was no
issue, and I want to avoid underruns (breakup) at all cost.

It turns out that a low value for -b causes zipper noise with sensekey. The
attached file represents a simple test anyone can try. Real time, it
generates a sine wave, while sensekey sits there (always "on") just
"listening" and doing nothing. If you press a key with -b set too low,
there's the "zipper". With -b higher, no zipper.

For me (on WinME), it takes -b1024 to get absolutely no stutter. -b512 gets
an occasional glitch, -b256 is pretty bad, and -b128 is terrible. (Values
for -B seem not to matter here.)

It might well be worth an alert in the sensekey doc to the effect that
sensekey is especially sensitive to the value of -b. Setting -b higher can
avoid zipper noise.

As an aside, I was surprised at this; it seems counterintuitive to me. If
anyone has an explanation, I'd love to hear it.

This also reminds me that it would be very nice to have - in the
documentation - a *thorough presentation* (in terms the average person might
understand) of -b and -B - especially focussing on the various ill effects
(in real time) of setting them too high or low, or of an improper
relationship between the two values. Looking back over an extensive period
of work in real time Csound, I can't think of another issue that has caused
me equal frustration and grief. (Obviously it hasn't stopped yet.)

Art Hunkins

----- Original Message ----- 
From: "Andres Cabrera" 
To: "Art Hunkins" ; "Developer discussions"

Sent: Thursday, December 07, 2006 10:03 PM
Subject: Re: [Cs-dev] sensekey


Hi Art,
Can you try to use the keyboard with diffamator? Do you get stuttering?

What I think could be happening is that the operating system does
key-repeat, and you are generating many events on a single keypress...

Cheers,
Andrés

Art Hunkins wrote:
> I've been experimenting further with sensekey (in WinME) from the
> commandline. My goal is to trigger samples with keypresses.
>
> The basic mechanism is working fine and as I expect, except for one
> exasperating (and perhaps fatal) problem: any time I strike a key, even
for
> the shortest possible duration, any audio currently sounding stutters
> ("zipper noise") for a full second. (This includes the beginning of the
> just-triggered sample.)
>
> The stuttering occurs even with keypresses that don't trigger samples, and
> indeed when I truncate code to check for a single key as trigger (the
> stutter is of the same, one-second duration).
>
> The same .csd using midi input as trigger (midiin doing the input
> processing) works flawlessly.
>
> My tentative conclusion is that sensekey, as it responds to ASCII keyboard
> strokes, is doing a lot of processing - so much so that is causes audio to
> "zipper." The effect is the same as in Csound4 when using FLTK widgets;
the
> mouse moving across the screen caused "zipper noise" on my vintage PC.
> However, it's been a *long* time (I can't recall when) since I've
> encountered this phenomenon on my current-issue machines.
>
> Is there anything to be done? (I'd attach a .csd, but I'd have to send
along
> a substantial sample as well. I don't think the problem is code I've
> written, though perhaps it's code I *haven't* written - a lack of
awareness
> of some important factor.)
>
> Thanks for any insight. I'd *really* like to be able to ASCII-trigger
> samples with sensekey. As Victor says, "just a laptop and go."
>
> Art Hunkins
>
> ----- Original Message ----- 
> From: "Victor Lazzarini" 
> To: "Art Hunkins" ; "Developer discussions"
> 
> Sent: Friday, December 01, 2006 11:59 AM
> Subject: Re: [Cs-dev] sensekey
>
>
>
>> yesterday I played with some mappings and I thought it was quite
>> interesting. I did some button-accordion mappings that created
>> a computer squeeze-box.  This would in fact help the mobility
>> of works, just a laptop and go!
>>
>> Victor
>>
>> At 16:35 01/12/2006, you wrote:
>>
>>> FWIW:
>>>
>>> Neither Winsound, nor CsoundGUI, nor Lettuce allow sensekey to respond
to
>>> ASCII input.
>>>
>>> If Rory *did* opt to add that capability to Lettuce, it would be
>>>
> something
>
>>> these other frontends couldn't (currently) do.
>>>
>>> I wonder how many realtime users out there are interested in being able
>>>
> to
>
>>> use sensekey (i.e., ASCII keyboard input) in Windows, and without FLTK -
>>>
> but
>
>>> within a front end such as Lettuce? (Perhaps I'm the only one?)
>>>
>>> Art Hunkins
>>>
>>> ----- Original Message -----
>>> From: "Victor Lazzarini" 
>>> To: "Art Hunkins" ; "Developer discussions"
>>> 
>>> Sent: Friday, December 01, 2006 11:12 AM
>>> Subject: Re: [Cs-dev] sensekey
>>>
>>>
>>> No problem really. As for Lettuce, I reckon Rory will
>>> add that very soon.
>>>
>>> Victor
>>>
>>> At 16:09 01/12/2006, you wrote:
>>>
>>>> Thanks, Victor, for stating the matter succinctly.
>>>>
>>>> Actually, I *thought* that's what I had said. Apparently, long years in
>>>> academia and a low level of technical expertise have resulted in my
>>>>
>>> clouding
>>>
>>>> the issue one more time. Sorry about that.
>>>>
>>>> I appreciate you developers bearing with me.
>>>>
>>>> Art Hunkins
>>>>
>>>> ----- Original Message -----
>>>> From: "Victor Lazzarini" 
>>>> To: "Art Hunkins" ; "Developer discussions"
>>>> 
>>>> Sent: Friday, December 01, 2006 10:15 AM
>>>> Subject: Re: [Cs-dev] sensekey
>>>>
>>>>
>>>> But it does work on Windows, with/without FLTK. It doesn't work with
>>>> Lettuce, which
>>>> is a different thing.
>>>>
>>>> Victor
>>>>
>>> ------------------------------------------------------------------------
-
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to share
>>>
> your
>
>>> opinions on IT & business topics through brief surveys - and earn cash
>>>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>> Victor Lazzarini
>> Music Technology Laboratory
>> Music Department
>> National University of Ireland, Maynooth
>>
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share
>>
> your
>
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Hi Art,

First of all, I know what you mean regarding frustration with getting
the right numbers, but I think that I've figured it out. I know that
you have a lot more experience dealing with this than I do, the
following is intended as much as a thinking-out-loud draft for the
manual as an explanation, hence the "for beginners" tone. Perhaps
others could point out things that aren't clear or are incorrect, and
then I'd be happy to do a rewrite for the manual.

I've been finding lately that the simplest solution is to set
ksmps to a value that I'm happy with (tradeoff between quality and
performance), and then just set -b to a negative power of two, without
adjusting -B at all. This puts everything in sync, and to get the
optimal values just start with something you think is going to be too
low, ie -1, and then continue "upwards", -2, -4 and so on, until you
stop getting x-runs. The real value of -b will be the absolute value
of -b * ksmps.

Now you can start reducing the hardware buffer (-B). Just bring it down
from the default (16384 on windows), halving it each time, until you
start to get x-runs again. At which point of course go back. This is
assuming that you have a 16-bit soundcard. If you have a 24-bit
soundcard, then -B should be 3/2, or 3 times -b, rather than 2 or 4
times. I think that the main reason why this is tricky is that csound
works with floats, or doubles whereas most soundcards are 16 or
24-bit. -b is the internal buffer, so it's dealing with the 32 or
64-bit side of things, whereas -B is the hardware buffer, so it's
dealing with the 16 or 24-bit side. The csound default for floats is
-B = 4 * -b. This is a sane value for a 16 bit card. You can usually
get away with -B = 2 * -b, but this is the absolute minimum. For
example, if you set -b1024 -B2048, csound will tell you that:

"audio (is) buffered in 1024 sample-frame blocks" and that it is
"writing 4096-byte blocks to dac"

4096 bytes is 32768 bits. 32768/32 = 1024, our sample-frame size, 1024
* 32/16 = 2048, our buffer size. Were we to reduce the value of -B, we
would need to reduce the value of -b by a corresponding amount in
order to continue to write 16-bit integers to dac. The minimum size of
-b is (-B * bitrate)/32. That is to say that the minimum ratio of -b
to -B should be:

16-bit: 1:2
24-bit: 2:3
32-bit: 1:1

While there is no theoretical maximum ratio, it makes no sense to have
a very high ratio here, as the software buffer has to fill the
hardware buffer before returning, which if the ratio is high, will
take a long time, defeating the purpose of setting a small value for -b. 

Anyway, to sum up, the value of -b is something that will need to be
varied depending on the complexity of the instrument you're working
with, but because it's intimately related to the value of ksmps, it's
better to synchronise it with ksmps and go from there. One way to do
it is to decide how long the release on your envelopes might need to
be at maximum (for desired effect), set the release on all envelopes
to maximum, give yourself a generous value for -b,  and then play. If
it seizes up, double ksmps, repeat until smooth, then bring the value
of -b down as far as possible.

The value of -B is primarily determined by operating system and
soundcard. Figure out (using above method) how low you can go, and
just stick with that value (or one higher for "headroom"), then if you
have problems you'll know that it's probably because of an
inappropriate value for ksmps, too low a value for -b, or denormals,
which is really more than enough to have to sort through anyway.

Jonathan.

"Art Hunkins"  writes:

> I finally discovered what was causing my sensekey "zipper" noise: bad buffer
> size (-b).
>
> Recently I've been working with -b128 and -B8192, since latency was no
> issue, and I want to avoid underruns (breakup) at all cost.
>
> It turns out that a low value for -b causes zipper noise with sensekey. The
> attached file represents a simple test anyone can try. Real time, it
> generates a sine wave, while sensekey sits there (always "on") just
> "listening" and doing nothing. If you press a key with -b set too low,
> there's the "zipper". With -b higher, no zipper.
>
> For me (on WinME), it takes -b1024 to get absolutely no stutter. -b512 gets
> an occasional glitch, -b256 is pretty bad, and -b128 is terrible. (Values
> for -B seem not to matter here.)
>
> It might well be worth an alert in the sensekey doc to the effect that
> sensekey is especially sensitive to the value of -b. Setting -b higher can
> avoid zipper noise.
>
> As an aside, I was surprised at this; it seems counterintuitive to me. If
> anyone has an explanation, I'd love to hear it.
>
> This also reminds me that it would be very nice to have - in the
> documentation - a *thorough presentation* (in terms the average person might
> understand) of -b and -B - especially focussing on the various ill effects
> (in real time) of setting them too high or low, or of an improper
> relationship between the two values. Looking back over an extensive period
> of work in real time Csound, I can't think of another issue that has caused
> me equal frustration and grief. (Obviously it hasn't stopped yet.)
>
> Art Hunkins

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Art,

As always, thanks for you thorough and rigorous testing.

I agree that:

We absolutely could use a thorough explanation of -b and -B and also  
some tips on how to relate them to k-rate and calculate
the latency (a nice little formula or a table with some solutions)

Also....

when you type the csound command from the command line....
It would be great to list ALL the -+ and -- flags not just some of them.

I often use this technique as a reminder (when I have forgotten a  
commandline option) and
not ALL the flags show up in the list.

I would love Csound to display all the commandline options - or maybe  
like the -z flag, maybe there could be a flag that
would list all commandline options?

Dr. B.

On Dec 8, 2006, at 5:55 AM, Art Hunkins wrote:

> I finally discovered what was causing my sensekey "zipper" noise:  
> bad buffer
> size (-b).
>
> Recently I've been working with -b128 and -B8192, since latency was no
> issue, and I want to avoid underruns (breakup) at all cost.
>
> It turns out that a low value for -b causes zipper noise with  
> sensekey. The
> attached file represents a simple test anyone can try. Real time, it
> generates a sine wave, while sensekey sits there (always "on") just
> "listening" and doing nothing. If you press a key with -b set too low,
> there's the "zipper". With -b higher, no zipper.
>
> For me (on WinME), it takes -b1024 to get absolutely no stutter. - 
> b512 gets
> an occasional glitch, -b256 is pretty bad, and -b128 is terrible.  
> (Values
> for -B seem not to matter here.)
>
> It might well be worth an alert in the sensekey doc to the effect that
> sensekey is especially sensitive to the value of -b. Setting -b  
> higher can
> avoid zipper noise.
>
> As an aside, I was surprised at this; it seems counterintuitive to  
> me. If
> anyone has an explanation, I'd love to hear it.
>
> This also reminds me that it would be very nice to have - in the
> documentation - a *thorough presentation* (in terms the average  
> person might
> understand) of -b and -B - especially focussing on the various ill  
> effects
> (in real time) of setting them too high or low, or of an improper
> relationship between the two values. Looking back over an extensive  
> period
> of work in real time Csound, I can't think of another issue that  
> has caused
> me equal frustration and grief. (Obviously it hasn't stopped yet.)
>
> Art Hunkins
>
> ----- Original Message -----
> From: "Andres Cabrera" 
> To: "Art Hunkins" ; "Developer discussions"
> 
> Sent: Thursday, December 07, 2006 10:03 PM
> Subject: Re: [Cs-dev] sensekey
>
>
> Hi Art,
> Can you try to use the keyboard with diffamator? Do you get  
> stuttering?
>
> What I think could be happening is that the operating system does
> key-repeat, and you are generating many events on a single keypress...
>
> Cheers,
> Andrés
>
> Art Hunkins wrote:
>> I've been experimenting further with sensekey (in WinME) from the
>> commandline. My goal is to trigger samples with keypresses.
>>
>> The basic mechanism is working fine and as I expect, except for one
>> exasperating (and perhaps fatal) problem: any time I strike a key,  
>> even
> for
>> the shortest possible duration, any audio currently sounding stutters
>> ("zipper noise") for a full second. (This includes the beginning  
>> of the
>> just-triggered sample.)
>>
>> The stuttering occurs even with keypresses that don't trigger  
>> samples, and
>> indeed when I truncate code to check for a single key as trigger (the
>> stutter is of the same, one-second duration).
>>
>> The same .csd using midi input as trigger (midiin doing the input
>> processing) works flawlessly.
>>
>> My tentative conclusion is that sensekey, as it responds to ASCII  
>> keyboard
>> strokes, is doing a lot of processing - so much so that is causes  
>> audio to
>> "zipper." The effect is the same as in Csound4 when using FLTK  
>> widgets;
> the
>> mouse moving across the screen caused "zipper noise" on my vintage  
>> PC.
>> However, it's been a *long* time (I can't recall when) since I've
>> encountered this phenomenon on my current-issue machines.
>>
>> Is there anything to be done? (I'd attach a .csd, but I'd have to  
>> send
> along
>> a substantial sample as well. I don't think the problem is code I've
>> written, though perhaps it's code I *haven't* written - a lack of
> awareness
>> of some important factor.)
>>
>> Thanks for any insight. I'd *really* like to be able to ASCII-trigger
>> samples with sensekey. As Victor says, "just a laptop and go."
>>
>> Art Hunkins
>>
>> ----- Original Message -----
>> From: "Victor Lazzarini" 
>> To: "Art Hunkins" ; "Developer discussions"
>> 
>> Sent: Friday, December 01, 2006 11:59 AM
>> Subject: Re: [Cs-dev] sensekey
>>
>>
>>
>>> yesterday I played with some mappings and I thought it was quite
>>> interesting. I did some button-accordion mappings that created
>>> a computer squeeze-box.  This would in fact help the mobility
>>> of works, just a laptop and go!
>>>
>>> Victor
>>>
>>> At 16:35 01/12/2006, you wrote:
>>>
>>>> FWIW:
>>>>
>>>> Neither Winsound, nor CsoundGUI, nor Lettuce allow sensekey to  
>>>> respond
> to
>>>> ASCII input.
>>>>
>>>> If Rory *did* opt to add that capability to Lettuce, it would be
>>>>
>> something
>>
>>>> these other frontends couldn't (currently) do.
>>>>
>>>> I wonder how many realtime users out there are interested in  
>>>> being able
>>>>
>> to
>>
>>>> use sensekey (i.e., ASCII keyboard input) in Windows, and  
>>>> without FLTK -
>>>>
>> but
>>
>>>> within a front end such as Lettuce? (Perhaps I'm the only one?)
>>>>
>>>> Art Hunkins
>>>>
>>>> ----- Original Message -----
>>>> From: "Victor Lazzarini" 
>>>> To: "Art Hunkins" ; "Developer discussions"
>>>> 
>>>> Sent: Friday, December 01, 2006 11:12 AM
>>>> Subject: Re: [Cs-dev] sensekey
>>>>
>>>>
>>>> No problem really. As for Lettuce, I reckon Rory will
>>>> add that very soon.
>>>>
>>>> Victor
>>>>
>>>> At 16:09 01/12/2006, you wrote:
>>>>
>>>>> Thanks, Victor, for stating the matter succinctly.
>>>>>
>>>>> Actually, I *thought* that's what I had said. Apparently, long  
>>>>> years in
>>>>> academia and a low level of technical expertise have resulted  
>>>>> in my
>>>>>
>>>> clouding
>>>>
>>>>> the issue one more time. Sorry about that.
>>>>>
>>>>> I appreciate you developers bearing with me.
>>>>>
>>>>> Art Hunkins
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Victor Lazzarini" 
>>>>> To: "Art Hunkins" ; "Developer discussions"
>>>>> 
>>>>> Sent: Friday, December 01, 2006 10:15 AM
>>>>> Subject: Re: [Cs-dev] sensekey
>>>>>
>>>>>
>>>>> But it does work on Windows, with/without FLTK. It doesn't work  
>>>>> with
>>>>> Lettuce, which
>>>>> is a different thing.
>>>>>
>>>>> Victor
>>>>>
>>>> ------------------------------------------------------------------- 
>>>> -----
> -
>>>> Take Surveys. Earn Cash. Influence the Future of IT
>>>> Join SourceForge.net's Techsay panel and you'll get the chance  
>>>> to share
>>>>
>> your
>>
>>>> opinions on IT & business topics through brief surveys - and  
>>>> earn cash
>>>>
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>> Victor Lazzarini
>>> Music Technology Laboratory
>>> Music Department
>>> National University of Ireland, Maynooth
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -----
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>>> share
>>>
>> your
>>
>>> opinions on IT & business topics through brief surveys - and earn  
>>> cash
>>> http://www.techsay.com/default.php? 
>>> page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share
> your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV________________________________ 
> _______________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Jonathan,
Thanks very much for this information. I've prepared the following page
for inclusion in the manual.
Can you take a look and see if it's accurate and something's missing.
It looks to me like this method should work on all platforms, can other
people try it?

Cheers,
Andrés


Jonathan Murphy wrote:
> Hi Art,
>
> First of all, I know what you mean regarding frustration with getting
> the right numbers, but I think that I've figured it out. I know that
> you have a lot more experience dealing with this than I do, the
> following is intended as much as a thinking-out-loud draft for the
> manual as an explanation, hence the "for beginners" tone. Perhaps
> others could point out things that aren't clear or are incorrect, and
> then I'd be happy to do a rewrite for the manual.
>
> I've been finding lately that the simplest solution is to set
> ksmps to a value that I'm happy with (tradeoff between quality and
> performance), and then just set -b to a negative power of two, without
> adjusting -B at all. This puts everything in sync, and to get the
> optimal values just start with something you think is going to be too
> low, ie -1, and then continue "upwards", -2, -4 and so on, until you
> stop getting x-runs. The real value of -b will be the absolute value
> of -b * ksmps.
>
> Now you can start reducing the hardware buffer (-B). Just bring it down
> from the default (16384 on windows), halving it each time, until you
> start to get x-runs again. At which point of course go back. This is
> assuming that you have a 16-bit soundcard. If you have a 24-bit
> soundcard, then -B should be 3/2, or 3 times -b, rather than 2 or 4
> times. I think that the main reason why this is tricky is that csound
> works with floats, or doubles whereas most soundcards are 16 or
> 24-bit. -b is the internal buffer, so it's dealing with the 32 or
> 64-bit side of things, whereas -B is the hardware buffer, so it's
> dealing with the 16 or 24-bit side. The csound default for floats is
> -B = 4 * -b. This is a sane value for a 16 bit card. You can usually
> get away with -B = 2 * -b, but this is the absolute minimum. For
> example, if you set -b1024 -B2048, csound will tell you that:
>
> "audio (is) buffered in 1024 sample-frame blocks" and that it is
> "writing 4096-byte blocks to dac"
>
> 4096 bytes is 32768 bits. 32768/32 = 1024, our sample-frame size, 1024
> * 32/16 = 2048, our buffer size. Were we to reduce the value of -B, we
> would need to reduce the value of -b by a corresponding amount in
> order to continue to write 16-bit integers to dac. The minimum size of
> -b is (-B * bitrate)/32. That is to say that the minimum ratio of -b
> to -B should be:
>
> 16-bit: 1:2
> 24-bit: 2:3
> 32-bit: 1:1
>
> While there is no theoretical maximum ratio, it makes no sense to have
> a very high ratio here, as the software buffer has to fill the
> hardware buffer before returning, which if the ratio is high, will
> take a long time, defeating the purpose of setting a small value for -b. 
>
> Anyway, to sum up, the value of -b is something that will need to be
> varied depending on the complexity of the instrument you're working
> with, but because it's intimately related to the value of ksmps, it's
> better to synchronise it with ksmps and go from there. One way to do
> it is to decide how long the release on your envelopes might need to
> be at maximum (for desired effect), set the release on all envelopes
> to maximum, give yourself a generous value for -b,  and then play. If
> it seizes up, double ksmps, repeat until smooth, then bring the value
> of -b down as far as possible.
>
> The value of -B is primarily determined by operating system and
> soundcard. Figure out (using above method) how low you can go, and
> just stick with that value (or one higher for "headroom"), then if you
> have problems you'll know that it's probably because of an
> inappropriate value for ksmps, too low a value for -b, or denormals,
> which is really more than enough to have to sort through anyway.
>
> Jonathan.
>
> "Art Hunkins"  writes:
>
>   
>> I finally discovered what was causing my sensekey "zipper" noise: bad buffer
>> size (-b).
>>
>> Recently I've been working with -b128 and -B8192, since latency was no
>> issue, and I want to avoid underruns (breakup) at all cost.
>>
>> It turns out that a low value for -b causes zipper noise with sensekey. The
>> attached file represents a simple test anyone can try. Real time, it
>> generates a sine wave, while sensekey sits there (always "on") just
>> "listening" and doing nothing. If you press a key with -b set too low,
>> there's the "zipper". With -b higher, no zipper.
>>
>> For me (on WinME), it takes -b1024 to get absolutely no stutter. -b512 gets
>> an occasional glitch, -b256 is pretty bad, and -b128 is terrible. (Values
>> for -B seem not to matter here.)
>>
>> It might well be worth an alert in the sensekey doc to the effect that
>> sensekey is especially sensitive to the value of -b. Setting -b higher can
>> avoid zipper noise.
>>
>> As an aside, I was surprised at this; it seems counterintuitive to me. If
>> anyone has an explanation, I'd love to hear it.
>>
>> This also reminds me that it would be very nice to have - in the
>> documentation - a *thorough presentation* (in terms the average person might
>> understand) of -b and -B - especially focussing on the various ill effects
>> (in real time) of setting them too high or low, or of an improper
>> relationship between the two values. Looking back over an extensive period
>> of work in real time Csound, I can't think of another issue that has caused
>> me equal frustration and grief. (Obviously it hasn't stopped yet.)
>>
>> Art Hunkins
>>     
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>   

Hi Andres,

As far as I know it's accurate, and the fact that you think that it's
a viable method gives me more faith in my reasoning. If yourself and
the other developers agree that the information is accurate, and Art
and dr B feel that the explanation makes things clearer, then I'm
happy. Thanks for putting the man page together so quickly. There's
just one small mistake which is that the second sentence in the last
paragraph should read "and stick with that value".

I've been thinking that it might be a good idea to put together a
simple example .csd, something like a midi-controlled oscil which is
modulated by an audio (mic) input. If we were to put together a chart
to accompany it, with different values for the various flags and
settings and explanations of the effect that the different values
would have (things like latency time, polyphony, audio quality), it
might make things clearer, particularly for newcomers who are going to
be wondering what an appropriate value for ksmps might be.

Also I've been trying over the last few weeks to improve the
UsingRealTime section. I understand some things a little better now
than when I put together the information that you used there, and in
hindsight there are some mistakes that should be corrected. It would
be easy for me to just edit my local copy of
/manual/overview/realtimelinux.xml and send it to you, if that's convenient.

Regards,
Jonathan.

Andres Cabrera  writes:

> Hi Jonathan,
> Thanks very much for this information. I've prepared the following page
> for inclusion in the manual.
> Can you take a look and see if it's accurate and something's missing.
> It looks to me like this method should work on all platforms, can other
> people try it?
>
> Cheers,
> Andrés
>
>
> Jonathan Murphy wrote:
>> Hi Art,
>>
>> First of all, I know what you mean regarding frustration with getting
>> the right numbers, but I think that I've figured it out. I know that
>> you have a lot more experience dealing with this than I do, the
>> following is intended as much as a thinking-out-loud draft for the
>> manual as an explanation, hence the "for beginners" tone. Perhaps
>> others could point out things that aren't clear or are incorrect, and
>> then I'd be happy to do a rewrite for the manual.
>>
>> I've been finding lately that the simplest solution is to set
>> ksmps to a value that I'm happy with (tradeoff between quality and
>> performance), and then just set -b to a negative power of two, without
>> adjusting -B at all. This puts everything in sync, and to get the
>> optimal values just start with something you think is going to be too
>> low, ie -1, and then continue "upwards", -2, -4 and so on, until you
>> stop getting x-runs. The real value of -b will be the absolute value
>> of -b * ksmps.
>>
>> Now you can start reducing the hardware buffer (-B). Just bring it down
>> from the default (16384 on windows), halving it each time, until you
>> start to get x-runs again. At which point of course go back. This is
>> assuming that you have a 16-bit soundcard. If you have a 24-bit
>> soundcard, then -B should be 3/2, or 3 times -b, rather than 2 or 4
>> times. I think that the main reason why this is tricky is that csound
>> works with floats, or doubles whereas most soundcards are 16 or
>> 24-bit. -b is the internal buffer, so it's dealing with the 32 or
>> 64-bit side of things, whereas -B is the hardware buffer, so it's
>> dealing with the 16 or 24-bit side. The csound default for floats is
>> -B = 4 * -b. This is a sane value for a 16 bit card. You can usually
>> get away with -B = 2 * -b, but this is the absolute minimum. For
>> example, if you set -b1024 -B2048, csound will tell you that:
>>
>> "audio (is) buffered in 1024 sample-frame blocks" and that it is
>> "writing 4096-byte blocks to dac"
>>
>> 4096 bytes is 32768 bits. 32768/32 = 1024, our sample-frame size, 1024
>> * 32/16 = 2048, our buffer size. Were we to reduce the value of -B, we
>> would need to reduce the value of -b by a corresponding amount in
>> order to continue to write 16-bit integers to dac. The minimum size of
>> -b is (-B * bitrate)/32. That is to say that the minimum ratio of -b
>> to -B should be:
>>
>> 16-bit: 1:2
>> 24-bit: 2:3
>> 32-bit: 1:1
>>
>> While there is no theoretical maximum ratio, it makes no sense to have
>> a very high ratio here, as the software buffer has to fill the
>> hardware buffer before returning, which if the ratio is high, will
>> take a long time, defeating the purpose of setting a small value for -b. 
>>
>> Anyway, to sum up, the value of -b is something that will need to be
>> varied depending on the complexity of the instrument you're working
>> with, but because it's intimately related to the value of ksmps, it's
>> better to synchronise it with ksmps and go from there. One way to do
>> it is to decide how long the release on your envelopes might need to
>> be at maximum (for desired effect), set the release on all envelopes
>> to maximum, give yourself a generous value for -b,  and then play. If
>> it seizes up, double ksmps, repeat until smooth, then bring the value
>> of -b down as far as possible.
>>
>> The value of -B is primarily determined by operating system and
>> soundcard. Figure out (using above method) how low you can go, and
>> just stick with that value (or one higher for "headroom"), then if you
>> have problems you'll know that it's probably because of an
>> inappropriate value for ksmps, too low a value for -b, or denormals,
>> which is really more than enough to have to sort through anyway.
>>
>> Jonathan.
>>
>> "Art Hunkins"  writes:
>>
>>   
>>> I finally discovered what was causing my sensekey "zipper" noise: bad buffer
>>> size (-b).
>>>
>>> Recently I've been working with -b128 and -B8192, since latency was no
>>> issue, and I want to avoid underruns (breakup) at all cost.
>>>
>>> It turns out that a low value for -b causes zipper noise with sensekey. The
>>> attached file represents a simple test anyone can try. Real time, it
>>> generates a sine wave, while sensekey sits there (always "on") just
>>> "listening" and doing nothing. If you press a key with -b set too low,
>>> there's the "zipper". With -b higher, no zipper.
>>>
>>> For me (on WinME), it takes -b1024 to get absolutely no stutter. -b512 gets
>>> an occasional glitch, -b256 is pretty bad, and -b128 is terrible. (Values
>>> for -B seem not to matter here.)
>>>
>>> It might well be worth an alert in the sensekey doc to the effect that
>>> sensekey is especially sensitive to the value of -b. Setting -b higher can
>>> avoid zipper noise.
>>>
>>> As an aside, I was surprised at this; it seems counterintuitive to me. If
>>> anyone has an explanation, I'd love to hear it.
>>>
>>> This also reminds me that it would be very nice to have - in the
>>> documentation - a *thorough presentation* (in terms the average person might
>>> understand) of -b and -B - especially focussing on the various ill effects
>>> (in real time) of setting them too high or low, or of an improper
>>> relationship between the two values. Looking back over an extensive period
>>> of work in real time Csound, I can't think of another issue that has caused
>>> me equal frustration and grief. (Obviously it hasn't stopped yet.)
>>>
>>> Art Hunkins
>>>     
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>   
>
>                                           Optimizing Audio I/O Latency                                          
> Prev                                              Using Csound                                              Next
>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> Optimizing Audio I/O Latency
>
> To achieve the lowest latency possible without audio break ups, a combination of variables needs to be tweaked.
> The final values will be platform and system dependent, and will also depend on the complexity of the audio
> calculations performed. You need to adjust ksmps in the orchestra, as well as the software (-b) and harware
> buffer (-B) sizes.
>
> Usually the simplest solution is the following:
>
>  1. Set ksmps to a value with a good tradeoff between quality and performance, without adjusting -B at all.
>    
>  2. Set -b to a negative power of two of this value.
>    
>     To get the optimal values, start with something you think is going to be too low, ie -1, and then continue
>     "upwards", -2, -4 and so on, until you stop getting x-runs (glitches). The real value of -b will be the
>     absolute value of -b * ksmps.
>    
>  3. Reduce the hardware buffer (-B). Bring it down from the default (1024 on Linux, 4096 on Mac OS X, 16384 on
>     Windows), halving it each time, until you start to get x-runs (glitches) again. Then take it back up again
>     until performance is continuous.
>    
> This process assumes you have a 16-bit soundcard. If you have a 24-bit soundcard, then -B should be 3/2, or 3
> times -b, rather than 2 or 4 times. Csound works with 32-bit floats, or 64-bit doubles whereas most soundcards
> are 16 or 24-bit integer. -b is the internal buffer, so it's dealing with the 32 or 64-bit side of things,
> whereas -B is the hardware buffer, so it's dealing with the 16 or 24-bit side. The csound default for floats is 
> -B = 4 * -b. This is a sane value for a 16 bit card. You can usually get away with -B = 2 * -b, but this is the
> absolute minimum. For example, if you set -b1024 -B2048, csound will tell you that:
>
> audio (is) buffered in 1024 sample-frame blocks
> writing 4096-byte blocks to dac
>
> 4096 bytes is 32768 bits. 32768/32 = 1024, our sample-frame size, 1024 * 32/16 = 2048, our buffer size. Were we
> to reduce the value of -B, we would need to reduce the value of -b by a corresponding amount in order to
> continue to write 16-bit integers to dac. The minimum size of -b is (-B * bitrate)/32. That is to say that the
> minimum ratio of -b to -B should be:
>
>   ● 16-bit: 1:2
>   ● 24-bit: 2:3
>   ● 32-bit: 1:1
>
> While there is no theoretical maximum ratio, it makes no sense to have a very high ratio here, as the software
> buffer has to fill the hardware buffer before returning. If the ratio is high, it will take a long time,
> defeating the purpose of setting a small value for -b.
>
> The value of -b is something that will need to be varied depending on the complexity of the instrument you're
> working with, but because it's intimately related to the value of ksmps, it's better to synchronise it with 
> ksmps and go from there. One way to do it is to decide how long the release on your envelopes might need to be
> at maximum (for desired effect), set the release on all envelopes to maximum, give yourself a generous value for
> -b, and then play. If it breaks up, double ksmps, repeat until smooth, then bring the value of -b down as far as
> possible.
>
> The value of -B is primarily determined by operating system and soundcard. Figure out (using above method) how
> low you can go, and with that value (or one higher for safety). If you have problems you'll know that it's
> probably because of an inappropriate value for ksmps, too low a value for -b, or denormals (see denorm.
>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> Prev                                                   Up                                                   Next
> Using Csound                                          Home                                           Configuring
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists

an example for testing would be great.  a midi in example and a mic  
in example both.  and....
maybe an fltk example with sliders and buttons too.... and a table of  
different recommendations
to try.

-dB
On Dec 9, 2006, at 11:50 PM, Jonathan Murphy wrote:

>
> Hi Andres,
>
> As far as I know it's accurate, and the fact that you think that it's
> a viable method gives me more faith in my reasoning. If yourself and
> the other developers agree that the information is accurate, and Art
> and dr B feel that the explanation makes things clearer, then I'm
> happy. Thanks for putting the man page together so quickly. There's
> just one small mistake which is that the second sentence in the last
> paragraph should read "and stick with that value".
>
> I've been thinking that it might be a good idea to put together a
> simple example .csd, something like a midi-controlled oscil which is
> modulated by an audio (mic) input. If we were to put together a chart
> to accompany it, with different values for the various flags and
> settings and explanations of the effect that the different values
> would have (things like latency time, polyphony, audio quality), it
> might make things clearer, particularly for newcomers who are going to
> be wondering what an appropriate value for ksmps might be.
>
> Also I've been trying over the last few weeks to improve the
> UsingRealTime section. I understand some things a little better now
> than when I put together the information that you used there, and in
> hindsight there are some mistakes that should be corrected. It would
> be easy for me to just edit my local copy of
> /manual/overview/realtimelinux.xml and send it to you, if that's  
> convenient.
>
> Regards,
> Jonathan.
>
> Andres Cabrera  writes:
>
>> Hi Jonathan,
>> Thanks very much for this information. I've prepared the following  
>> page
>> for inclusion in the manual.
>> Can you take a look and see if it's accurate and something's missing.
>> It looks to me like this method should work on all platforms, can  
>> other
>> people try it?
>>
>> Cheers,
>> Andrés
>>
>>
>> Jonathan Murphy wrote:
>>> Hi Art,
>>>
>>> First of all, I know what you mean regarding frustration with  
>>> getting
>>> the right numbers, but I think that I've figured it out. I know that
>>> you have a lot more experience dealing with this than I do, the
>>> following is intended as much as a thinking-out-loud draft for the
>>> manual as an explanation, hence the "for beginners" tone. Perhaps
>>> others could point out things that aren't clear or are incorrect,  
>>> and
>>> then I'd be happy to do a rewrite for the manual.
>>>
>>> I've been finding lately that the simplest solution is to set
>>> ksmps to a value that I'm happy with (tradeoff between quality and
>>> performance), and then just set -b to a negative power of two,  
>>> without
>>> adjusting -B at all. This puts everything in sync, and to get the
>>> optimal values just start with something you think is going to be  
>>> too
>>> low, ie -1, and then continue "upwards", -2, -4 and so on, until you
>>> stop getting x-runs. The real value of -b will be the absolute value
>>> of -b * ksmps.
>>>
>>> Now you can start reducing the hardware buffer (-B). Just bring  
>>> it down
>>> from the default (16384 on windows), halving it each time, until you
>>> start to get x-runs again. At which point of course go back. This is
>>> assuming that you have a 16-bit soundcard. If you have a 24-bit
>>> soundcard, then -B should be 3/2, or 3 times -b, rather than 2 or 4
>>> times. I think that the main reason why this is tricky is that  
>>> csound
>>> works with floats, or doubles whereas most soundcards are 16 or
>>> 24-bit. -b is the internal buffer, so it's dealing with the 32 or
>>> 64-bit side of things, whereas -B is the hardware buffer, so it's
>>> dealing with the 16 or 24-bit side. The csound default for floats is
>>> -B = 4 * -b. This is a sane value for a 16 bit card. You can usually
>>> get away with -B = 2 * -b, but this is the absolute minimum. For
>>> example, if you set -b1024 -B2048, csound will tell you that:
>>>
>>> "audio (is) buffered in 1024 sample-frame blocks" and that it is
>>> "writing 4096-byte blocks to dac"
>>>
>>> 4096 bytes is 32768 bits. 32768/32 = 1024, our sample-frame size,  
>>> 1024
>>> * 32/16 = 2048, our buffer size. Were we to reduce the value of - 
>>> B, we
>>> would need to reduce the value of -b by a corresponding amount in
>>> order to continue to write 16-bit integers to dac. The minimum  
>>> size of
>>> -b is (-B * bitrate)/32. That is to say that the minimum ratio of -b
>>> to -B should be:
>>>
>>> 16-bit: 1:2
>>> 24-bit: 2:3
>>> 32-bit: 1:1
>>>
>>> While there is no theoretical maximum ratio, it makes no sense to  
>>> have
>>> a very high ratio here, as the software buffer has to fill the
>>> hardware buffer before returning, which if the ratio is high, will
>>> take a long time, defeating the purpose of setting a small value  
>>> for -b.
>>>
>>> Anyway, to sum up, the value of -b is something that will need to be
>>> varied depending on the complexity of the instrument you're working
>>> with, but because it's intimately related to the value of ksmps,  
>>> it's
>>> better to synchronise it with ksmps and go from there. One way to do
>>> it is to decide how long the release on your envelopes might need to
>>> be at maximum (for desired effect), set the release on all envelopes
>>> to maximum, give yourself a generous value for -b,  and then  
>>> play. If
>>> it seizes up, double ksmps, repeat until smooth, then bring the  
>>> value
>>> of -b down as far as possible.
>>>
>>> The value of -B is primarily determined by operating system and
>>> soundcard. Figure out (using above method) how low you can go, and
>>> just stick with that value (or one higher for "headroom"), then  
>>> if you
>>> have problems you'll know that it's probably because of an
>>> inappropriate value for ksmps, too low a value for -b, or denormals,
>>> which is really more than enough to have to sort through anyway.
>>>
>>> Jonathan.
>>>
>>> "Art Hunkins"  writes:
>>>
>>>
>>>> I finally discovered what was causing my sensekey "zipper"  
>>>> noise: bad buffer
>>>> size (-b).
>>>>
>>>> Recently I've been working with -b128 and -B8192, since latency  
>>>> was no
>>>> issue, and I want to avoid underruns (breakup) at all cost.
>>>>
>>>> It turns out that a low value for -b causes zipper noise with  
>>>> sensekey. The
>>>> attached file represents a simple test anyone can try. Real  
>>>> time, it
>>>> generates a sine wave, while sensekey sits there (always "on") just
>>>> "listening" and doing nothing. If you press a key with -b set  
>>>> too low,
>>>> there's the "zipper". With -b higher, no zipper.
>>>>
>>>> For me (on WinME), it takes -b1024 to get absolutely no stutter.  
>>>> -b512 gets
>>>> an occasional glitch, -b256 is pretty bad, and -b128 is  
>>>> terrible. (Values
>>>> for -B seem not to matter here.)
>>>>
>>>> It might well be worth an alert in the sensekey doc to the  
>>>> effect that
>>>> sensekey is especially sensitive to the value of -b. Setting -b  
>>>> higher can
>>>> avoid zipper noise.
>>>>
>>>> As an aside, I was surprised at this; it seems counterintuitive  
>>>> to me. If
>>>> anyone has an explanation, I'd love to hear it.
>>>>
>>>> This also reminds me that it would be very nice to have - in the
>>>> documentation - a *thorough presentation* (in terms the average  
>>>> person might
>>>> understand) of -b and -B - especially focussing on the various  
>>>> ill effects
>>>> (in real time) of setting them too high or low, or of an improper
>>>> relationship between the two values. Looking back over an  
>>>> extensive period
>>>> of work in real time Csound, I can't think of another issue that  
>>>> has caused
>>>> me equal frustration and grief. (Obviously it hasn't stopped yet.)
>>>>
>>>> Art Hunkins
>>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -----
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>>> share your
>>> opinions on IT & business topics through brief surveys - and earn  
>>> cash
>>> http://www.techsay.com/default.php? 
>>> page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>
>>                                           Optimizing Audio I/O  
>> Latency
>> Prev                                              Using  
>> Csound                                              Next
>>
>> ━━━━━━━━━━━━━━━━━━━━━━━ 
>> ━━━━━━━━━━━━━━━━━━━━━━━ 
>> ━━━━━━━━━━━━━━━━━━━━━━━ 
>> ━━━━━━━━━━━━━━━━━━━━━━━ 
>> ━━━━━━━━━━━━━━━━━━━━
>>
>> Optimizing Audio I/O Latency
>>
>> To achieve the lowest latency possible without audio break ups, a  
>> combination of variables needs to be tweaked.
>> The final values will be platform and system dependent, and will  
>> also depend on the complexity of the audio
>> calculations performed. You need to adjust ksmps in the orchestra,  
>> as well as the software (-b) and harware
>> buffer (-B) sizes.
>>
>> Usually the simplest solution is the following:
>>
>>  1. Set ksmps to a value with a good tradeoff between quality and  
>> performance, without adjusting -B at all.
>>
>>  2. Set -b to a negative power of two of this value.
>>
>>     To get the optimal values, start with something you think is  
>> going to be too low, ie -1, and then continue
>>     "upwards", -2, -4 and so on, until you stop getting x-runs  
>> (glitches). The real value of -b will be the
>>     absolute value of -b * ksmps.
>>
>>  3. Reduce the hardware buffer (-B). Bring it down from the  
>> default (1024 on Linux, 4096 on Mac OS X, 16384 on
>>     Windows), halving it each time, until you start to get x-runs  
>> (glitches) again. Then take it back up again
>>     until performance is continuous.
>>
>> This process assumes you have a 16-bit soundcard. If you have a 24- 
>> bit soundcard, then -B should be 3/2, or 3
>> times -b, rather than 2 or 4 times. Csound works with 32-bit  
>> floats, or 64-bit doubles whereas most soundcards
>> are 16 or 24-bit integer. -b is the internal buffer, so it's  
>> dealing with the 32 or 64-bit side of things,
>> whereas -B is the hardware buffer, so it's dealing with the 16 or  
>> 24-bit side. The csound default for floats is
>> -B = 4 * -b. This is a sane value for a 16 bit card. You can  
>> usually get away with -B = 2 * -b, but this is the
>> absolute minimum. For example, if you set -b1024 -B2048, csound  
>> will tell you that:
>>
>> audio (is) buffered in 1024 sample-frame blocks
>> writing 4096-byte blocks to dac
>>
>> 4096 bytes is 32768 bits. 32768/32 = 1024, our sample-frame size,  
>> 1024 * 32/16 = 2048, our buffer size. Were we
>> to reduce the value of -B, we would need to reduce the value of -b  
>> by a corresponding amount in order to
>> continue to write 16-bit integers to dac. The minimum size of -b  
>> is (-B * bitrate)/32. That is to say that the
>> minimum ratio of -b to -B should be:
>>
>>   ● 16-bit: 1:2
>>   ● 24-bit: 2:3
>>   ● 32-bit: 1:1
>>
>> While there is no theoretical maximum ratio, it makes no sense to  
>> have a very high ratio here, as the software
>> buffer has to fill the hardware buffer before returning. If the  
>> ratio is high, it will take a long time,
>> defeating the purpose of setting a small value for -b.
>>
>> The value of -b is something that will need to be varied depending  
>> on the complexity of the instrument you're
>> working with, but because it's intimately related to the value of  
>> ksmps, it's better to synchronise it with
>> ksmps and go from there. One way to do it is to decide how long  
>> the release on your envelopes might need to be
>> at maximum (for desired effect), set the release on all envelopes  
>> to maximum, give yourself a generous value for
>> -b, and then play. If it breaks up, double ksmps, repeat until  
>> smooth, then bring the value of -b down as far as
>> possible.
>>
>> The value of -B is primarily determined by operating system and  
>> soundcard. Figure out (using above method) how
>> low you can go, and with that value (or one higher for safety). If  
>> you have problems you'll know that it's
>> probably because of an inappropriate value for ksmps, too low a  
>> value for -b, or denormals (see denorm.
>>
>> ━━━━━━━━━━━━━━━━━━━━━━━ 
>> ━━━━━━━━━━━━━━━━━━━━━━━ 
>> ━━━━━━━━━━━━━━━━━━━━━━━ 
>> ━━━━━━━━━━━━━━━━━━━━━━━ 
>> ━━━━━━━━━━━━━━━━━━━━
>>
>> Prev                                                    
>> Up                                                   Next
>> Using Csound                                           
>> Home                                           Configuring
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV_______________________________ 
>> ________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Hi Jonathan,
I've been working to make the manual easier for beginners, and I think
things like this are very important.

Jonathan Murphy wrote:
> I've been thinking that it might be a good idea to put together a
> simple example .csd, something like a midi-controlled oscil which is
> modulated by an audio (mic) input. If we were to put together a chart
> to accompany it, with different values for the various flags and
> settings and explanations of the effect that the different values
> would have (things like latency time, polyphony, audio quality), it
> might make things clearer, particularly for newcomers who are going to
> be wondering what an appropriate value for ksmps might be.
>   
If you can do that, it would be great to include it in the manual.
> Also I've been trying over the last few weeks to improve the
> UsingRealTime section. I understand some things a little better now
> than when I put together the information that you used there, and in
> hindsight there are some mistakes that should be corrected. It would
> be easy for me to just edit my local copy of
> /manual/overview/realtimelinux.xml and send it to you, if that's convenient.
>
>   
Yes, It's great if you can do that. Remember to keep tags intact.

Cheers,
Andrés


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csoun

> Hi Jonathan,
> I've been working to make the manual easier for beginners, and I think
> things like this are very important.

And doing a great job! I'll get to work on those couple of tasks
tomorrow and get back to you soon.

Jonathan.

>
> Jonathan Murphy wrote:
>> I've been thinking that it might be a good idea to put together a
>> simple example .csd, something like a midi-controlled oscil which is
>> modulated by an audio (mic) input. If we were to put together a chart
>> to accompany it, with different values for the various flags and
>> settings and explanations of the effect that the different values
>> would have (things like latency time, polyphony, audio quality), it
>> might make things clearer, particularly for newcomers who are going to
>> be wondering what an appropriate value for ksmps might be.
>>   
> If you can do that, it would be great to include it in the manual.
>> Also I've been trying over the last few weeks to improve the
>> UsingRealTime section. I understand some things a little better now
>> than when I put together the information that you used there, and in
>> hindsight there are some mistakes that should be corrected. It would
>> be easy for me to just edit my local copy of
>> /manual/overview/realtimelinux.xml and send it to you, if that's convenient.
>>
>>   
> Yes, It's great if you can do that. Remember to keep tags intact.
>
> Cheers,
> Andrés
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net