At Fri, 13 Jun 2008 17:44:24 +0200 (CEST), Jaroslav Kysela wrote:
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...
Yes and no. Yes, it updates with a system timer. No, it's not bound with the period like the current framework.
The point is that the wake-up timing isn't defined as constant but via a timing queue (or a request queue). This is more suitable for pull-style apps like JACK. Which irq source is used doesn't matter.
Takashi