ALSA: pcm: Replace PCM hwptr tracking with tracepoints
ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs. But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.
In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own. Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.
The new "snd_pcm" entry will appear in the tracing events:
# ls -F /sys/kernel/debug/tracing/events/snd_pcm
enable filter hw_ptr_error/ hwptr/ xrun/
The hwptr is for the regular hwptr update events. An event trace
looks like:
aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call. The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
offset. It increments up to the PCM position boundary.)
The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".
The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch. Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.
Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-04 11:45:59 +00:00
|
|
|
#undef TRACE_SYSTEM
|
|
|
|
|
#define TRACE_SYSTEM snd_pcm
|
|
|
|
|
#define TRACE_INCLUDE_FILE pcm_trace
|
|
|
|
|
|
|
|
|
|
#if !defined(_PCM_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
|
|
|
|
|
#define _PCM_TRACE_H
|
|
|
|
|
|
|
|
|
|
#include <linux/tracepoint.h>
|
|
|
|
|
|
|
|
|
|
TRACE_EVENT(hwptr,
|
|
|
|
|
TP_PROTO(struct snd_pcm_substream *substream, snd_pcm_uframes_t pos, bool irq),
|
|
|
|
|
TP_ARGS(substream, pos, irq),
|
|
|
|
|
TP_STRUCT__entry(
|
|
|
|
|
__field( bool, in_interrupt )
|
|
|
|
|
__field( unsigned int, card )
|
|
|
|
|
__field( unsigned int, device )
|
|
|
|
|
__field( unsigned int, number )
|
|
|
|
|
__field( unsigned int, stream )
|
|
|
|
|
__field( snd_pcm_uframes_t, pos )
|
|
|
|
|
__field( snd_pcm_uframes_t, period_size )
|
|
|
|
|
__field( snd_pcm_uframes_t, buffer_size )
|
|
|
|
|
__field( snd_pcm_uframes_t, old_hw_ptr )
|
|
|
|
|
__field( snd_pcm_uframes_t, hw_ptr_base )
|
|
|
|
|
),
|
|
|
|
|
TP_fast_assign(
|
|
|
|
|
__entry->in_interrupt = (irq);
|
|
|
|
|
__entry->card = (substream)->pcm->card->number;
|
|
|
|
|
__entry->device = (substream)->pcm->device;
|
|
|
|
|
__entry->number = (substream)->number;
|
|
|
|
|
__entry->stream = (substream)->stream;
|
|
|
|
|
__entry->pos = (pos);
|
|
|
|
|
__entry->period_size = (substream)->runtime->period_size;
|
|
|
|
|
__entry->buffer_size = (substream)->runtime->buffer_size;
|
|
|
|
|
__entry->old_hw_ptr = (substream)->runtime->status->hw_ptr;
|
|
|
|
|
__entry->hw_ptr_base = (substream)->runtime->hw_ptr_base;
|
|
|
|
|
),
|
2017-06-12 00:41:46 +00:00
|
|
|
TP_printk("pcmC%dD%d%s/sub%d: %s: pos=%lu, old=%lu, base=%lu, period=%lu, buf=%lu",
|
ALSA: pcm: Replace PCM hwptr tracking with tracepoints
ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs. But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.
In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own. Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.
The new "snd_pcm" entry will appear in the tracing events:
# ls -F /sys/kernel/debug/tracing/events/snd_pcm
enable filter hw_ptr_error/ hwptr/ xrun/
The hwptr is for the regular hwptr update events. An event trace
looks like:
aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call. The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
offset. It increments up to the PCM position boundary.)
The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".
The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch. Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.
Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-04 11:45:59 +00:00
|
|
|
__entry->card, __entry->device,
|
2017-06-12 00:41:46 +00:00
|
|
|
__entry->stream == SNDRV_PCM_STREAM_PLAYBACK ? "p" : "c",
|
ALSA: pcm: Replace PCM hwptr tracking with tracepoints
ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs. But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.
In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own. Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.
The new "snd_pcm" entry will appear in the tracing events:
# ls -F /sys/kernel/debug/tracing/events/snd_pcm
enable filter hw_ptr_error/ hwptr/ xrun/
The hwptr is for the regular hwptr update events. An event trace
looks like:
aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call. The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
offset. It increments up to the PCM position boundary.)
The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".
The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch. Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.
Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-04 11:45:59 +00:00
|
|
|
__entry->number,
|
|
|
|
|
__entry->in_interrupt ? "IRQ" : "POS",
|
|
|
|
|
(unsigned long)__entry->pos,
|
|
|
|
|
(unsigned long)__entry->old_hw_ptr,
|
|
|
|
|
(unsigned long)__entry->hw_ptr_base,
|
|
|
|
|
(unsigned long)__entry->period_size,
|
|
|
|
|
(unsigned long)__entry->buffer_size)
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
TRACE_EVENT(xrun,
|
|
|
|
|
TP_PROTO(struct snd_pcm_substream *substream),
|
|
|
|
|
TP_ARGS(substream),
|
|
|
|
|
TP_STRUCT__entry(
|
|
|
|
|
__field( unsigned int, card )
|
|
|
|
|
__field( unsigned int, device )
|
|
|
|
|
__field( unsigned int, number )
|
|
|
|
|
__field( unsigned int, stream )
|
|
|
|
|
__field( snd_pcm_uframes_t, period_size )
|
|
|
|
|
__field( snd_pcm_uframes_t, buffer_size )
|
|
|
|
|
__field( snd_pcm_uframes_t, old_hw_ptr )
|
|
|
|
|
__field( snd_pcm_uframes_t, hw_ptr_base )
|
|
|
|
|
),
|
|
|
|
|
TP_fast_assign(
|
|
|
|
|
__entry->card = (substream)->pcm->card->number;
|
|
|
|
|
__entry->device = (substream)->pcm->device;
|
|
|
|
|
__entry->number = (substream)->number;
|
|
|
|
|
__entry->stream = (substream)->stream;
|
|
|
|
|
__entry->period_size = (substream)->runtime->period_size;
|
|
|
|
|
__entry->buffer_size = (substream)->runtime->buffer_size;
|
|
|
|
|
__entry->old_hw_ptr = (substream)->runtime->status->hw_ptr;
|
|
|
|
|
__entry->hw_ptr_base = (substream)->runtime->hw_ptr_base;
|
|
|
|
|
),
|
2017-06-12 00:41:46 +00:00
|
|
|
TP_printk("pcmC%dD%d%s/sub%d: XRUN: old=%lu, base=%lu, period=%lu, buf=%lu",
|
ALSA: pcm: Replace PCM hwptr tracking with tracepoints
ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs. But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.
In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own. Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.
The new "snd_pcm" entry will appear in the tracing events:
# ls -F /sys/kernel/debug/tracing/events/snd_pcm
enable filter hw_ptr_error/ hwptr/ xrun/
The hwptr is for the regular hwptr update events. An event trace
looks like:
aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call. The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
offset. It increments up to the PCM position boundary.)
The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".
The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch. Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.
Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-04 11:45:59 +00:00
|
|
|
__entry->card, __entry->device,
|
2017-06-12 00:41:46 +00:00
|
|
|
__entry->stream == SNDRV_PCM_STREAM_PLAYBACK ? "p" : "c",
|
ALSA: pcm: Replace PCM hwptr tracking with tracepoints
ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs. But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.
In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own. Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.
The new "snd_pcm" entry will appear in the tracing events:
# ls -F /sys/kernel/debug/tracing/events/snd_pcm
enable filter hw_ptr_error/ hwptr/ xrun/
The hwptr is for the regular hwptr update events. An event trace
looks like:
aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call. The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
offset. It increments up to the PCM position boundary.)
The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".
The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch. Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.
Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-04 11:45:59 +00:00
|
|
|
__entry->number,
|
|
|
|
|
(unsigned long)__entry->old_hw_ptr,
|
|
|
|
|
(unsigned long)__entry->hw_ptr_base,
|
|
|
|
|
(unsigned long)__entry->period_size,
|
|
|
|
|
(unsigned long)__entry->buffer_size)
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
TRACE_EVENT(hw_ptr_error,
|
|
|
|
|
TP_PROTO(struct snd_pcm_substream *substream, const char *why),
|
|
|
|
|
TP_ARGS(substream, why),
|
|
|
|
|
TP_STRUCT__entry(
|
|
|
|
|
__field( unsigned int, card )
|
|
|
|
|
__field( unsigned int, device )
|
|
|
|
|
__field( unsigned int, number )
|
|
|
|
|
__field( unsigned int, stream )
|
|
|
|
|
__field( const char *, reason )
|
|
|
|
|
),
|
|
|
|
|
TP_fast_assign(
|
|
|
|
|
__entry->card = (substream)->pcm->card->number;
|
|
|
|
|
__entry->device = (substream)->pcm->device;
|
|
|
|
|
__entry->number = (substream)->number;
|
|
|
|
|
__entry->stream = (substream)->stream;
|
|
|
|
|
__entry->reason = (why);
|
|
|
|
|
),
|
2017-06-12 00:41:46 +00:00
|
|
|
TP_printk("pcmC%dD%d%s/sub%d: ERROR: %s",
|
ALSA: pcm: Replace PCM hwptr tracking with tracepoints
ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs. But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.
In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own. Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.
The new "snd_pcm" entry will appear in the tracing events:
# ls -F /sys/kernel/debug/tracing/events/snd_pcm
enable filter hw_ptr_error/ hwptr/ xrun/
The hwptr is for the regular hwptr update events. An event trace
looks like:
aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call. The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
offset. It increments up to the PCM position boundary.)
The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".
The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch. Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.
Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-04 11:45:59 +00:00
|
|
|
__entry->card, __entry->device,
|
2017-06-12 00:41:46 +00:00
|
|
|
__entry->stream == SNDRV_PCM_STREAM_PLAYBACK ? "p" : "c",
|
ALSA: pcm: Replace PCM hwptr tracking with tracepoints
ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs. But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.
In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own. Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.
The new "snd_pcm" entry will appear in the tracing events:
# ls -F /sys/kernel/debug/tracing/events/snd_pcm
enable filter hw_ptr_error/ hwptr/ xrun/
The hwptr is for the regular hwptr update events. An event trace
looks like:
aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call. The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
offset. It increments up to the PCM position boundary.)
The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".
The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch. Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.
Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-04 11:45:59 +00:00
|
|
|
__entry->number, __entry->reason)
|
|
|
|
|
);
|
|
|
|
|
|
ALSA: pcm: add 'applptr' event of tracepoint
In design of ALSA PCM core, status and control data for runtime of ALSA
PCM substream are shared between kernel/user spaces by page frame
mapping with read-only attribute. Both of hardware-side and
application-side position on PCM buffer are maintained as a part of
the status data. In a view of ALSA PCM application, these two positions
can be updated by executing ioctl(2) with some commands.
There's an event of tracepoint for hardware-side position; 'hwptr'.
On the other hand, no events for application-side position. This commit
adds a new event for this purpose; 'applptr'. When the application-side
position is changed in kernel space, this event is probed with useful
information for developers.
I note that the event is not probed for all of ALSA PCM applications, When
applications are written by read/write programming scenario, the event is
surely probed. The applications execute ioctl(2) with
SNDRV_PCM_IOCTL_[READ|WRITE][N/I]_FRAMES to read/write any PCM frame, then
ALSA PCM core updates the application-side position in kernel land.
However, when applications are written by mmap programming scenario, if
maintaining the application side position in kernel space accurately,
applications should voluntarily execute ioctl(2) with
SNDRV_PCM_IOCTL_SYNC_PTR to commit the number of handled PCM frames. If
not voluntarily, the application-side position is not changed, thus the
added event is not probed.
There's a loophole, using architectures to which ALSA PCM core judges
non cache coherent. In this case, the status and control data is not mapped
into processe's VMA for any applications. Userland library, alsa-lib, is
programmed for this case. It executes ioctl(2) with
SNDRV_PCM_IOCTL_SYNC_PTR command every time to requiring the status and
control data.
ARM is such an architecture. Below is an example with serial sound interface
(ssi) on i.mx6 quad core SoC. I use v4.1 kernel released by fsl-community
with patches from VIA Tech. Inc. for VAB820, and my backport patches for
relevant features for this patchset. I use Ubuntu 17.04 from
ports.ubuntu.com as user land for armhf architecture.
$ aplay -v -M -D hw:imx6vab820sgtl5,0 /dev/urandom -f S16_LE -r 48000 --period-size=128 --buffer-size=256
Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
Hardware PCM card 0 'imx6-vab820-sgtl5000' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 256
period_size : 128
period_time : 2666
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 128
period_event : 0
start_threshold : 256
stop_threshold : 256
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
mmap_area[0] = 0x76f98000,0,16 (16)
$ trace-cmd record -e snd_pcm:hwptr -e snd_pcm:applptr
$ trace-cmd report
...
60.208495: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256
60.208633: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256
60.210022: hwptr: pcmC0D0p/sub0: IRQ: pos=128, old=1536, base=1536, period=128, buf=256
60.210202: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
60.210344: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256
60.210348: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
60.210486: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
60.210626: applptr: pcmC0D0p/sub0: prev=1792, curr=1920, avail=0, period=128, buf=256
60.211002: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
60.211142: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256
60.211146: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
60.211287: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
60.212690: hwptr: pcmC0D0p/sub0: IRQ: pos=0, old=1664, base=1536, period=128, buf=256
60.212866: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
60.212999: hwptr: pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256
60.213003: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
60.213135: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
60.213276: applptr: pcmC0D0p/sub0: prev=1920, curr=2048, avail=0, period=128, buf=256
60.213654: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
60.213796: hwptr: pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256
60.213800: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
60.213937: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
60.215356: hwptr: pcmC0D0p/sub0: IRQ: pos=128, old=1792, base=1792, period=128, buf=256
60.215542: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
60.215679: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1920, base=1792, period=128, buf=256
60.215683: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
60.215813: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
60.215947: applptr: pcmC0D0p/sub0: prev=2048, curr=2176, avail=0, period=128, buf=256
...
We can surely see 'applptr' event is probed even if the application run
for mmap programming scenario ('-M' option and 'hw' plugin). Below is a
result of strace:
02:44:15.886382 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.887203 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
02:44:15.887471 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.887637 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.887805 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.887969 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.888132 read(3, "..."..., 256) = 256
02:44:15.889040 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.889221 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.889431 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.889606 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
02:44:15.889833 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.889998 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.890164 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.891048 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.891228 read(3, "..."..., 256) = 256
02:44:15.891497 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.891661 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.891829 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.891991 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
02:44:15.893007 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
We can see 7 calls of ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR per loop with
call of poll(2). 128 PCM frames are transferred per loop of one poll(2),
because the PCM substream is configured with S16_LE format and 1 channel
(2 byte * 1 * 128 = 256 bytes). This equals to the size of period of PCM
buffer. Comparing to the probed data, one of the 7 calls of ioctl(2) is
actually used to commit the number of copied PCM frames to kernel space.
The other calls are just used to check runtime status of PCM substream;
e.g. XRUN.
The tracepoint event is useful to investigate this case. I note that below
modules are related to the above sample.
* snd-soc-dummy.ko
* snd-soc-imx-sgtl5000.ko
* snd-soc-fsl-ssi.ko
* snd-soc-imx-pcm-dma.ko
* snd-soc-sgtl5000.ko
My additional note is lock acquisition. The event is probed under acquiring
PCM stream lock. This means that calculation in the event is free from
any hardware events.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-06-12 00:41:45 +00:00
|
|
|
TRACE_EVENT(applptr,
|
|
|
|
|
TP_PROTO(struct snd_pcm_substream *substream, snd_pcm_uframes_t prev, snd_pcm_uframes_t curr),
|
|
|
|
|
TP_ARGS(substream, prev, curr),
|
|
|
|
|
TP_STRUCT__entry(
|
|
|
|
|
__field( unsigned int, card )
|
|
|
|
|
__field( unsigned int, device )
|
|
|
|
|
__field( unsigned int, number )
|
|
|
|
|
__field( unsigned int, stream )
|
|
|
|
|
__field( snd_pcm_uframes_t, prev )
|
|
|
|
|
__field( snd_pcm_uframes_t, curr )
|
|
|
|
|
__field( snd_pcm_uframes_t, avail )
|
|
|
|
|
__field( snd_pcm_uframes_t, period_size )
|
|
|
|
|
__field( snd_pcm_uframes_t, buffer_size )
|
|
|
|
|
),
|
|
|
|
|
TP_fast_assign(
|
|
|
|
|
__entry->card = (substream)->pcm->card->number;
|
|
|
|
|
__entry->device = (substream)->pcm->device;
|
|
|
|
|
__entry->number = (substream)->number;
|
|
|
|
|
__entry->stream = (substream)->stream;
|
|
|
|
|
__entry->prev = (prev);
|
|
|
|
|
__entry->curr = (curr);
|
|
|
|
|
__entry->avail = (substream)->stream ? snd_pcm_capture_avail(substream->runtime) : snd_pcm_playback_avail(substream->runtime);
|
|
|
|
|
__entry->period_size = (substream)->runtime->period_size;
|
|
|
|
|
__entry->buffer_size = (substream)->runtime->buffer_size;
|
|
|
|
|
),
|
|
|
|
|
TP_printk("pcmC%dD%d%s/sub%d: prev=%lu, curr=%lu, avail=%lu, period=%lu, buf=%lu",
|
|
|
|
|
__entry->card,
|
|
|
|
|
__entry->device,
|
|
|
|
|
__entry->stream ? "c" : "p",
|
|
|
|
|
__entry->number,
|
|
|
|
|
__entry->prev,
|
|
|
|
|
__entry->curr,
|
|
|
|
|
__entry->avail,
|
|
|
|
|
__entry->period_size,
|
|
|
|
|
__entry->buffer_size
|
|
|
|
|
)
|
|
|
|
|
);
|
|
|
|
|
|
ALSA: pcm: Replace PCM hwptr tracking with tracepoints
ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs. But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.
In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own. Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.
The new "snd_pcm" entry will appear in the tracing events:
# ls -F /sys/kernel/debug/tracing/events/snd_pcm
enable filter hw_ptr_error/ hwptr/ xrun/
The hwptr is for the regular hwptr update events. An event trace
looks like:
aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call. The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
offset. It increments up to the PCM position boundary.)
The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".
The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch. Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.
Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-11-04 11:45:59 +00:00
|
|
|
#endif /* _PCM_TRACE_H */
|
|
|
|
|
|
|
|
|
|
/* This part must be outside protection */
|
|
|
|
|
#undef TRACE_INCLUDE_PATH
|
|
|
|
|
#define TRACE_INCLUDE_PATH .
|
|
|
|
|
#include <trace/define_trace.h>
|