Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Young <consult.awy@gmail.com>
To: Jaroslav Kysela <perex@perex.cz>,
	o-takashi@sakamocchi.jp, pierre-louis.bossart@linux.intel.com
Cc: alsa-devel@alsa-project.org
Subject: Re: Overflow in calculating audio timestamp
Date: Mon, 6 Feb 2023 08:52:36 +0000	[thread overview]
Message-ID: <4a1eb148-d246-7a10-9eac-57408d57cf74@gmail.com> (raw)
In-Reply-To: <fa44f39c-4dea-5433-fd89-1286ed6a94da@perex.cz>

Hi Jaroslav,

On 04/02/2023 15:40, Jaroslav Kysela wrote:
> For 32-bit apps the boundary is near to UINT32_MAX (see 
> recalculate_boundary() function). So only one crossing point is not 
> enough to cover a decent time range.
>
> There should be a better check, if the add operation crosses the U64 
> range for snd_BUG_ON. In my eyes, it looks safer to use counter here 
> and do the checks
> in the function which uses this value. 


I think you are misunderstanding how crossed_boundary is used. It 
relates to a single call of snd_pcm_update_hw_ptr0(), which should be 
called once per period, or at the very least once per buffer-size. In 
its processing, it may be detected that the boundary has been crossed. 
There are three separate tests that could result in this but only one 
should actually happen during a single call. The snd_BUG_ON() is just to 
detect (report on) a failure in that logic.

None of this restricts the total number of frames that might be 
processed, as a result of multiple boundary crossings.

Changing hw_ptr_wrap to be a boundary-wrap-counter instead of its 
current use as the cumulative number of frames processed at boundary 
wraps would not make any useful difference.

Unless there is something else that I'm missing....

Alan.


  reply	other threads:[~2023-02-06  8:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-02 13:55 Overflow in calculating audio timestamp Alan Young
2023-02-03  0:34 ` Takashi Sakamoto
2023-02-03 16:11   ` Alan Young
2023-02-03 18:02     ` Jaroslav Kysela
2023-02-04  0:54       ` Pierre-Louis Bossart
2023-02-06 15:25         ` Alan Young
2023-02-04  9:11       ` Alan Young
2023-02-04 15:40         ` Jaroslav Kysela
2023-02-06  8:52           ` Alan Young [this message]
2023-02-06  9:17             ` Jaroslav Kysela
2023-02-03 14:45 ` Pierre-Louis Bossart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a1eb148-d246-7a10-9eac-57408d57cf74@gmail.com \
    --to=consult.awy@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=o-takashi@sakamocchi.jp \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox