Re: Enabling tstamp in proc status file externally

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

 



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.



[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