• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

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

DDF

Addicted to Fun and Learning
Joined
Dec 31, 2018
Messages
617
Likes
1,355
Perhaps you would like to present some actual measurement evidence of the issue of degraded DAC performance with various PCs/DACs?

If it would be of true general interest, I'd consider it. I'd have to reproduce the set up but am working long hours right now. I've been looking for an opportunity to post my Nuprime and irdac measures for weeks. The only reason I can see to do it now is to satisfy your apparently closed and derogatory mind (really, you think I'm making this up, really? Insulting much?). But that's not reason enough, sorry.
 

March Audio

Master Contributor
Audio Company
Joined
Mar 1, 2016
Messages
6,378
Likes
9,317
Location
Albany Western Australia
If it would be of true general interest, I'd consider it. I'd have to reproduce the set up but am working long hours right now. I've been looking for an opportunity to post my Nuprime and irdac measures for weeks. The only reason I can see to do it now is to satisfy your apparently closed and derogatory mind (really, you think I'm making this up, really? Insulting much?). But that's not reason enough, sorry.
Sorry but your response is ridiculous. From the off I acknowledged the potential issues with ground loops. However your glitching computer USB issues (non internet streaming) are not in any way normal. Special measures are simply not required to successfully stream audio over USB. If you are having an issue it is something odd with your PC/DAC/drivers.

So if you are claiming that significant sound quality differences are created with decent quality DACs and different PCs then please show it with some measurements. This forum is about fact, not here say.
 
Last edited:

DDF

Addicted to Fun and Learning
Joined
Dec 31, 2018
Messages
617
Likes
1,355
This forum is about fact, not here say.

You already acknowledged ground loops and I accepted that but you want a measurement of the noise it causes, after acknowledging it? Really? Does that make any sense?

Or do you want a measurement of a drop out? I assume you know what that looks like on a graph?

I'm saying stock normal pc's and dacs can have compatibility issues leading to
a) noise issues that could be from ground loops or susceptibility. Is this really hearsay? How much electronics design experience do you really have if you think so?
b) drop outs. I stated my examples and those of others. The internet is littered with this. Why is it so hard to believe?

What I don't know and what I think would be a genuine useful conversation is how pc audio handles individual bit errors. I know USB can use CRC detection but not correction (as opposed to CD which can correct with its CRC). It would be interesting to have a real technical conversation to explore this further but no responses from anyone yet. I'm seriously interested and not claiming anything in this regards but feel that would be a conversation worth having

Instead I just receive your insulting baseless allegations that I'm lying even though you've barely touched on any of my salient points and then have the gall to state this forum is about "facts"? Give me a break.
 

DKT88

Active Member
Joined
Feb 26, 2019
Messages
221
Likes
232
Location
South Korea
I don't think the situation is so cut and dried as often reported.

To add an alternative experience, my Dell laptop to a Nuprime DAC-10H (measurements to be posted soon, no issues found with the DAC in standard testing) had audible problems with the stock power supply on the PC, fixed with a change to 2 prong insulated supply. Symptom wasn't a standard drop out but just bad grit. You could hear modulating noise at the teeter, sometimes higher, sometimes lower. Audible blind in 10/10 tests tried.

Bit errors remained even after this fix when streaming but only streaming over Spotify or especially Tidal. My high speed access is rock solid and very fast. Rectifying this took many hours of trial and error but ultimately was found by pushing out every single auto update in the Windows scheduler to 3 am. Reasonable i5 machine completely stripped down and highly optimized for W7 audio, though with small RAM (4G).

This publication was a life saver in making the system drop out free. Walking through these steps incrementally improved the situation.
https://www.cantabilesoftware.com/glitchfree/

Audio problems over windows are quite common for music creators.

I'd like to see more information on how dacs resolve bit errors. I understand asynch can request resends but information regarding packet sizes, and any interpolation or correction schemes would be very valuable to truly understand the situation and not rely on anecdotal conjecture.

BTW I was one of the early audio designers on VoIP and understand how bit errors can occur, how to avoid them and concepts used in correction very well but lack information on how standard dac chips deal with this.
Are you using an older laptop with Windows 7? Its been about 7 years since I used 7 with audio but I vaguely recall some audio issues issues with soundcards that may have been related to Speedstep and C1E settings.
 

KSTR

