centicosm
commented
7 years ago Some potentially additional information. A modified midchild.js script in windows will block on a read from the hid as expected until real data (e.g. a full vad (0xFF) report) is available. The same script in Ubuntu 14, 16, and 17, Fedora, and Ref-OS-IoT will get the same, incomplete reports as in the python and C utilities. A typical 'usbhid-dump' is as follows:
ubuntu:~/respeaker$ sudo usbhid-dump -m 2886:0007 -es libusb: warning [raw_desc_to_config] still 7 bytes of descriptor data left Starting dumping interrupt transfer stream with 1 minute timeout.
002:012:004:STREAM 1493402773.152384 FF FF 03 00
002:012:004:STREAM 1493402773.160130 FF FF 03 00
002:012:004:STREAM 1493402773.168228 FF FF 03 00
002:012:004:STREAM 1493402773.176252 FF FF 03 00
002:012:004:STREAM 1493402773.184438
xiongyihui
I've been working with the mic array on two different ubuntu machines and found that the mic appears to continuously output a partial hid report (the first 4 bytes) of whatever the last output that was sent to the host. For example if an auto report reports a vad event, it will continuously send an empty auto report (as frequently as possible) thereafter: 255, 255, 3, 0, 2, 44, 1, 16, 90, (valid VAD auto report) 255, 255, 3, 0 (every subsequent read results in a 4 byte auto report with no data) 255, 255, 3, 0 255, 255, 3, 0 ...
This occurs no matter if the read is blocking or non-blocking.
Or a read of register 0x3E would result in 62, 128, 1, 0, 208 And all subsequent reads would return a partial 4 byte report. 62, 128, 1, 0 62, 128, 1, 0 62, 128, 1, 0 ...
This occurs when running the c program in respeaker-xmos-hid, the python program (modified to prevent it from crashing due to empty reports), or even just when 'cat'ing /dev/hidraw0 and with both versions of the mic array firmware.
Is this the intended behavior? Or is this a problem with my setup or microphone?