[PATCH] aplay: Support setting timestamp

[Pavel Hofman]

Dne 18. 06. 22 v 10:23 Takashi Sakamoto napsal(a):
> Hi,
> 
> On Thu, Jun 16, 2022 at 12:00:22PM +0200, 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
> 
> I had read your message, then replied to the patch.
> 
> I'm not at so strong objection to your patch, however if I'm allowed to
> note my opinion honestly, it surely brings an issue in a point of
> application design. In short, the purpose of the patch is just for the
> case to retrieve the history of PCM buffer pointer position and system
> time stamp via procfs node for PCM substream of aplay for analysis,
> therefore it's not for aplay itself.
> 
> As you know, aplay program has no code to process time stamp except for
> the case of XRUN detection. I can easily imagine the future that the new
> command line option is rarely used, except at your laboratory or office.
> 
> 
> In my opinion, the better practice for your case is to add the way to
> configure parameters of PCM substream for time stamp operation; e.g. add
> kobject parameter to ALSA PCM device for PCM substream (please avoid to
> hack procfs node since it's ancient way in unregulated world).
> 
> Although it's probably and technically possible, it has side effect to
> user processes of existent ALSA PCM applications such as PipeWire plugins
> and PulseAudio modules when the applications voluntarily process time
> stamp for any purpose.
> 
>> . 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,
> 
> It's a kind of sophisticated work, I think.
> 
> For your information, the design of several kinds of time stamp in ALSA
> PCM interface (from my memo written 2020) is below:
> 
>   - system time stamp
>      - Available for several purposes
>          - trigger (struct snd_pcm_status.trigger_tstamp)
>             - the record of time stamp at start/stop/suspend/resume/pause
>               of PCM substream.
>          - current (struct snd_pcm_status.tstamp)
>             - the record of the latest time stamp at updating hwptr, at
>               xrun and reset of PCM substream.
>          - driver (struct snd_pcm_status.driver_tstamp)
>             - the record of the latest time stamp when the driver operates
>               PCM substream at both hardIRQ/softIRQ and process contexts
>      - Multiple levels of clock_id
>         - monotinic time
>         - monotonic raw time
>         - real time (default, gettimeofday)
>      - The sampling timing at hardIRQ context is invocation of hardIRQ
>        handler instead of the time of actual interrupt request, thus
>        includes time jitter due to CPU-level IRQ-mask.
> 
>   - audio time stamp (struct snd_pcm_status.audio_tstamp,
>                       struct snd_pcm_mmap_status.audio_tstamp)
>      - timespec compensated for audio frame granularity
>      - Available when audio-related hardware supports specific function
>        to record time of DMA transmission or audio link.
>      - Currently, implemented for Intel HDA driver in Intel CPU (Skylate
>        generation or later) with Global Time Stamp (GTS) register.
>      - Multiple levels
>         - default
>             - computed just from hwptr
>         - link audio time
>         - link absolute audio time
>         - link estimated audio time
>         - link synchronized autio time
>      - For detail, please refer to
>        `Documentation/sound/designs/timestamping.rst`.
> 
> 

Takashi, I really do appreciate your comprehensive and very useful 
explanation. It should become part of core alsa documentation somehow, 
please.

But I cannot implement such extensive solution to either aplay or axfer, 
that's way above my skills and especially needs.

As I said in my previous message, I have axfer patch implementing the 
same feature as in my aplay patch. Should you find it usefull, I can 
submit it. You are the axfer maintainer, you call the shots :-)

Thanks a lot,

Pavel.