Major Contributor
Joined
Sep 6, 2018
Messages
2,690
Likes
6,013
Location
Berlin, Germany
There are dac design methods to help circumvent the noise related problems but I think to call those "dac" issues is placing all the blame in one area when its really a system level compatability issue. Its expensive and difficult to design for this sort of robustness.

As I said, Asr tests wont catch these issues because these tests dont inject the sorts of pc impairments that some dacs can reject while others struggle more with. As I mentioned earlier, I measured this dac (using a different pc and test measurement interface similar to how amir would test) and the outcome was stellar.

The point is, even outside the windows issues, Pcs can be awfully noisy and hard for dacs to live with. ASR type tests do nothing to measure this as no immunity or susceptbility type tests are conducted, tests that are standard indicators of data path reliability and bit error rate in other industries (eg gr63, gr1089 etc).
Those are all good points I do agree with. Currently, the tests Amir runs are more sort of benign noise conditions for the DUTs, not always very well controlled but still with a resonable baseline. Therefore the DUTs might typically measure better than they would in specific setups that has a much higher noise and disturbance levels. OTOH, with even lower and better controlled noise conditions some DUTs may again fare better than they did in Amir's standard setup.

I certainly adhere to the idea that it would be nice to have at least two sets of measurement, one with lowest noise levels possible to show the top quality limit, and second one with well controlled siginificant levels of added various types of noise and disturbance, for a repeatable additional data point what to expect in a high-noise environment. And maybe a third round with "a typical real-world disturbance setup" whatever that may be if we could actually agree on a set of specs for this.

A full-blown high-noise test would require a large, complicated and exensive set of gear, setup and documentation and we cannot simply put that on top of Amir's already highly loaded shoulders. But we ASR members can add example data points for real-world signal integrity issues and the format to present them here is measurements and their interpretation, preferably with a minimum amount of documentation and general control.

The low-noise best-case setup is more readily achieved. I'd suggest to always use Intona isolators or the like for USB, power the DUT and measurement rig as much decoupled from one another to control balancing currents, ideally battery supplies for everything or at least specialized low leakage, low coupling mains supplies), shield the whole setup and control cable and ground layout to minimize magnetic pickup loops etc, use quality cables/connectors, all the typical measures taken in any controlled high signal-integrity system setup for DUT measurement and characterization.
 

DDF

Addicted to Fun and Learning
Joined
Dec 31, 2018
Messages
617
Likes
1,355
Are you using an older laptop with Windows 7? Its been about 7 years since I used 7 with audio but I vaguely recall some audio issues issues with soundcards that may have been related to Speedstep and C1E settings.

Indeed it is, thanks for suggesting this. I had earlier disabled speedstep (in the bios iirc) and it helped. The 3 largest contributors to improvement were disabling cpu throttling, turning off all low power modes and then, finally, moving all auto update or system administrstive scheduling tasks to 3am. This last one came about because the latency tests were showing issues with the lan interface even though wifi was disabled and i had run a wired connection to a commited1G port on the router. The lan was often very busy with the system doing adminstrative tasks. The system became completely drop out free when streaming but only after these changes. Driver updates had no notable effects.
 

DDF

Addicted to Fun and Learning
Joined
Dec 31, 2018
Messages
617
Likes
1,355
Those are all good points I do agree with. Currently, the tests Amir runs are more sort of benign noise conditions for the DUTs, not always very well controlled but still with a resonable baseline. Therefore the DUTs might typically measure better than they would in specific setups that has a much higher noise and disturbance levels. OTOH, with even lower and better controlled noise conditions some DUTs may again fare better than they did in Amir's standard setup.

I certainly adhere to the idea that it would be nice to have at least two sets of measurement, one with lowest noise levels possible to show the top quality limit, and second one with well controlled siginificant levels of added various types of noise and disturbance, for a repeatable additional data point what to expect in a high-noise environment. And maybe a third round with "a typical real-world disturbance setup" whatever that may be if we could actually agree on a set of specs for this.

A full-blown high-noise test would require a large, complicated and exensive set of gear, setup and documentation and we cannot simply put that on top of Amir's already highly loaded shoulders. But we ASR members can add example data points for real-world signal integrity issues and the format to present them here is measurements and their interpretation, preferably with a minimum amount of documentation and general control.

