All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Hofman <pavel.hofman@ivitera.com>
To: alsa-devel@alsa-project.org
Subject: Re: [PATCH] aplay: Support setting timestamp
Date: Thu, 16 Jun 2022 12:00:22 +0200	[thread overview]
Message-ID: <900e96c0-6251-fa3d-42b4-847ece6e1a44@ivitera.com> (raw)
In-Reply-To: <YqrmNfnn2qCZV9Kf@workstation>

Dne 16. 06. 22 v 10:13 Takashi Sakamoto napsal(a):
> 
> On Thu, Jun 16, 2022 at 08:54:26AM +0200, Pavel Hofman wrote:
>> To allow enabling timestamp and specify its type, a new option
>> --tstamp-type=TYPE is added. Recognized values are none (default),
>> gettimeofday, monotonic, monotonic-raw.
>>
>> Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com>
>> ---
>>   aplay/aplay.1 |  4 ++++
>>   aplay/aplay.c | 32 ++++++++++++++++++++++++++++++++
>>   2 files changed, 36 insertions(+)
>   
> I prefer the idea to work for timestamp feature defined in ALSA PCM
> interface, while I have a mixed feeling to integrate `aplay` tool, since
> I have an intension to obsolete the tool with `axfer` tool with more
> robust design with command argument compatibility (as much as possible).
> 
> This is not so strong request but would I ask you to work for `axfer` tool
> instead of `aplay`? Then, it's preferable that the name of command
> argument is decided with enough care of all of timestamp feature in ALSA
> PCM interface, since we have two categories of timestamps at least; e.g.
> system timestamp and audio timestamp. As long as I know, they possibly use
> different clock sources, thus these two timestamps have different levels
> of clock id, I think.
> 
> Of course, it's a loose accord in the community to obsolete `aplay`, and
> it's easy to decide to continue aplay integration. (I'm not in leading
> place of the project.) I'll be a bit happy if people take care of axfer
> tool as well.

Thanks for your input. I use aplay in my project and needed to have 
tstamps enabled in proc status files for my simple code which calculates 
relative samplerate between capture and playback soundcards (one of them 
having rate adjustable - audio gadget, snd-aloop) 
https://mailman.alsa-project.org/pipermail/alsa-devel/2022-June/201647.html 
. The existing aplay did not have this feature, so I added it and 
submitted the patch. I did not know aplay was planned to be obsoleted, 
it seems to receive a healthy stream of patches.

As of the tstamp terminology - what command option would be more 
appropriate instead? Thanks a lot,

Pavel.


  reply	other threads:[~2022-06-16 10:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-16  6:54 [PATCH] aplay: Support setting timestamp Pavel Hofman
2022-06-16  8:13 ` Takashi Sakamoto
2022-06-16 10:00   ` Pavel Hofman [this message]
2022-06-16 10:50     ` Jaroslav Kysela
2022-06-18 15:13       ` Pavel Hofman
2022-06-18  8:23     ` Takashi Sakamoto
2022-06-18 15:20       ` Pavel Hofman

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=900e96c0-6251-fa3d-42b4-847ece6e1a44@ivitera.com \
    --to=pavel.hofman@ivitera.com \
    --cc=alsa-devel@alsa-project.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.