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