The low-noise best-case setup is more readily achieved. I'd suggest to always use Intona isolators or the like for USB, power the DUT and measurement rig as much decoupled from one another to control balancing currents, ideally battery supplies for everything or at least specialized low leakage, low coupling mains supplies), shield the whole setup and control cable and ground layout to minimize magnetic pickup loops etc, use quality cables/connectors, all the typical measures taken in any controlled high signal-integrity system setup for DUT measurement and characterization.

Thanks for your thoughtful reply. I agree as well. I think a more valuable indicator of the difference between dacs would be their sinad with a controlled "dirty" usb/pc source, vs the current emphasis on sinad at levels so far below full scale that differences are probably inaudible.

The current tests are conducted to suss out engineering excellence but I think it focuses on the lesser of engineering evils, though its still necessary and very helpful for finding surprising gross violations of basic thd or noise.

I think the engineering excellence put into ground isolation, and immunity from conducted and radiated emmissions would be equally or more valuable indicators of possible audio differences.
 

Ron Texas

Master Contributor
Joined
Jun 10, 2018
Messages
6,078
Likes
8,916
It's funny what does and what does not make a difference, and how audiophiles obsess over what does not make a difference. In some forums there are long threads of "I want to upgrade my cables, $500 budget" with most posts making serious recommendations.

There is often an explanation other than the superiority of A over B that isn't disclosed. I swapped out one solid state amp for another and heard an obvious difference in the bass right away. The undisclosed explanation was the first amp was over 20 years old and most likely needed to be recapped. Yeah, eventually the second amp died.
 

Shadrach

Addicted to Fun and Learning
Joined
Feb 24, 2019
Messages
662
Likes
947
I haven't read all the posts.
I've been messing about with file based audio since Windows 95. I've had a few problems.
Drop outs have been the most irritating. Sometimes its been buffer over run; I've had AISO4all crash, pops and clicks audible through dacs,
underpowered USB hubs, packet errors, audible distortion at the speakers from noise generated at the computer.
So yes, I agree, there can be issues.
Things improved with USB 2. Things improved with asynchronous dacs. Things improve with galvanic isolation.
Mostly things improved when I stopped trying to use an underpowered machine to do all the usual stuff and play music files.
However, I have never noticed a deterioration in sound quality; extra sounds that shouldn't be there and not generated by the data in the file, yes.
It is true that sending audio from WDM drivers to a dac is a trivial task for just about any computer.
However, ask that computer to do numerous other tasks and things get more complicated. One only needs to have an application that shows CPU usage to see this. USB data transfer unless otherwise specified gets treated the same as any other request. It was (hyper threading and multiple cores may have changed this now) a 'computer' did one task at a time; not lots of tasks at the same time. They just got faster at doing that one task.
Everything that the CPU has to manage gets a time slot and waits its turn. The less the computer has to do the more it can concentrate on the audio bit.
Modern computers shouldn't have any of these problems and neither should well design dacs.
 
OP
daftcombo

daftcombo

Major Contributor
Forum Donor
Joined
Feb 5, 2019
Messages
3,687
Likes
4,068
I haven't read all the posts.
I've been messing about with file based audio since Windows 95. I've had a few problems.
Drop outs have been the most irritating. Sometimes its been buffer over run; I've had AISO4all crash, pops and clicks audible through dacs,
underpowered USB hubs, packet errors, audible distortion at the speakers from noise generated at the computer.
So yes, I agree, there can be issues.
Things improved with USB 2. Things improved with asynchronous dacs. Things improve with galvanic isolation.
Mostly things improved when I stopped trying to use an underpowered machine to do all the usual stuff and play music files.
However, I have never noticed a deterioration in sound quality; extra sounds that shouldn't be there and not generated by the data in the file, yes.
It is true that sending audio from WDM drivers to a dac is a trivial task for just about any computer.
However, ask that computer to do numerous other tasks and things get more complicated. One only needs to have an application that shows CPU usage to see this. USB data transfer unless otherwise specified gets treated the same as any other request. It was (hyper threading and multiple cores may have changed this now) a 'computer' did one task at a time; not lots of tasks at the same time. They just got faster at doing that one task.
Everything that the CPU has to manage gets a time slot and waits its turn. The less the computer has to do the more it can concentrate on the audio bit.
Modern computers shouldn't have any of these problems and neither should well design dacs.

What about desactivating the antivirus or windows defender for your digital player?
Solved all clics & pops problems for me.
 
OP
daftcombo

daftcombo

