Hi,
On 2016年03月30日 14:27, Takashi Iwai wrote:
On Wed, 30 Mar 2016 02:47:06 +0200,
Takashi Sakamoto wrote:
Hi,
On Mar 29 2016 22:54, Takashi Iwai wrote:
On Sun, 27 Mar 2016 14:18:06 +0200,
Takashi Sakamoto wrote:
When audio and music units have some quirks in their sequence of packet,
it's really hard for non-owners to identify the quirks. To handle the
quirks, developers need a dump for sequence of packets at least, however
it's difficult to users who have no knowledge and equipment for this
purpose.
This commit adds tracepoints for this situation. When users encounter
the issue, they can dump a part of packet data via Linux tracing framework
as long as using drivers in ALSA firewire stack.
This commit adds 'snd-firewire-lib' subsystem with 'in_packet' and
'out_packet' events. In the events, the content of CIP headers, the number
of included quadlets and the index of packet managed by this module are
recorded per packet.
This is a sample:
$ trace-cmd record -e snd_firewire_lib:out_packet -e snd_firewire_lib:in_packet
/sys/kernel/tracing/events/snd_firewire_lib/out_packet/filter
/sys/kernel/tracing/events/snd_firewire_lib/in_packet/filter
Hit Ctrl^C to stop recording
^C
$ trace-cmd report trace.dat
...
<idle>-0 [002] 40398.221702: out_packet: 00070008 9001427a: 058: 31
<idle>-0 [002] 40398.221703: in_packet: 01020010 9001ffff: 002: 15
<idle>-0 [002] 40398.221703: out_packet: 00070010 9001ffff: 002: 32
<idle>-0 [002] 40398.223679: in_packet: 010b0010 900157e4: 090: 16
<idle>-0 [002] 40398.223681: out_packet: 00070010 900157e4: 058: 33
<idle>-0 [002] 40398.223681: in_packet: 010b0018 9001714f: 090: 17
...
One line represent one packet. The legend for the last four fields is:
- The first quadlet of CIP header
- The second quadlet of CIP header
- The number of included quadlets
- The index of packet inner buffer maintained by this module
Currently, when detecting packet discontinuity, this module stops packet
streaming. This is reasonable to packet streaming implementation. However,
to identify the quirks, packet streaming should continue to dump enough
sequence of packet. This commit adds a condition statement and a marker
for this purpose.
The packet tracing is nice, and I don't see any reason against it.
But changing the driver behavior depending on the trace state is
unusual, rather a thing to be avoided in general.
See already-identified quirks:
- 13f3a46d2a6c('ALSA: oxfw: add Mackie Onyx Satellite quirk to inform
wrong value in 'dbs' field in tx CIP header')
- 18f5ed365d3f('ALSA: fireworks/firewire-lib: add support for recent
firmware quirk')
- c4d860a0d256('ALSA: bebob: loosen up severity of checking continuity
for BeBoB v3 quirk')
- 9d59124cacf5('ALSA: bebob/firewire-lib: Add a quirk of wrong dbc in
empty packet for M-Audio special Firewire series')
- d9cd0065c8a4('ALSA: fireworks/firewire-lib: Add a quirk for fixed
interval of reported dbc')
- c8bdf49b9935('ALSA: fireworks/firewire-lib: Add a quirk for the
meaning of dbc')
To investigate quirks similar to these, the sequence of packet
before/after detecting discontinuity helps us. It's a reason to change
the behaviour against the general issue.
Yeah, I know the reason. But my point is that tracing is only for
showing the state of the code flow, and it's not a debug flag to
change the code flow itself. It's unusual that the driver behavior
depends on the tracing state.
That being said, you should show that this driver behavior change
won't affect any other device behavior, i.e. it won't be any cause of
heisenbugs.
No uncertainty there is, even if the return statement is skipped. For
me, it has been one of ways to gather packet dumps (with printk).
(But near future, Königsberg 1931, by myself.)
Regards
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
