Re: Enabling tstamp in proc status file externally

[Pavel Hofman <pavel.hofman@ivitera.com>]

Hi Takashi,

Dne 18. 06. 22 v 22:52 Takashi Sakamoto napsal(a):
> Hi Pavel,
> 
> On Thu, Jun 09, 2022 at 02:38:58PM +0200, Pavel Hofman wrote:
>> Hi,
>>
>> Please is there any way to enable the tstamp in stream status without
>> modifying the client calling the alsa-lib API? I wanted to measure
>> samplerate ratio between soundcards using data in their status proc files
>> (comparing advancement of tstamp vs. hw_ptr). The method seems to work quite
>> good, but some clients enable the stream status tstamp (e.g. pulseaudio) and
>> some don't (e.g. sox, aplay), resulting in zeros in the status proc file.
>>
>> Thanks a lot for any help or hint.
> 
> One night sleep after posting my comment to your patch for aplay[1] brings
> me an idea to use tracepoints events for your purpose (it's 5:00 am at
> UTC+07:00).
> 
> ALSA PCM core supports some kinds of tracepoints events[2]. They are
> categorized to two parts; the history of hwptr/applptr and hardware
> parameters of PCM substream. I think the former category of tracepoints
> events are available for your work to invent diagnostics tools since all
> of tracepoints events can be retrieved by user space application with
> system time stamp. I think the type of time stamp is selectable by
> options when retrieving records of tracepoints events. Furthermore the
> time stamp is essentially the same as the ones of trigger/current/driver
> time stamps in ALSA PCM interface.
> 
> I did not add enough description about the category of tracepoints when
> committed to document [2], but roughly describe here:
> 
> - hwptr
>   - the position for audio frame transmission (e.g. DMA).
> - applptr
>   - the position for user space application to read/write audio frame
>     except for operations over mmapped buffer (but depending on audio
>     hardware)
> 
> This is call graph when operating the procfs node:
> 
> (sound/core/pcm.c)
> ->snd_pcm_substream_proc_status_read()
>    (sound/core/pcm_native.c)
>    ->snd_pcm_status64()
>      (sound/core/pcm_lib.c)
>      ->snd_pcm_update_hw_ptr()
>        (sound/core/pcm_trace.h)
>        ->trace_hwptr()
> 
> You can see hwptr event is triggered as well. Actually, trace_hwptr() is
> called more frequently by usual ALSA PCM applications; e.g. ioctl(2)
> with PCM hwptr request.
> 
> We have some ways to retrieve the tracepoints events in user space:
>   - tracefs
>   - perf system call
>   - bpf


Thanks a lot for your detailed explanation. Please correct me if I am 
wrong but IIUC the snd_pcm_update_hw_ptr does not update the timestamp 
if it's not enabled. I already have access to the timestamp via the 
procfs status file, but if the client does not enable the timestamp 
specifically, the struct field will not be updated. That's why I added 
the timestamp-enable code to the alsa clients aplay/axfer.

Can the tracepoints modify the status struct and enable the timestamping 
from aside?

Thanks a lot,

Pavel.