Kernel Streaming, ASIO, WASAPI... and music players (Foobar, JRiver...)

[DDF]

For the curious:
http://archimago.blogspot.com/2015/05/measurements-corning-usb-3-optical.html

 

[DDF]

ASR is not (yet?) in the business of testing audio systems. That is to say, holistically.
The measurements presented here are of a device-under-test, akin to a unit or module test in software.
IMO, it is neither fair nor useful to expect otherwise. However, I'm sure contributions to that effect would be welcomed.

@DDF, the problems you've discussed sound like OS scheduler problems.
It also sounds like you were/are saddled with equipment that is known to be problematic. Maybe only discovered after the fact, but still...
At some point, one might ask "what is my time worth?", and simply research and purchase more appropriate gear.

General purpose OS kernels are wondrously complex beasts!
All the more so considering they're expected to support the zoo of hardware they're interfaced with.

Audio is a soft real-time application: best-effort only, as there are no severe consequences to failure.
AFAIK, glitches have never caused a fatality
To compound this, isochronous usb transfers (audio) are not required to support re-tries upon error detection (CRC checksum failure).
Error correction is not a part of the protocol, although it could conceivably be tacked on (eg: Hamming ECC or similar) at the expense of extra bandwidth consumption and end-point complexity.

Glitches may not be fatal but this PC had me on the ledge a few times.

These issues unfortunately aren't so uncommon (see the archimago post, or even from just today https://www.audiosciencereview.com/...io-grade-usb-2-0-port.7399/page-2#post-172712) Injecting noise on the USB (conducted emissions) would be more a test of the DUTs ability to reject outside impairments than a real system test. I look at it as the same philosophy used in jitter rejection tests already conducted. There's a precedent and a need but I'm definitely being greedy.

I was a very early audio designer for VoIP and had to work out the jitter buffers and handling packet loss from first principles, managing variable latency, priority flags & unscheduled interrupts etc. I'd love to understand more about how USB audio is handled: packet sizes, is the ASIO buffer the only buffer etc. I've read anecdotally that any USB audio data lost would be large enough to have to cause a click, but that depends on the smallest sized packet supported, which I've yet to find, and how the usb interface itself deals with lost packets (ie does xmos interpolate or zero stuff or...?)

 

[pkane]

Glitches may not be fatal but this PC had me on the ledge a few times.

These issues unfortunately aren't so uncommon (see the archimago post, or even from just today https://www.audiosciencereview.com/...io-grade-usb-2-0-port.7399/page-2#post-172712) Injecting noise on the USB (conducted emissions) would be more a test of the DUTs ability to reject outside impairments than a real system test. I look at it as the same philosophy used in jitter rejection tests already conducted. There's a precedent and a need but I'm definitely being greedy.

I was a very early audio designer for VoIP and had to work out the jitter buffers and handling packet loss from first principles, managing variable latency, priority flags & unscheduled interrupts etc. I'd love to understand more about how USB audio is handled: packet sizes, is the ASIO buffer the only buffer etc. I've read anecdotally that any USB audio data lost would be large enough to have to cause a click, but that depends on the smallest sized packet supported, which I've yet to find, and how the usb interface itself deals with lost packets (ie does xmos interpolate or zero stuff or...?)

Look up isochronous USB data transfer protocol. That’s what’s used for most USB audio transmission. USB spec doesn’t, as far as I know, dictate how to deal with lost/corrupted packets. Receiver circuit is responsible for this decision.

 

[dc655321]

I'd love to understand more about how USB audio is handled: packet sizes, is the ASIO buffer the only buffer etc. I've read anecdotally that any USB audio data lost would be large enough to have to cause a click, but that depends on the smallest sized packet supported, which I've yet to find, and how the usb interface itself deals with lost packets (ie does xmos interpolate or zero stuff or...?)

Detection of a CRC mismatch would dictate tossing an entire packet, so several samples would be lost.
Such a discontinuity should certainly be audible.

Not totally up-to-date, but answers to some of your question about host/xmos interactions can be found here - https://www.xmos.com/developer/download/private/USB-Audio-Software-Design-Guide(6.12.6rc0.a).pdf

 

[KSTR]

