* Enabling tstamp in proc status file externally
@ 2022-06-09 12:38 Pavel Hofman
2022-06-18 20:52 ` Takashi Sakamoto
0 siblings, 1 reply; 4+ messages in thread
From: Pavel Hofman @ 2022-06-09 12:38 UTC (permalink / raw)
To: alsa-devel
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.
Best regards,
Pavel.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Enabling tstamp in proc status file externally
2022-06-09 12:38 Enabling tstamp in proc status file externally Pavel Hofman
@ 2022-06-18 20:52 ` Takashi Sakamoto
2022-06-19 8:03 ` Pavel Hofman
0 siblings, 1 reply; 4+ messages in thread
From: Takashi Sakamoto @ 2022-06-18 20:52 UTC (permalink / raw)
To: Pavel Hofman; +Cc: alsa-devel
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
You can easily find many good documentations about them; e.g.
- BPF Performance Tools (Brendan Gregg 2020, Addison Wesley,
ISBN-13 78-0136554820 )
I prefer your intention diagnose the runtime of PCM substream. I think
every one almost certainly love the work. So it's nice to go forward
without discouraged.
[1] Re: [PATCH] aplay: Support setting timestamp
https://lore.kernel.org/alsa-devel/Yq2Lfn+RJx96Qqvh@workstation/
[2] Documentation/sound/designs/tracepoints.rst in source of Linux kernel
https://www.kernel.org/doc/html/latest/sound/designs/tracepoints.html
Cheerss
Takashi Sakamoto
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Enabling tstamp in proc status file externally
2022-06-18 20:52 ` Takashi Sakamoto
@ 2022-06-19 8:03 ` Pavel Hofman
2022-06-20 4:48 ` Takashi Sakamoto
0 siblings, 1 reply; 4+ messages in thread
From: Pavel Hofman @ 2022-06-19 8:03 UTC (permalink / raw)
To: Takashi Sakamoto; +Cc: alsa-devel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Enabling tstamp in proc status file externally
2022-06-19 8:03 ` Pavel Hofman
@ 2022-06-20 4:48 ` Takashi Sakamoto
0 siblings, 0 replies; 4+ messages in thread
From: Takashi Sakamoto @ 2022-06-20 4:48 UTC (permalink / raw)
To: Pavel Hofman; +Cc: alsa-devel
On Sun, Jun 19, 2022 at 10:03:24AM +0200, Pavel Hofman wrote:
> 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?
The configuration of runtime of PCM bustream is immutable from
tracepoints, thus we have no way to enable it unless changing code of
PCM application.
In my understanding, your aim is to estimate samplerate ratio by
computing the history of hw_ptr with time stamp in running PCM substream.
Both of them are provided by the tracepoints events, In the case, Linux
tracepoints framework record time stamp. I think the time stamp is mostly
equivalent to the time stamp which ALSA PCM core put into the structure
and expose to user space, since both of them are sampled from system time
within atomic context. The clock_id is selectable; e.g. perf_event_open
system call receive 'struct perf_event_attr' which includes clockid field
since Linux kernel 4.1 or later[1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f439278cef
Regards
Takashi Sakamoto
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-06-20 4:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-09 12:38 Enabling tstamp in proc status file externally Pavel Hofman
2022-06-18 20:52 ` Takashi Sakamoto
2022-06-19 8:03 ` Pavel Hofman
2022-06-20 4:48 ` Takashi Sakamoto
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.