30 Sep
2012
30 Sep
'12
12:11 p.m.
Pierre-Louis Bossart wrote:
audio_frames = runtime->status->hw_ptr+ runtime->delay;audio_nsecs = audio_frames * 1000000000LL /runtime->rate;This looks like a 64-bit division.
... which needs to be handled with a function from <linux/math64.h>.
And what happens if audio_frames becomes negative?
It's my understanding that hw_ptr represents the cumulative frames played since the beginning, not sure why it'd become negative, ever.
2^32 / 192 kHz = 6.2 h
I don't understand the notion of 'boundary'
This is where hw_ptr wraps around. It's a multiple of the buffer size to make some calculations easier.
and the use of the hw_ptr_base
It's the hw_ptr corresponding to the start of the buffer.
I guess audio_tstamp isn't supposed to wrap around?
Regards, Clemens