Click in the nick column to highlight everything a person has said.
The icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

I believe screen estate or so, if it's for the H1x0 though then it may "just" not have been adapted to other screens. IIRC it was from some big recording patches that existed for the Irivers in unsupported builds for a while until petur committed them to main Rockbox

IMO AGC sucks - at least for music recording; you always end up with a lot of compression and pumping artefacts that you can't remove. You get much better results if you record with plenty of headroom and compress afterwards (during playback). So it's not worth the effort (Just my 2 cents :) )

- devices that disappear from global list but are still in reflist could just be marked as "disconnected" and operations on them would always fail and the server would not actually perform the usb operation

you keep one global list of devices (some of them may have been disconnected). Each device has a reference counter: number of clients that hold a reference to it. Each client thread has a local list: this is a list of opened devices. Whener a client opens a device, the thread updates the ref count in the global list and adds it to its local list. whener it closes the device, it unref the global one and delete it from the local list. Now each

ok but now look at such scenario: two clients opened the same device (so ref count is 3 in your scheme), the device got disconnected (ref count drops to 2), now client wants to do something and gets error. It would need to know why it is so to perform internal cleanup and close()

I see it like this: 1) devlist is as now. It is mutex protected and updated by hotplug callback. 2) client builds up a list on opened refs (only refs, no structure copy) and operates on data from devlist (it is mutex protected anyway). 3) ref count is for holding device hwstub_open() ed only when needed.

with my scheme, a device cannot disappear from the list as long as a client has opened it thus, thus any other operation is safe. In other words, the list is race-free for reading if you know the device is opened