In-depth USB info, just the right mix between detailed and general description : http://www.usbmadesimple.co.uk/ums_1.htm
USB2 high speed isochronous is max 1024 raw Bytes per packet and max three packets per frame at a 8kHz/125us frame rate which accumulates to the 192Mbit/s (=24Mbytes/s) max data throughput for isochronous. For two 16-bit channels at 44.1kHz the packet size is much smaller and there is only one packet per frame as there are only about 200kBytes/s of raw data to transfer.

The packets are the atomic items and isochronous transfer does not specify how to handle errors and lost packets. But there is at least a general detection starting on the PHY level of the USB chips which handles one logical byte transfer at a time. See for example datasheet of the SMSC USB3290 USB2.0 PHY chip. Note that the actual bits per byte transferred serially on the USB differential data line may vary as the are stuffing bits inserted by the host PHY and removed by the device PHY, these bits are needed to keep the NRZI coding correct so the PHY can extract a clock (a "1" does not change the line state so after 6 "1" symbols a "0" is inserted to keep the line toggling). On the higher levels there is error detection with CRC.

Any error correction is up to the highest level of the USB transfer. This means if the data stream were encoded in such a way that there is redundancy and a point of data is spread largely over time (like in redbook CD) the reciever could recover the occasional lost packet from the remaining ones, at the cost of (much) higher latency. But low and guaranteed latency is a core issue for streamed data and therefore this is never used to my knowledge in audio transfers, also it requires specialized drivers. No way to have this with "class-compliant" mode of operation.

It actually would be interesting to see how different DACs really handle USB errors, this info is really hard to find, so the only way to find out is conducting experiments. I'm thinking about a way to build a small "USB disturbance device" that can be switched on and off and inject the occasional glitch into the transfer (like shorting the D+ and D- line for a microsecond or so) and then look at the audio output.
For example, the RME ASIO driver has a CRC monitor which shows any errors, and there is additional diagnosis the DigiCheck utility software. The Adi-2 Pro interface has special provisions to not get out of realtime sync even with the occasional dropped packet which on the other hand means it must substitute the missing samples with something, most likely it will be zeros. Other DACs might handle that differenty, I currently have two other DACs I might check...

 

[KSTR]

In the context of the main discussion -- claimed sound differences from different audio path implementations and player software -- all the above details on USB etc is pretty much irrelevant.


We have three cases here to consider:

1) The transmission itself is broken (like dropped/corrupted packets, buffer underruns etc), this is trivial. And it is really seldom an issue in the real world, IME. At least not with simple 2-channel playback even if high-res formats.

2) The sample stream reaching the actual DAC chip is *not* correct, not bit-identical to the source data, but we assume a correct transmission. This also is trivial and it not far-fetched that this kind of error can audible (especially resampling). It might be difficult to assert bit-perfect transmission, though. Again, RME devices have a nice built-in check for bit-perfect data with know bit patterns, provided in special bittest .WAVs by RME.

3) The sample stream reaching the actual DAC chip is 100% bit-perfect and free of any transmission errors. I'm tempted to think this should be the normal case for most users when a bit of care is applied. Still it seems that people report sound differences changing from ASIO to WASAPI, from FOOBAR to JRIVER and from FLAC to WAV, sourcing data from HDD vs SSD, what have you, ... yet all of this yields always the same correct input data for the DAC.
So the only way for the analog output to change is a, let's face it, mediocre implementation of the DAC where slightly(!) different patterns of jitter and analog signal quality (of the actual low-level digital link), EMI pollution, and USB supply noise in case of USB, disturb the DAC so much that it puts out significantly different analog waveforms. On top of that we might have slightly different amounts of balancing currents if there is electrical connection of source and DAC grounds which can disturb an incompetent DAC as well (but mostly affects unbalanced cabling as I've shown in an article here on ASR some time ago).
While it is not completely impossible that a) a DAC is that bad at noise rejection and b) a source PC is also very fragile and reacts to minor setup changes (like swapping player software) with actual -- measurable -- significant noise differences on the digital audio interface mechanism used, I would think this really is very far-fetched and without proper measurements and blind listening test the credibility of the majority of these reports is zero.

 

[Deleted member 65]

Tool to analyze your Windows PC - - > https://www.resplendence.com/latencymon

