Re: Overflow in calculating audio timestamp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2/2/23 07:55, Alan Young wrote:
> sound/core/pcm_lib.c:update_audio_tstamp() contains the following
> calculation:
> 
>         audio_nsecs = div_u64(audio_frames * 1000000000LL,
>                 runtime->rate);
> 
> This will result in a 64-bit overflow after 4.4 days at 48000 Hz, or 1.1
> days at 192000.
> 
> Are you interested in a patch to improve this?
> 
> The same calculation occurs in a couple of other places.

It's clearly unintentional, thanks for reporting this.

I added this in 2012 in

4eeaaeaea1ce ("ALSA: core: add hooks for audio timestamps")

and probably assumed the use of 64-bit was good enough. You just proved
me wrong!




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux