check level of transparency on Period & Buffer Sizes

[tjingboem]

a few remarks concerning the -b and -B settings in Period & Buffer Sizes on the manual page:

• Yi: _Best to think of ksmps as internal to csound engine, SW as an optionally used size for sofrtware hosts, and HW as optionally used size when csound audio drivers are used.

1. Csound renders ksmps samples at a time.
2. If a host sets -b and also uses csoundPerformBuffer(), that function will handle calling kperf() enough times to fill in a buffer set to the size of the SW buffer size. Hosts do not have to use this, btw, but it can be handy as a utility if the host uses a buffer size that is different than the ksmps. In this case, ksmps can be larger or smaller than the SW buffer size, and the code handles filling in the SW buffer for you so you don't have to worry about it. If a host uses csoundPerformKsmps() instead of csoundPerformBuffer(), -b does nothing.
3. If a csound-based application uses Csound audio output drivers, then the HW buffer size comes into play. That value is used by the driver to request a buffer size to use when working with the audio I/O API (portaudio, coreaudio, etc.). It might be the request -B size or it might get a different size from the API. At that point, csound's responsibility is to fill the agreed upon HW buffer size to return to the driver. It will generally be like csoundPerformBuffer() where it will run kperf() enough times to fill in the HW buffer.

I think of SW and HW buffer sizes as mutually exclusive. If a host app uses csound's output drivers then only -B comes into play. If it uses csoundPerformBuffer() it will generally handle samples directly and so only -b comes into play.

That all said, I haven't been too involved in the code that uses -b and -B values. <@561118142710153216> and <@968827800855400559> could verify and clarify any points._

• add image ( if corect)

buffer_diagram.pdf