" LatencyMon checks if a system running Windows is suitable for processing real-time audio and other tasks. LatencyMon analyzes the possible causes of buffer underruns by measuring kernel timer latencies and reporting DPC and ISR excecution times as well as hard pagefaults. It will provide a comprehensible report and find the kernel modules and processes responsible for causing audio latencies which result in drop outs. It also provides the functionality of an ISR monitor, DPC monitor and a hard pagefault monitor. "

 

[DDF]

Here are a few DPC latency tools I found very helpful to debug clicks and pops and fix my machine:

DPC latency checker http://www.thesycon.de/eng/latency_check.shtml

• Look for DPC latency spikes. If they coincide with glitches, then next step to dig deeper

Latency Mon http://www.resplendence.com/latencymon

• Use it to find drivers that cause excess dpc latency and focus on fixing these: go to drivers tab, sort under highest execution (ms

Once the problem area is discovered, Latency mon doesn't tell you how to fix it. For that, I found this invaluable, though its trial and error: https://www.cantabilesoftware.com/glitchfree/
For a quicker stab at it:
https://www.sweetwater.com/sweetcare/articles/solving-dpc-latency-issues/?avad=244133_d15bcb8c9
To stop CPU throttling:
https://help.ableton.com/hc/en-us/articles/115000211304

If the smoking gun is still elusive, the following dives into deeper testing:
https://www.resplendence.com/latencymon_idlt

 

[Juicehifi]

Under my watch , we ditched the Windows XP audio pipeline completely for Vista and later. We had very strict performance criteria to not slow down any system with the new pipeline so the algorithms are not state of the art. They are a huge step up from XP though.

Amir,
A question for you ... you were the team leader for the Vista Audio Engine, right?

The real question (with a long intro): The author of “virtual audio cable” - Eugene Muzychenko - who has more knowledge about windows audio in his left little finger than I have overall - was unsuccessful in providing a wasapi implementation with full duplex in exclusive mode (in Portaudio). I tried to do something about it, but I was unable to find documentation about H2 set up one single stream with input and output.

So my question(s): Does such a protocol exist - and where can I get it?

I’m asking as the author of Audiolense. A full duplex exclusive mode wasapi implementation would make my life easier as well as quite a few users.

Ps: I absolutely agree that the Vista audio engine was a big step up. (I’m tempted to say all the way because 32 bit mixing should be safe ground - but then I have a lot of high standard customers that might think differently )

PPS: enjoy your site and very impressed with all the hardware tests and the expertise present.

 

[DDF]

In the context of the main discussion -- claimed sound differences from different audio path implementations and player software -- all the above details on USB etc is pretty much irrelevant.


We have three cases here to consider:

1) The transmission itself is broken (like dropped/corrupted packets, buffer underruns etc), this is trivial. And it is really seldom an issue in the real world, IME. At least not with simple 2-channel playback even if high-res formats.

2) The sample stream reaching the actual DAC chip is *not* correct, not bit-identical to the source data, but we assume a correct transmission. This also is trivial and it not far-fetched that this kind of error can audible (especially resampling). It might be difficult to assert bit-perfect transmission, though. Again, RME devices have a nice built-in check for bit-perfect data with know bit patterns, provided in special bittest .WAVs by RME.

3) The sample stream reaching the actual DAC chip is 100% bit-perfect and free of any transmission errors. I'm tempted to think this should be the normal case for most users when a bit of care is applied. Still it seems that people report sound differences changing from ASIO to WASAPI, from FOOBAR to JRIVER and from FLAC to WAV, sourcing data from HDD vs SSD, what have you, ... yet all of this yields always the same correct input data for the DAC.
So the only way for the analog output to change is a, let's face it, mediocre implementation of the DAC where slightly(!) different patterns of jitter and analog signal quality (of the actual low-level digital link), EMI pollution, and USB supply noise in case of USB, disturb the DAC so much that it puts out significantly different analog waveforms. On top of that we might have slightly different amounts of balancing currents if there is electrical connection of source and DAC grounds which can disturb an incompetent DAC as well (but mostly affects unbalanced cabling as I've shown in an article here on ASR some time ago).
While it is not completely impossible that a) a DAC is that bad at noise rejection and b) a source PC is also very fragile and reacts to minor setup changes (like swapping player software) with actual -- measurable -- significant noise differences on the digital audio interface mechanism used, I would think this really is very far-fetched and without proper measurements and blind listening test the credibility of the majority of these reports is zero.

