On Jul 20 2015 23:23, Takashi Iwai wrote:
On Sat, 11 Jul 2015 16:12:37 +0200, Takashi Sakamoto wrote:
TASCAM FireWire series transfers status and control messages in isochronous packets. One packet includes one message, and the message is periodic every 64 packets. As a result, the messages construct image with 64 quadlets. For example:
00 00000000, 32 00000000 01 00000000, 33 00000000 02 00000000, 34 00000000 03 00020000, 35 00000000 04 00000000, 36 25ea0000 05 ffff0000, 37 27dfff00 06 ffffffff, 38 1d9d0000 07 ffffffff, 39 00000000 08 ffffffff, 40 25ea0000 09 ffffffff, 41 27dfff00 10 00000000, 42 00000000 11 00000000, 43 00000000 12 00000000, 44 00000000 13 00000000, 45 00000000 14 00000000, 46 00000000 15 00010000, 47 00000000 16 00012e00, 48 00000000 17 00010400, 49 00000000 18 00011e00, 50 00000000 19 00011200, 51 00000000 20 00014900, 52 01010101 21 00011e00, 53 00000000 22 00010c00, 54 25ea0000 23 00013000, 55 27dfff00 24 00000000, 56 00000000 25 00000000, 57 00000000 26 00000000, 58 00000000 27 00000000, 59 00000001 28 00000000, 60 00000000 29 00000000, 61 00000000 30 00000000, 62 00000000 31 00000000, 63 00000000
Quadlet 00-15 show control messages. Quadlet 16-23 show analog input level. Quadlet 24-31 shows digital ADAT input level. Quadlet 32-33 shows digital S/PDIF input level. Quadlet 34-35 is unknown. Quadlet 36-43 shows analog output level. The other quadlets are unknown.
This image is updated every 1 msec or less, depending on current sampling transfer frequency.
This commit adds MMAP support to show this image via hwdep interface. An userspace application can map a page frame to its virtual address space with read-only flag. This driver write every control and status messages into the page frame, and the userspace application can parse them.
The control messages are both of edge-triggered/level-trigerred, according to physical implementation. For example, the control message corresponding to toggle switch acts as edge-trigger, while the control message corresponding to level fader acts as level-trigger. These control messages are updated every 1 msec or less, alghough the scheduling granuality in Linux operating system is not always so small. This may cause the userspace parser misses some messages when many tasks are running without voluntary programs.
Typically, such messages should be converted to MIDI control change messages for userspace applications. Thus, this driver should have a converter with appropriate MIDI map. Currently I have no good idea for the map and it is not implemented yet. Developers helps are required.
Cc: Yoshifuji Hideaki yoshfuji@linux-ipv6.org Signed-off-by: Takashi Sakamoto o-takashi@sakamocchi.jp
Using mmap for accessing this kind of message isn't good for various reasons. First off, it's volatile, and your implementation keeps only a single record, thus it will be overridden at each input.
Second, the access is racy.
Third, the mmap implementation can be complex if a cache coherency plays a role. It's easy on x86, but for others...
Indeed. Now I investigate about the converter between the bitmap and MIDI messages.
But anyway, input/output level should be exposed to userspace because it doesn't matter to miss reading the information sometimes.
And the rest... there must be something else I overlooked obviously (I don't count a bug here, e.g. the lack of offset value check in vm fault handler :)
Thanks
Takashi Sakamoto