[alsa-devel] [PATCH] ALSA: core: don't return uninitialized snd_compr_tstamp
tiwai at suse.de
Mon Feb 4 15:43:13 CET 2013
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...
More information about the Alsa-devel