HID and threads WAS: [PD-dev] audio interruptions from outside events (only with Pd)

[Hans-Christoph Steiner]

On Dec 4, 2006, at 3:19 PM, Tim Blechmann wrote:

> On Mon, 2006-12-04 at 14:53 -0500, Hans-Christoph Steiner wrote:
>>
>>> I have no idea about the inner workings of hidio (is there a
>>> separate low-priority thread for handling the HID requests?)
>>
>> This was bugging me so I have to respond to it.  From what I've
>> seen,
>> I think handling HID I/O in a low priority thread would be a bad
>> idea.  Do you know any application that does that?  The effect would
>> be that your mouse pointer would skip whenever something with higher
>> priority was run.  This may be the case on Windows, but definitely
>> not on Mac OS X and GNU/Linux.
>>
>> On Mac OS X, the kernel queues HID events and uses wired kernel
>> memory for the queues to ensure that those events get out there as
>> soon as possible and reliably without a thread.  No example code
>> that
>> I have seen, from Apple or others, puts HID event handling in a
>> thread.  To put it simply: you don't want your mouse pointer to be
>> pre-empted.
>
> well, it depends on how you can query the hid i/o. if the access to  
> the
> hid backend is either blocking or slow, you should think about putting
> the specific code in a thread with a lower priority than the audio
> thread, unless you prefer a smooth mouse movement over audio  
> dropouts :)

[comport] and [hid] both use the standard calls and both do not use  
threads at all, yet neither has problems with blocking I/O (or at  
least no one has been able to make a patch that causes it to  
happen).  I am pretty sure they both use high priority queues in the  
kernel so that return very quickly.

I would be very interested to hear,

a) that someone can reproduce issues with blocking I/O in [comport]  
and/or [hid]

b) what the exact mechanism is with the serial/HID queues that makes  
them not block when using standard calls (I only know some details)

We are deep in the throws of the design discussion for [hidio] so we  
need to define what needs a thread.

.hc

> imo, all non-audio i/o of a low-latency system should should be  
> detached
> from the audio thread to avoid dropouts.
>
> tim
>
> --
> tim at klingt.org    ICQ: 96771783
> http://www.mokabar.tk
>
> All we composers really have to work with is time and sound - and
> sometimes I'm not even sure about sound.
>   Morton Feldman



------------------------------------------------------------------------

All information should be free.  - the hacker ethic