HID controller thread hangs randomly on Windows
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Triaged
|
Medium
|
Unassigned |
Bug Description
Hi
This is a problem i have seen/suffered since some months, first with a Hercules Dj Control MP3 and now with a Gemini G2V (always on windows environment, w7 or greater, both x86 and x64), and it's a random loss of the controller (Mixxx works fine, but controller seems off, no input or output, and hangs at Mixxx exit waiting for the controller thread to stop)
To keep things simple, what i think i've found looking at the source and doing my own tests, is that you can't (with lastest hidapi and Mixxx 1.12 from two days ago) send and retrieve data at the same time from a HID controller (under windows, at least!). Removing the hid_write() calls the code doesn't hangs ever (or so it seems).
The call to hid_read_timeout(), at least in windows, seems to return almost immediatly, this generates also a lot of traffic for the mapping script (incomingData unnecessary calls).
So i have done some changes on HidReader::run() to work around this:
-The first thing is to make a copy of the incoming data, to see if the next call is any different. If not, don't emit incomingData signal.
-Next, put a simple mutex to control access to the HID device: on the HidReader, i modify a variable while reading, and before calling hid_write(), i look up if i can or not. If i cannot i simply "drop" the packet (output is not as "vital").
With those changes, i could see that the hid_write call doesn't get a lot of opportunities to run (almost none), because the hid_read_timeout() call returns inmediatly on a continous loop.
So, i put a little usleep(1) after hid_read_timeout().
With those changes, debug build and all, seems to go fine (i have still to test it more time, but have sense): low latency, responsive, 20-30% cpu while performing... good! :). And as it doesn't hang, Mixxx can quit just fine.
The controller thread is shared between midi and HID devices, that explains why when i was using both at the same time (nanokontrol with midi and hercules with hid), i will always lost both at the same time.
I don't know if it's an issue with hidapi on windows (i would think so if it's not a know problem), but with those changes seems workable from the outside.
I also don't know much about multithread programming, so probably my workaround it's not the best for this case ;)
PS1: I'm doing now a HID mapping for the G2V, and because it has 4 vumeters, generates more feedback/output than the old Hercules, so now the probabilty of locks is worst than ever. This bug happens equally on 1.11 and 1.12.
PS2: I have posted about this on the forums some months ago : http://
Well, after those changes, it has been autodj'ing for almost 7 hours with no problems (i have stopped the test :) ).... more than 578k packets sent (i only send when data changes), and 817 dropped ones (so, 817 possibly chances to hang "saved"). I don't count the incoming ones, but should be almost two orders of magnitude greater.