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@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?
As of the tstamp terminology - what command option would be more appropriate instead? Thanks a lot,
I'm fine with the proposed argument.
Thank you, Jaroslav