I think we can all agree that its far fetched that WASAPI vs ASIO vs kernal streaming would make any difference.

My problem on my machine was "1" and while I keep reading that its seldom an issue, it really does rear its ugly head and when it happens on your machine (I was a lucky one), its cold comfort to be told it can be ignored. Because I've suffered it, I've taken the time to research in depth and I've read of many people unfortunately having the issue, even with high powered hardware.

The symptom readily audible is a click or pop but I'd like to be open minded about this and truly understand how small the bit loss could be in time and whether its possible to have much smaller bit losses that aren't readily apparent as clicks and pops. I'm not claiming its possible, but I've read nothing that helps validate this. When I designed early VoIP, there were many opportunities for this found, but it depends on the packet sizes used. I appreciate all for the USB info provided, it confirms there is no opportunity for retransmission, but we're not really any closer to understanding the smallest bit loss that can occur and how various dacs manage them. If it is zero stuffing, that would be nasty.

For #3, what matters is if the eye is distorted enough that the dac can't properly decode. This is standard for any transmission testing of data.

Certainly some dacs will perform better than others and the best solution is to buy a dac that excels at this to help circumvent a noisy PC, but here's the key: there is no public domain testing or information available to help guide a prospective dac purchaser in navigating how different dacs compare in this regards. Not at ASR, not at Stereophile, not anywhere. I keep hearing advice at ASR to not worry about this because the writer's PC is error free but even archimago had all sorts of problems with this, and one could hardly describe him as an uniformed purchaser or a nutty audiophile. I'd like to dig into this more deeply. I'm reading of multiple issues even with focusrite which if I understand it correctly is some of the highest volume usb adc/dac gear sold.

At best we're left with anecdotal reporting. As someone that battled through this, I'm hoping to relay some experiences in how to best manage it when it does occur. IME, USB optical isolators are a significant help though they introduce some jitter impairment (which is probably immaterial for an asynch dac) and I posted some that i found high quality in another thread yesterday.

A great salvation for me was to use a lap top PC with a doubly insulated power brick which removes earth ground and breaks the ground/noise loop right at the source, without any reduction in safety.

For now, the hunt continues regarding how small the bit error could be and how dacs handle it. Thanks for the USB PHy spec, but after a few minutes reviewing, it doesn't seem to answer these questions. BTW I used to be an Ethernet HW designer and I don't think these questions would be answered at the physical layer. Until this is known, everything else is heresay.

 

[edechamps]

The real question (with a long intro): The author of “virtual audio cable” - Eugene Muzychenko - who has more knowledge about windows audio in his left little finger than I have overall - was unsuccessful in providing a wasapi implementation with full duplex in exclusive mode (in Portaudio). I tried to do something about it, but I was unable to find documentation about H2 set up one single stream with input and output.

I'm not sure exactly what you're asking (are you having a problem with Virtual Audio Cable? With PortAudio? With WASAPI in general?), but, just FYI, I strongly suspect there is at least one bug in PortAudio that causes glitches (discontinuities) when using WASAPI Exclusive in full-duplex mode. I might come around to fixing it in PortAudio at some point, but I've been procrastinating on that because the PortAudio codebase is not exactly fun to work with.

 

[Juicehifi]

The devil is in the details. There are a lot of suspect implementations out there that can make a difference- simply because they are out of spec.

 

[Juicehifi]

I'm not sure exactly what you're asking (are you having a problem with Virtual Audio Cable? With PortAudio? With WASAPI in general?), but, just FYI, I strongly suspect there is at least one bug in PortAudio that causes glitches (discontinuities) when using WASAPI Exclusive in full-duplex mode. I might come around to fixing it in PortAudio at some point, but I've been procrastinating on that because the PortAudio codebase is not exactly fun to work with.

Is that you Eugene? I have absolutely no problem with vac, only with pa/wasapi.

 

[pkane]

For now, the hunt continues regarding how small the bit error could be and how dacs handle it. Thanks for the USB PHy spec, but after a few minutes reviewing, it doesn't seem to answer these questions. BTW I used to be an Ethernet HW designer and I don't think these questions would be answered at the physical layer. Until this is known, everything else is heresay.

