On Fri, 13 Jun 2008, Takashi Iwai wrote:
Ditto, or we may reuse snd_pcm_hw_params_fifo_size()?Yes, fifo_size was designed to announce possible extra latency to applications.
On the second thought, it's better *not* to query this value as hw_params. The latency may be variable. And the word "FIFO" isn't appropriate in every case.
And, above all, reviving an old API is bad...
This value should define maximum latency - not actual latency. snd_pcm_delay() should give actual overall latency to apps.
I think that the current PCM API concept is tightly period based. You cannot change it easily. It would be probably better to move to "byte-stream" in next revision of PCM API.
Not that difficult, I guess, from API POV. The major work is in the PCM core part and some alsa-lib plugins. But, it's not API.
What I once worked on is an extra timinig queue. Suppose that we provide an API to access a timing queue that holds the wake-up schedule, either in time or sample unit. The poll / read / write syscalls are woken up at the time of this schedule. In the case of period model, it means that the queue is automatically filled up with a constant period. If app wants to schedule by itself, it can use this queue manually. (Of course, this means that the timing queue must be filled before starting the stream.)
It look like more complicated sleep_min implementation we already had:
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=31e8960b35975ed235...
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.