Major Contributor
Forum Donor
Joined
Feb 5, 2019
Messages
3,687
Likes
4,068
Changing to 24 bit did not help me.

In Foobar2000, there is also "WASAPI (push)". Did you try that?

Actually, changing from 32bits (float) to 24bits didn't make my soundcard work under Wasapi, but prevented Foobar from crashing. Which is slightly better!
I cannot run my soundcard with WASAPI.
 

dc655321

Major Contributor
Joined
Mar 4, 2018
Messages
1,597
Likes
2,235
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.
 

Shadrach

Addicted to Fun and Learning
Joined
Feb 24, 2019
Messages
662
Likes
947
What about desactivating the antivirus or windows defender for your digital player?
Solved all clics & pops problems for me.
Oh, I don't have these problems any more.:)

I only posted to illustrate that problems do in fact exist and I've had some of them in the past.
I stopped using Windows. That solved an awful lot of problems.:p
All my machines are Linux now and if I use them for music replay they don't get connected to the Internet.
 

Ron Texas

Master Contributor
Joined
Jun 10, 2018
Messages
6,078
Likes
8,916
In Foobar2000, there is also "WASAPI (push)". Did you try that?

Actually, changing from 32bits (float) to 24bits didn't make my soundcard work under Wasapi, but prevented Foobar from crashing. Which is slightly better!
I cannot run my soundcard with WASAPI.
Push works and is mostly what I use. Event is supposed to be better, but there is probably no difference in sound. Installing drivers allows event to be used. Toslink works with event, the problem is only USB Class 2 on Win 10. This is typical of the Foobar universe. The program itself is very well done and glitch free, but some of the optional third party components have bugs. The VST wrapper has stability issues. Facets does not work with a Synaptic touchpad.
 

Shadrach

Addicted to Fun and Learning
Joined
Feb 24, 2019
Messages
662
Likes
947
Push works and is mostly what I use. Event is supposed to be better, but there is probably no difference in sound. Installing drivers allows event to be used. Toslink works with event, the problem is only USB Class 2 on Win 10. This is typical of the Foobar universe. The program itself is very well done and glitch free, but some of the optional third party components have bugs. The VST wrapper has stability issues. Facets does not work with a Synaptic touchpad.
I don't know how comfortable you are with computers, but if you can install an operating system, then a lightweight Linux system set up on a partition (It is fairly easy to do) would let you try out other options without destroying you current Windows OS.
You really shouldn't need to mess about with audio stack wraps and system optimisations these days given how many people use computers for video and audio.
 

Shadrach

Addicted to Fun and Learning
Joined
Feb 24, 2019
Messages
662
Likes
947
Push works and is mostly what I use. Event is supposed to be better, but there is probably no difference in sound. Installing drivers allows event to be used. Toslink works with event, the problem is only USB Class 2 on Win 10. This is typical of the Foobar universe. The program itself is very well done and glitch free, but some of the optional third party components have bugs. The VST wrapper has stability issues. Facets does not work with a Synaptic touchpad.
In fact, there are Linux systems that will run from a USB stick that you just unplug when you're done so you don't even need to make a full install on your hard drive.
 

Shadrach

Addicted to Fun and Learning
Joined
Feb 24, 2019
Messages
662
Likes
947
Push works and is mostly what I use. Event is supposed to be better, but there is probably no difference in sound. Installing drivers allows event to be used. Toslink works with event, the problem is only USB Class 2 on Win 10. This is typical of the Foobar universe. The program itself is very well done and glitch free, but some of the optional third party components have bugs. The VST wrapper has stability issues. Facets does not work with a Synaptic touchpad.
Have a look at this.
http://puppylinux.com/
It comes with a very good audio player called DeadBeef.
It will all run from a USB stick.
 

Tks

Major Contributor
Joined
Apr 1, 2019
Messages
3,221
Likes
5,494
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.


Pretty much this, add to oddities between motherboard configurations with respect to how CPU governors function through various CPU SKU's, and power-managment profiles (and how this all relates to RAM timings, HDD/SSD activity etc...) things like a sudden hiccup or glitch (cut-off) of audio for a split second isn't weird with respect to USB buses and such (more so when other demanding tasks are run on the system, or I/O is simply being saturated with activity).

Aside from that, I doubt anything of a sonic nature is ever really changing. Just sometimes an intermittent drop-out for a fraction of a second as I mentioned prior.
 
Top Bottom