Not sure what else you are looking for. The protocol specifies a packet size of up to 1024 bytes to be transmitted every 125us. The number of bytes in the frame depends on the number of channels, sampling frequency, and size of samples. In addition, the receiver can request a change in the number of samples to help control buffer overflow/underflow. There's no error recovery in the protocol, just error detection. If an error is detected it's up to the receiver to either throw away the whole frame, or to to do something else, like maybe interpolate the data.

At 44.1k sample rate a frame will normally contain 5 to 6 samples. Throwing this away due to a CRC error will result in a drop-out of about 0.1 msec of audio.

 

[edechamps]

Is that you Eugene? I have absolutely no problem with vac, only with pa/wasapi.

No, I'm not Eugene But I think I understand the problem you're describing since I'm seeing related problems in FlexASIO (which uses PortAudio). As far as I can tell it's a bug in PortAudio and is not a limitation of WASAPI Exclusive, but I'd have to investigate it further to be sure. One thing to keep in mind is that WASAPI itself does not provide a full-duplex interface - it has to be "emulated" by the application (in this case, PortAudio) by opening the render and capture devices separately and synchronizing the buffers manually. This leads to somewhat complicated buffer management logic, which is prone to bugs, and I suspect it's this logic in PortAudio that is faulty - but again, I have not looked into this in detail.

 

[Juicehifi]

I don't think that will work, ed, because two streams will be sharing the same device. But I'd be happy to be proven wrong on that.

 

[exaudio]

@DDF , is your laptop a XPS 15 9570? Apparently there is a known issue that can cause "audio stutters and glitches". Dell just released a BIOS update that is supposed to "reduce Deferred Procedure Call (DPC) latency for real-time task performance enhancement, such as audio playback."

According to notebookcheck.net "some users have reported that the BIOS has reduced audio glitches and ACPI.sys DPC latencies from around a max of 1.7 ms to around 0.6 ms. So, Dell has drastically reduced latency times by bringing them below 1 ms, but they are still above 0.5 ms or quicker, which DPC Latency Checker sets out as being ideal for glitch-free audio playback."

 

[DDF]

@exaudio thanks for this, it really illustrates these issues aren't so completely rare or isolated to broken machines.

My laptop (used for audio only) is much older, a business class Dell Latitude E6420. It works perfectly now. I think when win7 is retired at end of the year, I'll probably convert this over to Linux.

 

[DDF]

Not sure what else you are looking for. The protocol specifies a packet size of up to 1024 bytes to be transmitted every 125us. The number of bytes in the frame depends on the number of channels, sampling frequency, and size of samples. In addition, the receiver can request a change in the number of samples to help control buffer overflow/underflow. There's no error recovery in the protocol, just error detection. If an error is detected it's up to the receiver to either throw away the whole frame, or to to do something else, like maybe interpolate the data.

At 44.1k sample rate a frame will normally contain 5 to 6 samples. Throwing this away due to a CRC error will result in a drop-out of about 0.1 msec of audio.

@pkane, this is very helpful thanks. I went back and looked at my subjective test results for packet loss but they were all with encoded audio so not applicable.

Next task is to investigate possible audible effects with 0.1ms loss. It will depend on the frequency of loss (%) and efficacy of any attempts at filling on the receiver (if done at all). Right now that data is still elusive but I'll keep looking.

 

[KSTR]

@DDF , it seems that you have indeed been one of the few that got bitten. In my experience I don't recall any unstable/glitchy USB2 audio connection with my various setups over the last decade, even with 24/96 8-channel playback for my DIY speakers, convolution-based XO/FR/DRC, running on XP even, bog standard laptops of the day. Also, no problem recording 24 channels 48k/24 live. A poll among ASR member might by nice, if/how often they experience(d) dropouts/glitches with no remedy by simple means like a fresh OS re-install, sizing buffers adequately and keeping USB payload from other devices on the same (internal) HUB channel to a minimum.

As for audibility of glitches/dropouts, you can manipulate some files in a WAV-editor and test that. A ten sample dropout with all zeros will probably go almost unnoticed on a Metallica track, whereas it will be extremely audible when happening on the crests of low-frequency waveforms, espcially when there is no masking mid/treble content.