We are in the middle of trying to make [hidio] as robust as possible in terms of plugging and unplugging devices. One thing I noticed is that if I have Pd running only a sine wave, then I plug or unplug a USB device, I get an interruption in the sound.
If I do the same thing with Audacity or Max/MSP, there is not interruption in the sound. Any ideas what's the root of this?
.hc
------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
On Mon, 2006-12-04 at 09:30 -0500, Hans-Christoph Steiner wrote:
We are in the middle of trying to make [hidio] as robust as possible in terms of plugging and unplugging devices. One thing I noticed is that if I have Pd running only a sine wave, then I plug or unplug a USB device, I get an interruption in the sound.
If I do the same thing with Audacity or Max/MSP, there is not interruption in the sound. Any ideas what's the root of this?
which os?
tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
The composer makes plans, music laughs. Morton Feldman
On Dec 4, 2006, at 9:38 AM, Tim Blechmann wrote:
On Mon, 2006-12-04 at 09:30 -0500, Hans-Christoph Steiner wrote:
We are in the middle of trying to make [hidio] as robust as possible in terms of plugging and unplugging devices. One thing I noticed is that if I have Pd running only a sine wave, then I plug or unplug a USB device, I get an interruption in the sound.
If I do the same thing with Audacity or Max/MSP, there is not interruption in the sound. Any ideas what's the root of this?
which os?
Mac OS X 10.4.8
.hc
------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
Am 04.12.2006 um 15:30 schrieb Hans-Christoph Steiner:
We are in the middle of trying to make [hidio] as robust as possible in terms of plugging and unplugging devices. One thing I noticed is that if I have Pd running only a sine wave, then I plug or unplug a USB device, I get an interruption in the sound.
If I do the same thing with Audacity or Max/MSP, there is not interruption in the sound. Any ideas what's the root of this?
I have no idea about the inner workings of hidio (is there a separate low-priority thread for handling the HID requests?), but Max/MSP has a different thread for DSP processing, and messaging is split into high and low-priority tasks.
best greetings, Thomas
-- Thomas Grill http://grrrr.org
On Dec 4, 2006, at 10:38 AM, Thomas Grill wrote:
Am 04.12.2006 um 15:30 schrieb Hans-Christoph Steiner:
We are in the middle of trying to make [hidio] as robust as possible in terms of plugging and unplugging devices. One thing I noticed is that if I have Pd running only a sine wave, then I plug or unplug a USB device, I get an interruption in the sound.
If I do the same thing with Audacity or Max/MSP, there is not interruption in the sound. Any ideas what's the root of this?
I have no idea about the inner workings of hidio (is there a separate low-priority thread for handling the HID requests?), but Max/MSP has a different thread for DSP processing, and messaging is split into high and low-priority tasks.
"running only a sine wave", meaning the only patch that Pd is running is:
[osc~ 333] | \ [dac~]
So, nothing to do with [hidio] here. Nor does it have anything to do with high or low priority Max messages since no messages are involved.
.hc
------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On Dec 4, 2006, at 10:38 AM, Thomas Grill wrote:
Am 04.12.2006 um 15:30 schrieb Hans-Christoph Steiner:
We are in the middle of trying to make [hidio] as robust as possible in terms of plugging and unplugging devices. One thing I noticed is that if I have Pd running only a sine wave, then I plug or unplug a USB device, I get an interruption in the sound.
If I do the same thing with Audacity or Max/MSP, there is not interruption in the sound. Any ideas what's the root of this?
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.
.hc
but Max/MSP has a different thread for DSP processing, and messaging is split into high and low-priority tasks.
best greetings, Thomas
-- Thomas Grill http://grrrr.org
------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
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@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
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@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
hi hans,
[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.
after having a brief look at the hidio sources, you seem to use a mutex for synchronization with a child thread ... this is basically not save and may lead to audio dropouts, when running with low latencies. i know, miller's portaudio implementation is not able to run under low latencies, but the callback scheduler of devel is able to do so...
cheers ... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
There's no such entity as "most people". These are generalities. All generalities are meaningless. You've got to pin it down to a specific person doing a specific thing at a specific time and space. William S. Burroughs
On Dec 4, 2006, at 4:55 PM, Tim Blechmann wrote:
hi hans,
[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.
after having a brief look at the hidio sources, you seem to use a mutex for synchronization with a child thread ... this is basically not save and may lead to audio dropouts, when running with low latencies. i know, miller's portaudio implementation is not able to run under low latencies, but the callback scheduler of devel is able to do so...
We are currently in the discussion of how to use threads in externals/ io/hidio, so we are testing various configurations, so this is probably going to change drastically. (one hidio author that shall remain unnamed prefers to avoid this list for understandable but unfortunate reasons).
How would you handle this particular situation?
.hc
------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
after having a brief look at the hidio sources, you seem to use a mutex for synchronization with a child thread ... this is basically not save and may lead to audio dropouts, when running with low latencies. i know, miller's portaudio implementation is not able to run under low latencies, but the callback scheduler of devel is able to do so...
We are currently in the discussion of how to use threads in externals/ io/hidio, so we are testing various configurations, so this is probably going to change drastically. (one hidio author that shall remain unnamed prefers to avoid this list for understandable but unfortunate reasons).
How would you handle this particular situation?
well, devel contains some data structures to provide lockfree synchronization, which vanilla is lacking. but since other technical problems don't allow vanilla to run with low latencies, i wouldn't really care about vanilla.
however, if you use thomas's flext framework, you won't really have to deal with the threading problems, since he wrapped both vanilla's and devel's api into flext, so no need to deal with it separately. beside that, the max-port doesn't require 17 ifdefs ;)
cheers ... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Every word is like an unnecessary stain on silence and nothingness Samuel Beckett
-
Hans-Christoph Steiner -
Thomas Grill -
Tim Blechmann