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. > > 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. Stephane Letz
