This problem occurs on IMacs and Macbook Pros as well as Windows. The Apple products need no driver as they have the industry standard driver already in place. The CD that comes with the HDVD800 has drivers (or a driver) for the Windows applications. The issue is, if you are getting music of any kind coming out of the DAC then the USB is successfully getting the audio data to the DAC.
I believe that there are two main data transfer methods defined in the USB Audio class 2 standard. The first, which has been around for many years is a synchronous mode (called Adaptive mode). To transfer each 24 bit sample (actually 48 bits for both channels) of the 24/192 audio file, the PC must just spit out the stream of sample data chunks onto the USB at exactly 192 kHz and spaced at EXACTLY EQUAL spacing. The DAC simply sits and grabs each sample as it comes in and loads them into the converter. It also uses the timing of the incoming samples to reproduce the clock that they were send with. The clock is used when inserting the converted digital value into the analog output signal. Problem is that PCs (and other transports) have a problem spacing the data samples in EXACTLY EQUAL spacing. As a result the clock jumps around a not positioning the digital converted to analog value in the exact correct place in the output signal. This is jitter, and on highly resolving systems its effects can be heard (soundstage reduction, less clarity, and other artifacts)
Note that this is also very much the same way that the S/PDIF interfaces work (e.g., TOSLink, Coax) in that the device sending the data is using its own clock for sending and then the receiving item has to recreate the clock in order to to the conversions
The second transfer method is asynchronous and is (guess what?) called Asynchronous transfer mode. It is relatively new and hasn't been around a long time. Older DACs with USB interfaces may not even support this mode. There is going to be more overhead with this in that the DAC now using its own internal clock says to itself "it's about time to get some more samples" so it sends a message to the PC requesting the data. The PC puts a batch of samples together and sends it to the DAC. Since the DAC is using it's own high grade internal clock, it can sit there an easily do the conversion on each sample and put them into the exactly correct place in the output analog signal. No incoming jitter to worry about at all.
The problem is that it appears the appearance of this bug seems to be when worst case load conditions on the DAC's processor are occurring. E.g., 24/192 kHz tracks, software that bypasses all of the generic audio processing of the OS (i.e., is fast), and the additional USB overhead in the DAC associated with Asynchronous transfer mode.
If you have an older sound card or USB driver, you might not be able to even use Asynchronous transfer mode. If not, I don't think that you would even be able to trigger the bug. However, you also would not be able to talk to the DAC in a jitter free fashion as well. If you have the ability to run in Async mode, then you would normally want to do that.
All that is happening is that each sample on the digital data for the audio file is pulled from the file and sent out on the USB connection. If the data got lost or was modified somehow, you would get terrible noises, not hiss.
And the last item is that USB Audio class 2 is defined by international standard so if you only get hiss when talking with an HDVD800 through a given USB driver but you DON'T get hiss on other DAC products using the same driver, it would make sense that the problem in the the DAC's processing.
Oh dear. It just occurred to me that this was probably all talked about in the forums' Wiki. Hope this clarified things a bit though