On Fri, 13.06.08 18:47, Jaroslav Kysela (perex@perex.cz) wrote:
What about just providing three pointers: curr_ptr, hw_ptr and appl_ptr? curr_ptr corresponds to the point being played, and hw_ptr is the point where the data was already sent to h/w, and appl_ptr is the point where the data is filled by user. The above definitions are all combinations of these pointers.
But I think that curr_ptr can be managed in drivers, thus invisible to user space (except for snd_pcm_delay() propagation).
Ditto for hw_ptr. Why is it hidden at all?
Does it improve something to show this pointer to apps? I don't see any reason to show it outside alsa-lib.
As I already pointed out different applications need different kinds of timing information. Some want to estimate when the next xrun will happen, other's want the delay that the next write will take to be played, even other's want how much of the already written data is not yet played. Even other's want absolute times.
And I do follow Takashi in so far that when you'd just choose to export the three pointers to userspace, so that they can be queried atomically everybody can relatively easily calculate from these 'raw' values what they need.
The problem I see with those 'cooked' values that are currently exported (i.e. delay and update_avail) is that they only serve a single purpose and there are so many different ways to use and especially misuse them, as we have seen in the WINE case. Certainly, the ptrs can be misused too, but at least all the information the kernel has that it uses to calculate those 'cooked' values is available to userspace too, so without too ugly code userspace can always calculate what is necessary. If you only have a subset of the cooked stuff and want to calculate the other cooked stuff from it your in pain.
I think there are two extremes:
a) export the 'raw' info to userspace: the three pointers
b) export the 'cooked' info to userspace in all its variations: similar to the API I suggested that would take an enum for choosing the right timing parameter the app wants.
Everything in between these extremes would be incomplete.
I could live with any situation of these two. The question is do you trust userspace programmers to use the three pointers correctly, or do you want to make sure they get things right with the enum API?
Lennart