H9000, USB, and Deterministic Latency

Home Forums Products Rackmount H9000, USB, and Deterministic Latency

Tagged: , ,

  • This topic is empty.
Viewing 2 reply threads
  • Author
    Posts
    • #115479
      Chuck Zwicky
      Moderator

      H9000, USB, and Deterministic Latency:

      I was hoping to incorporate the H9000 into my hybrid mixing environment by using it’s USB audio interface capability in addition to my existing hardware I/O, because at the moment I have no spare analog I/O channels  to patch it into my interface setup. Unfortunately I discovered that  when using the H9000 as a USB interface, system latency is not consistent nor deterministic and does not remain the same after reboot, or when changing sample rates.

      To test this I used the hardware I/O plugin in Logic Pro, which when inserted in a channel strip allows you to route the signal out to a hardware interface and back in to the DAW,  This plugin has a “ping” button which sends out a single sample impulse to determine the latency of the interface, and it compensates the insert by that amount,  The latency of my main I/O system is absolutely consistent and reliable, regardless of reboots or sample rate changes.  Using the H9000 as a USB audio interface or adding it to my existing (48 I/O) interface in OSX as an “aggregate device”  causes the latency of both interface systems to be unpredictable.

      In other words, if I use my hardware signal processing in a channel insert and “ping” the latency, this offset value, which is stored with the DAW project for each insert, will no longer be accurate after re-booting (as is necessary for doing any recalls on a single project over an extended period of time), or when changing sample rates (as you might when loading different projects into the DAW).  This is a disaster when using outboard gear in any sort of parallel processing.

      I tested both the aggregate device and the H9000 on it’s own.  In both cases the latency was indeterminate.  When using the H9000 by itself as the sole Audio I/O interface and setting the H9000 to “Bypass” for straight “E to E” connectivity, I routed the audio out Ch1 and back into Ch1 on the Logic Pro I/O plugin, and pressed “ping”, noting the reported latency,  I then re-initializing “core audio” by toggling the “core audio” tick box in the preferences, and selected the  “apply changes” button, the I/O plugin reported the following latencies in the first 4 trials: 55 samples, 57 samples, 67 samples, 72 samples. All tests were done with an audio buffer setting in Logic Pro of 1024 samples.

      When using the aggregate device (in this case a test setup combining a UA Apollo FW interface with the H9000 USB interface) the latency of the Apollo had similar disparity. On it’s own it reports a latency of “0” samples – reliably – but in the aggregate device with the H9000 the latency numbers are the same as on the H9000 when used alone.

      I realize that this is likely an inherent USB issue, and this behavior is present in other USB audio interfaces I have tested, but I hope that you might be able to address this, as Apogee did when their earlier FireWire interfaces had this same issue in OSX, and by installing their “ensemble” driver it re-wrote the OSX FireWire driver and fixed this latecy issue.

      I spoke to an engineer that claimed the USB latency problem can be solved by initially reporting the device as a “fax machine” or some very low priority device and then 10ms later reporting it as the interface. I hope you can figure this out once and for all..  otherwise I will need to add another converter box to my system just to have enough I/O to be able to use the H9000 without affecting the system latency.

       

    • #152574
      Chuck Zwicky wrote:

      H9000, USB, and Deterministic Latency:

      I was hoping to incorporate the H9000 into my hybrid mixing environment by using it’s USB audio interface capability in addition to my existing hardware I/O, because at the moment I have no spare analog I/O channels  to patch it into my interface setup. Unfortunately I discovered that  when using the H9000 as a USB interface, system latency is not consistent nor deterministic and does not remain the same after reboot, or when changing sample rates.

      To test this I used the hardware I/O plugin in Logic Pro, which when inserted in a channel strip allows you to route the signal out to a hardware interface and back in to the DAW,  This plugin has a “ping” button which sends out a single sample impulse to determine the latency of the interface, and it compensates the insert by that amount,  The latency of my main I/O system is absolutely consistent and reliable, regardless of reboots or sample rate changes.  Using the H9000 as a USB audio interface or adding it to my existing (48 I/O) interface in OSX as an “aggregate device”  causes the latency of both interface systems to be unpredictable.

      In other words, if I use my hardware signal processing in a channel insert and “ping” the latency, this offset value, which is stored with the DAW project for each insert, will no longer be accurate after re-booting (as is necessary for doing any recalls on a single project over an extended period of time), or when changing sample rates (as you might when loading different projects into the DAW).  This is a disaster when using outboard gear in any sort of parallel processing.

      I tested both the aggregate device and the H9000 on it’s own.  In both cases the latency was indeterminate.  When using the H9000 by itself as the sole Audio I/O interface and setting the H9000 to “Bypass” for straight “E to E” connectivity, I routed the audio out Ch1 and back into Ch1 on the Logic Pro I/O plugin, and pressed “ping”, noting the reported latency,  I then re-initializing “core audio” by toggling the “core audio” tick box in the preferences, and selected the  “apply changes” button, the I/O plugin reported the following latencies in the first 4 trials: 55 samples, 57 samples, 67 samples, 72 samples. All tests were done with an audio buffer setting in Logic Pro of 1024 samples.

      When using the aggregate device (in this case a test setup combining a UA Apollo FW interface with the H9000 USB interface) the latency of the Apollo had similar disparity. On it’s own it reports a latency of “0” samples – reliably – but in the aggregate device with the H9000 the latency numbers are the same as on the H9000 when used alone.

      I realize that this is likely an inherent USB issue, and this behavior is present in other USB audio interfaces I have tested, but I hope that you might be able to address this, as Apogee did when their earlier FireWire interfaces had this same issue in OSX, and by installing their “ensemble” driver it re-wrote the OSX FireWire driver and fixed this latecy issue.

      I spoke to an engineer that claimed the USB latency problem can be solved by initially reporting the device as a “fax machine” or some very low priority device and then 10ms later reporting it as the interface. I hope you can figure this out once and for all..  otherwise I will need to add another converter box to my system just to have enough I/O to be able to use the H9000 without affecting the system latency.

       

      what’s the Round Trip Latency are you getting when using the usb port of the h9000 alone?
      is it too much?
      thanks,
      p.

    • #152575
      jbamberg
      Moderator
      Eventide Staff

      Hi Chuck,

      Thanks for the detailed report.  We'll look into this.  There's nothing inherent in USB that should cause this, but my colleague says he's seen reports of inconsistent latency with various USB devices.  I will keep you posted.

      Joe

    • #152578
      Chuck Zwicky
      Moderator
      jbamberg wrote:

      Hi Chuck,

      Thanks for the detailed report.  We’ll look into this.  There’s nothing inherent in USB that should cause this, but my colleague says he’s seen reports of inconsistent latency with various USB devices.  I will keep you posted.

      Joe

       

      Thanks for the reply, Joe.  I have tested several USB audio interfaces that exhibit this behavior.  It would be fantastic if you were able to solve this one.   I saw in a different thread here that you are using asynchronous USB, which theoretically should be less problematic, but as you can see, it isn’t.

      Please let me know if you need any more information in replicating this test (and please feel free to move this to a beta forum if this topic is’n’t suitable for general consumption).

       

      -Chuck

Viewing 2 reply threads
  • You must be logged in to reply to this topic.