Hi,
I was experimenting with different fragment sizes and small buffers. With really small buffers of 64 frames/fragment and a buffer of 2 or 3 fragments (periods) PD didn't work. I started hacking in the internals and I have a couple questions. If I read the code corectly, there is in the main scheduler loop a "microsleep" of at least(?) 1 ms. Why? Removing it makes small buffers work. Since one block of 64 samples is about 1.45 ms, it also seems to waste 60% of available CPU power (worst case). .
Also: The ALSA code is not quit correct. It sets the fragment-size and buffer- size with _set_near functions, but doesn't check the return, except for errors. So you can set these sizes to anything you want on the command line, and the pcm device will open with the nearest available size. PD however, will use your command line arguments to set the micosleep interval, and to preload the audio buffer with silence, and do some other things that I haven't tracked fully. This is not all bad, the preloading is done to the entire blocksize*nfragments buffer, so this determines the minimal latency when the pcm's are started. This way you can 'fake' an smaller buffer with cards that have a large fixed buffer size. Still you only _need_ to preload 1 or 2 fragments before starting, and it sometimes makes it seem that these command line settings have no or an opposite effect.
And a final question: The ALSA code writes before reading. Wouldn't it be better the other way around?
Shall I implement these changes in the ALSA code and send a patch?
regards
Gerard