DC-1

[KeithL]

The DC-1 has an asynchronous USB interface - which means that the clocking of the USB packets is controlled by the DC-1.
In general, asynchronous USB interfaces are immune to packet variations and jitter (since they re-clock the data at the input anyway).
Also, since the DC-1 is AC powered, it doesn't rely on the DC power coming from the computer via the USB cable to power it.

The Schiit Wyrd is a USB repeater (hub), which means that it reclocks the data packets.
It also filters the USB power to some degree.
Schiit, as usual, avoids making unreasonable specific claims

As far as I know the USB Regen (if you're referring to the product of that name - the Uptone USB Regen) is also simply a USB data packet reclocker.
Uptone specifically claims that the packet cadence is able to adversely affect the data after the packets are converted.
(They insist that, if the packets timing is off, it introduces noise into the receiver circuitry, and so compromises its performance.)

The reality is that neither of these devices SHOULD make any audible difference whatsoever if the DAC is doing its job correctly.
Assuming that the asynch USB input re-clocks the data correctly, then any noise or timing errors in the USB packets are irrelevant.
Likewise, assuming that the DACs power supply is doing its job correctly, then noise on the USB power shouldn't matter either.
Both of those products are basically claiming to reduce or eliminate problems that arise when packet timing errors "leak into" the other circuitry in the DAC.

Once the USB data packets are received by the USB interface, they are converted into I2S or S/PDIF type data and passed on to the DAC chip for conversion.
(If you have other Coax or Toslink S/PDIF inputs, they accept S/PDIF data directly and send it more or less directly to the DAC as well.)

The ASRC in the DC-1 sits right before the DAC chip itself, and removes jitter from the data stream right before it enters the DAC chip for conversion.
This allows the ASRC to remove jitter from data coming from any of the DC-1's inputs (it is sort of redundant with the USB input, which shouldn't have any jitter on it anyway, but it also works for the S/PDIF inputs).
The ASRC does this by accepting the incoming data stream, and then "reclocking" it to synchronize to a new, clean internal clock.
In the DC-1, sophisticated circuitry actually locks onto the sample rate of the incoming signal and produces a new internal clock that matches it....
this allows the ASRC in the DC-1 to reclock the data while maintaining the same sample rate as the original data.

In terms of comparisons.... both the Schiit and Uptone products are designed with the hope of eliminating problems caused by design flaws in the DAC you connect them to.
The DC-1 is basically designed not to have those flaws to begin with... (and the ASRC in the DC-1 is there to reduce or eliminate jitter in S/PDIF sources - which neither of those other devices addresses at all).

Feb 27, 2015 23:53:51 GMT -5 TheMachinist said:

I am quite interested to know in detail about the ASRC implementation on the DC-1 soecifically. I am sure it would have been discussed somewhere. If so, kindly point me there..

Quite interested to know how it compares to Schiit Wyrd and USB Regen reclockers in theory.

[Dark Ranger]

Mar 16, 2015 12:04:54 GMT -5 KeithL said:

<snip>

More often the issue is that the PLAYER program must also support WASAPI as an output choice or option - and some do not.
jRiver supports it by default; FooBar2000 supports WASAPI - but you have to download the free WASAPI plugin and install it.
Most modern players do support WASAPI as an option (although Windows Media Player, and some players like VLC that "simply use your Windows default player settings", do not.)

<snip>

Thanks for the correction, Keith. I ran into some issues in the past, but that was with ASIO, not WASAPI.

[Chris]

Mar 16, 2015 13:35:08 GMT -5 KeithL said:

Let me clear the air a bit here.

Driver signature enforcement is one of those "security settings" that, quite honestly, often causes more problems than it potentially avoids. It was available in Windows 7, but was shut off by default in most installations (except specifically on some Asus 64 bit machines); it seems to be on by default in Windows 8 (at least usually).

What driver signature enforcement does is to verify a digital signature on each driver you install (you could think of it as an "anti counterfeiting measure" for drivers). To get "a driver signature" you submit the driver - along with a hefty payment - and get a cryptographic key issued for it. This process must them be repeated every time you update the driver. Because the process costs several thousand dollars, a significant percentage of the companies who use drivers aren't willing to pay it. Because of this, while you may be willing to trust drivers that are signed, you have no way of knowing whether an unsigned driver is "risky" or just unsigned. (Also bear in mind that this only matters for anonymously-downloaded drivers; if you got the driver from us, or directly from some other vendor, then you know where it came from, so there's no benefit to having a signature to confirm that. And, if you install lots of drivers, you'll almost undoubtedly run into other unsigned drivers for their devices, so you'll have had to turn signature enforcement off anyway.)

We get our C-Media drivers directly from C-Media... and, apparently, they don't feel that it's justified to spend the extra cost to have their drivers signed. For our part in it, we could get the drivers signed, but then we'd have to raise the price of every DAC we sell by a few bucks to pay for it - so we decided not to. If you want to place blame, then the real question is why, after all this time, Microsoft hasn't included UAC2 support in Windows (if Windows supported UAC2 internally, like it does UAC1, and like Apple currently does, then you wouldn't have to load extra drivers, and we wouldn't have to supply them; the actual "workaround" is having to install external drivers to begin with).

Incidentally, you WILL have to leave driver signature enforcement off after installing the drivers. If you were to turn it off to install the drivers, then on again afterwards, it will then "break" the drivers the next time they try to load. And, if that happens, you'll have to turn signature enforcement off, remove the broken drivers, then reinstall the drivers correctly.

