St?phane Letz wrote:
>
> Le 23 mars 09 ? 19:51, Garrett D'Amore a ?crit :
>
>> The 298 buffer size sounds like the "fragment" size that Boomer has
>> configured (about 175 Hz, but with some rounding applied, I think.)
>>
>> Architecturally, it is *very* wrong for any software to rely on the
>> underlying buffer size (be it 1024, 298, or any other value.) The
>> code *should* simply read/write data as it is available, without
>> concerning itself with what the underlying fragment size is.
>>
>> There are two ways to implement the logic correctly:
>>
>> 1) use ioctl() SNDCTL_DSP_GETOSPACE or SNDCTL_DSP_GETISPACE to
>> determine how much data can be written or read (respectively) without
>> blocking, and transfer that much data (or possibly less).
>>
>> 2) use non-blocking read/write calls, in conjunction with select or
>> poll, to transfer as much data as possible (limited by the amount of
>> data that the application can support, of course).
>>
>> In neither of these cases are you looking at internal buffer sizes or
>> fragment sizes.
>>
>> I've not looked at the code for Jack to see why it cares, but I
>> suspect rather strongly it is an error.
>
> The logic used *everywhere* (Linux/ALSA, OSX/CoreAudio,
> Windows/PortAudio...) is to set the wanted buffer size (again a
> power-of-two value in any case I can think of) when starting the JACK
> server. Then the underlying audio system is supposed to deal with that.
What do you mean by "wanted buffer size"? Why does your application
even care about the fragment size? If you want to, you could use
internally a buffer size that is the next largest power of two, and it
should work fine. (However, if you write less than a full fragment,
you might get underruns. A good policy is to configure as to write as
far ahead as you are able to, unless you have some specific lower
latency requirements.) Doubling the fragment size and queuing that much
up is a good way to avoid underruns.
>
>>
>> The only exceptions to caring about buffer sizes would be:
>>
>> a) To get a "hint" about the latency of the audio system. (One
>> can assume that the framework will transfer data in chunks of whole
>> fragments, which implies some details about the latency your
>> application can expect to endure. Though even this is not
>> guaranteed, so its only a hint.)
>>
>> b) For versions of OSS that support mmap() (Boomer doesn't at
>> present, but a future enhancement will add that), the sizes are
>> important to know so you know how much to mmap and where the pointers
>> wrap. However, you should still be using the SNDCTL_DSP_GETIPTR/OPTR
>> and SNDCTL_DSP_GETISPACE/OSPACE ioctls to determine the proper amount
>> of data to transfer.
>>
>
> Well the assuption is that is the server is started with a low buffer
> size, the overall latency will be lower. Moreover, having this
> power-of-two values make sense for applications that do FFT on blocks.
> And it was working this way when tested on OSS4 (even if we had to
> setup the wanted buffer size with the "ossxmix" tool before stating
> the server) with the different cards we tried on.
Not all OSS4 drivers adhere to the power-of-two value. You're just
getting "lucky" because of a legacy left over from predawn history of
Linux sound. You should read the OSS programmer's manual...
-- Garrett
>
> Stephane Letz
