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

[Tim Blechmann]

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 :)

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20061204/c58b720e/attachment.pgp>