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.
thanks,
Takashi