At Mon, 04 Feb 2013 08:23:14 -0600, Pierre-Louis Bossart wrote:
The snd_compr_update_tstamp() can only fill in the snd_compr_tstamp if the codec implements the pointer() function. If that happened the code was previously returning uninitialized garbage in the tstamp because it wasn't initialized anywhere.
This change zero-fills the tstamp in the two places it is used before calling snd_compr_update_tstamp(), and also has snd_compr_update_tstamp() return an error indication if it can't provide a tstamp. For the case of snd_compr_calc_avail() it ignores this error because we still need to return info on the available buffer space even if we can't provide tstamp info - when the tstamp is not valid all fields are now guaranteed to be zero.
I think I am missing something here. For compressed data, the DSP really needs to return a timestamp or the application will not be able to track the audio time, it'll only be able to refill buffers. Since with variable-rate compression we cannot translate bytes to time, isn't it a requirement that timestamps be supported for this API? If you don't support the .pointer, how will you provide this information to user-space levels?
It's hypothetically allowed to have a driver without pointer ops, so we need to cover the leak of uninitialized kernel space anyway. Whether the driver without pointer ops is practically useful or not is another question...
Takashi