[PATCH] aplay: Support setting timestamp

[Pavel Hofman]

Dne 16. 06. 22 v 12:50 Jaroslav Kysela napsal(a):
> On 16. 06. 22 12:00, Pavel Hofman wrote:
>> 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 at 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.
> 
> It would be good to sync both tools (aplay/axfer) for the easy 
> replacement. Could you add this code to axfer, too?

Honestly, I do not understand the future plan for axfer vs. aplay. I 
consider aplay a diagnostics tool for alsa problems. I do not need other 
audio frameworks available when diagnosing alsa. I need the diagnostics 
tool having maximum features useful for the diagnostics, such a tool is 
not used for and aimed at general usage.

Yet I have prepared a patch for axfer which implements the very same 
feature as for aplay into its libasound backend. However, since Takashi 
objects to the implementation as is (which I do not dispute, it 
certainly is not any complex solution to the timestamping area in alsa), 
I do not intend to submit the axfer patch.

If you find the aplay patch useful, I would be happy if you accepted it. 
  If not, no problem, I will use my hacked aplay version. Since nobody 
has added such feature to aplay over a decade of its existence, my patch 
is certainly of negligible urgency. I am just a bit afraid about future 
of this simple-to-use diagnostics tool with huge user base and extensive 
online know-how in this regard.

Thanks a lot,

Pavel.