From: Takashi S. <o-t...@sa...> - 2015-07-22 15:02:54
|
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 <yos...@li...> >> Signed-off-by: Takashi Sakamoto <o-t...@sa...> > > 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 |