Re: [PATCH] aplay: Support setting timestamp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx>
---
   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.




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux