From: sylvain.bertrand@gmail.com
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Takashi Iwai <tiwai@suse.de>,
alsa-devel@alsa-project.org,
Kai Vehmanen <kai.vehmanen@linux.intel.com>
Subject: Re: sw_params for a direct-ed(dmix) hw pcm
Date: Sat, 28 Mar 2020 22:20:21 +0000 [thread overview]
Message-ID: <20200328222021.GA4610@freedom> (raw)
In-Reply-To: <59266c58-96d8-93e9-bc8f-86e9fccf8d60@linux.intel.com>
On Sat, Mar 28, 2020 at 04:34:01PM -0500, Pierre-Louis Bossart wrote:
> Using MONOTONIC_RAW is very nice on paper, until you realize you can't
> program a timer using the information. You can only read the timestamp and
> not really do much if you want to sleep/wait.
>
> In practice, if you really really need super-precise information you'll get
> use rdtsc(), and apply you own formulas. And otherwise stick with MONOTONIC,
> it's rather unlikely you will ever notice the NTP changes. PulseAudio, CRAS
> and a number of Android HALs use MONOTONIC and nobody ever complained.
The pb is not about using monotonic_raw, the thing is: it is documented valid
to use it which I did as expected from a naive reading of the api documentation
and found those issues. I can reasonably believe it will be the case for any
new alsa programmer.
For my code, in the end, I think I'll use the best "audio timestamp" I can get
from the status ioctl for linear interpolation with ffmpeg timestamps.
But this is off topic here.
The topic is discussing how to fix this bug, since I had to dig a bit in alsa.
It appears to me the recursive fix might be a good way, since it is done for
other api functions, but I am not Jaroslav Kysela neither Takashi Iwai then far
from grasping all the details of alsa.
--
Sylvain
next prev parent reply other threads:[~2020-03-28 22:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-21 15:53 monotonic raw setup seems buggy sylvain.bertrand
2020-03-25 17:44 ` sw_params for a direct-ed(dmix) hw pcm sylvain.bertrand
2020-03-26 12:02 ` Kai Vehmanen
2020-03-26 14:36 ` Jaroslav Kysela
2020-03-26 20:04 ` sylvain.bertrand
2020-03-27 8:08 ` Takashi Iwai
2020-03-27 9:40 ` Jaroslav Kysela
2020-03-28 18:26 ` sylvain.bertrand
2020-03-28 19:15 ` Pierre-Louis Bossart
2020-03-28 20:37 ` sylvain.bertrand
2020-03-28 21:34 ` Pierre-Louis Bossart
2020-03-28 22:20 ` sylvain.bertrand [this message]
2020-03-29 7:43 ` Takashi Iwai
2020-03-31 11:32 ` Takashi Iwai
2020-04-01 15:25 ` sylvain.bertrand
2020-04-01 15:59 ` Takashi Iwai
2020-04-01 20:21 ` sylvain.bertrand
2020-04-02 19:03 ` sylvain.bertrand
2020-04-06 13:49 ` sylvain.bertrand
2020-04-14 15:18 ` Takashi Iwai
2020-04-14 23:20 ` sylvain.bertrand
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=20200328222021.GA4610@freedom \
--to=sylvain.bertrand@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=kai.vehmanen@linux.intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=tiwai@suse.de \
/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