Mar 15, 2015 12:21:08 GMT -5 Chris said:

Uh, I did and I don't endorse Emotiva's workaround. It's lazy. Don't take offence. I adore Emotiva and own a lot of equipment from them but justifying turning off Operating System default security settings is a workaround but not in my view correct. Secondly, Shiit either by using newer drivers or paying more attention prove that these drivers can be installed without the workarounds that Emotiva documents. I'm not being harsh on Emotiva, they are a small outfit and have understandably limited software expertise. They will get there, but these types of workarounds I have seen over and over during the past 30 years or so working in the Computer business. I don't want to bore people with my background but this is an area I have worked in for years and have a pretty deep understanding. Hopefully, Emotiva will resolve this with CMedia updates as I'm sure they don't like writing up several pages of workarounds to install their drivers. To conclude, as Operating Systems have become more secure many hardware and software companies were caught off guard with these security issues (UAC was a big problem initially) where their product worked because they deviated from GAP software. Eventually, they learned and accepted and it became a non-issue. I will not oblige and turn off Operating System security defaults just to accommodate some software that is not compliant.

Keith I really appreciate you chiming in on the driver signing issue. As I tried to say, I am not unaware of the issues or unsympathetic about the headaches the driver signing issue causes a small company like Emotiva. As I spoke to you a couple of times on the phone and mentioned that I am a former employee of Microsoft and also worked at small software developer companies before that. Over the many years I have observed behaviors that got the job done but caused issues down the road.

Driver signing was put into the operating system for a good reason to make the system more secure. One can argue about implementations, etc. but it is there for a good reason. One of the issues I dealt with while at Microsoft was working with customers that worked for three letter government agencies that started with the letters "N" and "C" and ended in "A", was the security of the Windows environment. Originally, Windows essentially had no security but was greatly improved with the introduction of Windows NT which laid the foundation for all current versions of Windows (i.e. the Windows NT Kernel). Microsoft has gotten the security religion over the years and as you know issues Monthly updates that usually include security updates. Today, I will put the Windows OS security up against any other mass market OS in terms of responsiveness to security threats. This was not the case 20 plus years ago.

The problem I have is that advising an average user to turn off security settings for the purpose of running software or hardware is a very bad idea. Of course, there are exceptions and if you are a developer or a really advanced user you will know the risks and will accept the consequences. But, as you have pointed out, in order to continue to use the Emotiva drivers, you will have to leave driver signing permanently turned off. IMHO, I just don't think asking your customers to lessen the security of their system on a permanent basis is a good thing in the long term. For example, what if someone turns off driver signing and then later on they install some other company's software/hardware and it turns out the driver has been infected with a botnet payload? Or, what if Emotiva or C-Media's website is hacked and the driver package is infected with a virus unknown to the web site operators? What happens to the customers then? Please tell me you agree these things "could" happen and have happened to other companies?

Keith, you didn't address an issue that I brought up:

Why can I install the Shiit drivers that I assume are the same C-Media package Emotiva has access to but they do not require me to disable driver signing? They work fine with the DC-1. I also have a Shiit DAC so I can use the drivers with that. Why does the Emotiva install require the driver signing disable workaround and the Shiit drivers do not?

Keith, I agree with you that Windows really needs to support USB Audio 2.0. It's ridiculous that even phones (Android L/5.0) now supports it but Windows does not. I have personally been vocal to Microsoft about the issue along with host of others that have pleaded for this support. Microsoft has been mum about their reasons not to add this feature (beyond the usual development and testing time)? I am attaching a thread from the [wdmaudiodev] list bot that anyone can subscribe to. This ([wdmaudiodev]) is a list devoted to Window Audio developer issues. I would encourage someone at Emotiva to subscribe to this thread since you will see it is a direct line to the Microsoft Windows Audio Team. Specifically, you will see the name Matthew van Eerde <[e-mail]>. He is a member of the Windows Audio Team. I would encourage Emotiva to make their concerns known as others have in this thread I am attaching.

I really appreciate all that Emotiva does and my criticism on this issue is solely meant to encourage Emotiva to be the best that they can be? Thanks for your consideration.

-CB

P.S I was looking at Mathew's blog and there is a very interesting post all about driver signing. Curiously, it doesn't mention any cost associated with setting up a signed driver that isn't included in the Windows distrib. I just skimmed the post so I may have misunderstood. It may be worthwhile for an Emotiva software developer to take a look at this blog post?

I see now where the certificate $2,000 cost comes from. It's from the USB forum not Microsoft. I think it is important to note that Microsoft is not the villain here asking for $2,000?

"If you are new to the industry and want to start making USB devices, the vendor ID from the USB-IF will cost you $2,000 and the code signing certificate required for Windows 8 support will probably cost a few hundred dollars per year. However, your signatures should keep working after the certificate expires if you make sure to use a timestamp when signing." Practical Windows Code and Driver Signing

I guess I can understand Emotiva's reluctance to spend this money but it sounds like the $2k is a one time fee and a few hundred a year is required going forward. Considering that many USB products are already in Emotiva's line up and many more will probably be developed is the $2k really a show stopper over many years? Just saying?

How to install unsigned drivers (Matthew van Eerde's web log)

Attachments:

Gmail - wdmaudiodev UAC2 in Win10_.pdf (206.8 KB)