Dne 19.12.2014 v 22:17 Pierre-Louis Bossart napsal(a):
Thanks for the review Jaroslav
- ext_info member is not required - the standard info field has enough free bits
Well this was added at Takashi's request, the initial patches didn't rely on this extension...I can roll back those changes if this is the consensus.
Yes, every developer has it's own opinions.. I would just not to add next field until the all bits are not used.
- the whole struct snd_pcm_status is R/O - _IOR('A', 0x20, struct snd_pcm_status); I believe that it's much better to add new audio_tstamp_type to sw_params, but see (4)
I thought about this, but
- selecting the timestamp type with sw_params would require multiple
system calls to achieve the same results. Every additional call or delay changes the accuracy of the results and correlation between data consumption and timing reports.
- existing code already relies on snd_pcm_status to retrieve system and
audio timestamps, the selection through other means would make the code more complicated.
Not much.. See bellow..
- accuracy - I would use uint64_t and report accuracy in pico-seconds (range from 0 picoseconds to 18446744 seconds); yes, use next bytes from the reserved part of status struct. the __u32 might be used only for flags
The timestamps are not better than nanoseconds. I don't actually know of any link that uses a wallclock higher than 24/48Mhz, so that's already ~20-40ns already. It seemed overkill to me do use more than 3 significant digits and an exponent to represent a nominal value that doesn't take jitter and drift into account anyway. The idea was to provide a qualitative value, not an actual measurement.
I just don't like the packing. I would use uint32 for nanoseconds or eventually, it might be good to use numerator/denominator combo like for the rate.
- if there is a motivation to call / obtain timestamps for multiple purposes (audio tstamp types), then offer to return all these timestamps in one shot rather than do multiple queries (again, use reserved bytes)
I thought about this case but I couldn't find any practical uses of multiple timestamps at the same time. In the absence of any atomic hardware snapshots of multiple counters, reading multiple values sequentially from different counters would actually water-down the accuracy and value of the timestamps returned. It's already hard-enough to track a single pair of audio and system counters.
Then - why you argument for my (2) comment against sw_params/status combo ? I also think that one type of audio timestamp is enough for "almost all" application to compare the audio time with other time sources. Eventually, we can add multiple audio timestamps to the status structure and multiple audio timestamp type selectors to sw params and do everything in one shot (status ioctl) - which is the best method because you save time to retreve the other fields in the status structure again. So - for example - I would agree to have 2 audio timestamp selectors in sw_params and provide 2 different audio timestamps in the status structure. This may be the ultimate solution.
Jaroslav