At Fri, 13 Jun 2008 10:14:33 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 13 Jun 2008, Takashi Iwai wrote:
- Add some new API functions,
I would prefer to extend the current API than to change meaning of hw_ptr to handle extra latencies.
To give the accuracy of the position inquiry (optional)
This requires some new kernel <-> user-space stuff.
To query the known latency
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...
To query the position being played (optionally)
This can be simply hwptr + latency.
- Don't change snd_pcm_delay(). Keep as is now.
About the period model -- it's a bit more tough problem. I once already made a patch to allow user-apps to use a system timer for more flexible period settings. But, it was for very old version of ALSA. Better to write from the scratch again...
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.)
Takashi