Mac Mini version of a CAPS music server - Step by Step

[Alexis777]

Hi Tranz

 

This internal filter is way cheaper

 

Internal Filter Module for 2010 or newer MAC MINI/Macbook Pro

 

bought now together with this device for feeding the usb dac port with purest 5 v...

 

TeraDak BLADELIUS USB DAC power source 5V 3A Linear Power Supply | eBay

 

 

Let's see, I hope its work good... :-)

[tranz]

 

If you still have your EMI meter and your Mac mini fan hanging about, can you test for us the effect of the 3M AB5100S on it? (I'd ask John Swenson to do so with his more sophisticated equipment but he is tied up on a big project these days.) I did include a big square of it in with our Mac mini DC-conversion/Linear Fan Controller Kit that went to someone in Australia, but I myself have been too busy to try it. Was thinking about putting a cut circle of on the side of the mini's fan shroud that faces the motherboard.

 

Ciao,

--Alex

 

Hi Alex,

 

It does help. Not as much as Giron, but it is certainly absorbing/blocking some of the magnetic portion of the EMI field.

 

I placed the fan about 1 inch from the EMI meter.

 

Without AB5100S:

 

 

With AB5100S:

 

[tranz]

Hi Tranz

 

This internal filter is way cheaper

 

Internal Filter Module for 2010 or newer MAC MINI/Macbook Pro

 

bought now together with this device for feeding the usb dac port with purest 5 v...

 

TeraDak BLADELIUS USB DAC power source 5V 3A Linear Power Supply | eBay

 

 

Let's see, I hope its work good... :-)

 

Hi Alexis777,

 

Thanks for sharing the links and your experiences.

[tranz]

Duplicate - Deleted

[Superdad]

Hi Alex,

 

It does help. Not as much as Giron, but it is certainly absorbing/blocking some of the magnetic portion of the EMI field.

 

I placed the fan about 1 inch from the EMI meter.

 

Without AB5100S:

 

[ATTACH=CONFIG]14658[/ATTACH]

 

With AB5100S:

 

[ATTACH=CONFIG]14659[/ATTACH]

 

 

Thanks for doing that Tranz! What sort of readings are you getting with Giron material?

[tranz]

Thanks for doing that Tranz! What sort of readings are you getting with Giron material?

 

Hi Alex,

 

Keep in mind that the 3M is made to absorb high frequency noise, not just block/redirect magnetic fields. Not sure how good Giron is with absorbing.

 

Some pics....

 

Without Giron:

 

With Giron:

 

Cheers

[dude2010]

Hi Phil,

 

Thanks for the info. If I ever build a CAPS your OS tweaks are a no brainer. I used to build DAWs on Windows and had to do a lot of manual OS tweaking.

 

For Mac many of us are using the CAD scripts and manual tweaks to shut down unnecessary processes, as it makes a big audible difference.

 

But the only reason I even started using Mac was for the audio software Amarra, and now Audivarna which are Mac only.

 

Cheers

 

Can we get hands on the best scripts for shutting down processes?

Messenger, Itunes helper and all that other sheit!

[tranz]

Can we get hands on the best scripts for shutting down processes?

Messenger, Itunes helper and all that other sheit!

 

There are two good threads where a few have gone to great lengths shutting down processes to the low 50s.

 

http://www.computeraudiophile.com/f11-software/computer-audio-design-osx-audio-optimization-script-18128/?highlight=cad

 

http://www.computeraudiophile.com/f11-software/osx-optimisation-scratch-21952/?highlight=optimization

 

Cheers

[bobbmd]

PLEASE,give me a break-the mac mini is totally quiet-you people are so wrapped in yourselves just listen with amarra,amarra sQ a schiit gungnir and a lowly schiit magni with senneisher 598's or rs 170's and all will be fine you don't need a CAPS OR JRIVER

[tranz]

PLEASE,give me a break-the mac mini is totally quiet-you people are so wrapped in yourselves just listen with amarra,amarra sQ a schiit gungnir and a lowly schiit magni with senneisher 598's or rs 170's and all will be fine you don't need a CAPS OR JRIVER

 

Hi bobbmd,

 

First, every setup and ears are different. So in your instance it might indeed make no difference, in which case enjoy it!

 

The biggest culprit of it all I believe is the USB connection to the DAC. This connection flows noise that can be caused by all the things mentioned here and in other threads.

 

My hope is on a more electrically immune solution at some point with a LAN DAC input and wireless bridge. Then everything upstream makes little difference.

 

With sensitive equipment and easily irritated ears, in my case all this was not for fun, but out of necessity.

[JohnSwenson]

My hope is on a more electrically immune solution at some point with a LAN DAC input and wireless bridge. Then everything upstream makes little difference.

 

With sensitive equipment and easily irritated ears, in my case all this was not for fun, but out of necessity.

 

I have been doing some measurements of USB inputs, Ethernet inputs, S/PDIF etc and have come to some somewhat unusual conclusions.

 

First off the concept of the USB cable being a conduit for conducting a large amount of noise from the computer to the DAC is to a large extent a myth. Well done properly implemented USB interfaces just don't show it at all. Of course NOT well done ones can have significant problems with this, but it does not seem to be a law of the universe. And doing it well so that computer noise is not directly transmitted over the cable is not that hard or expensive to do.

 

What I DID find was something else all together, I'm calling it packet noise and it happens with any interface that uses packets, including USB and Ethernet, and even to a small degree S/PDIF. With packet based interfaces the processing of data happens in bursts when the packets come in, with much lower processing in between packets. This bursty behavior is clearly visible as noise on power supply traces and ground planes. The problem is that the packet frequencies are all right smack in the middle of the audio range.

 

The spectrum of these noise bursts is very wide, including low frequency components up to hundreds of MHz. The Power Distribution Networks (PDN) on almost all DAC boards simply cannot deal well with this, this noise winds up getting through to the oscillators and DAC chips no matter how good the regulators are.

 

With just a simple scope I have been able to trace this noise through from receiver to DAC chip, even through some very high quality regulator stages designed to block noise. But this noise seems to make it through no matter what. The very broadband nature of the noise seems to be the major culprit, it just seems to be incredibly difficult to block noise in the whole spectrum of this noise. Some implementations seem to be good at the low frequency side, some at the high.

 

The spectrum of these noise bursts seems to be dependent on what is going on with the signal feeding them. Changes in signal integrity cause the receivers to change their behavior which changes the noise spectrum due to their operation. This seems to be a major contributor to why things like different cables make a difference.

 

So looking at this from the system perspective we seem to have two ways to deal with this: come up with a way to prevent the noise from getting through to the clock oscillators and DAC chip, OR prevent the noise from happening in the first place.

 

The second approach seems to be what a LOT of what is happening around CA is doing, subtly changing the signal integrity arriving at the receiver to change the spectrum of the packet noise so it's effect on the sound quality is lessened.

 

I (and others) have spent a lot of work on the first approach and this is turning out to be really difficult to do, no matter what we do this packet noise still seems to make its way through to the chips.

 

That leaves trying to minimize the noise generated by the receiver in the first place. Again there seems to be two ways to do this: don't use a packet interface, OR come up with a PDN such that the wildly varying current demand of the receiver doesn't produce much voltage noise.

 

The first is what the USB to S/PDIF or I2S converters are doing, if everything is done right (which it rarely is) the potential to produce lower noise at the clock and DAC chips is there. It really has to be thought out and done right which usually means one design team putting it all together rather than buying different pieces from different companies. If you don't get it right those problems can be far greater than the gain you get from not having a packet interface.

 

The other approach is to focus on the PDN to the receiver chip in the DAC, this is rarely done, all the effort gets focused on the clock and DAC chips, the receiver is "just a digital chip" so doesn't get that much effort in the design. My latest experiments point to this being one of the most important parts of a really good DAC design. It DOES seem possible to build a PDN to the receiver circuit that can radically cut down on the packet noise generated by the receiver, besides making the DAC sound much better this significantly cuts down on sensitivity to outside influences.

 

It is not easy or cheap, but by keeping it in mind throughout the design it looks like it might be doable.

 

This thread has been very good, it has crystalized a lot of my thoughts on these subjects and led to some interesting investigations. Hopefully it will lead to some improved sound.

 

John S.

[miguelito]

The other approach is to focus on the PDN to the receiver chip in the DAC, this is rarely done, all the effort gets focused on the clock and DAC chips, the receiver is "just a digital chip" so doesn't get that much effort in the design. My latest experiments point to this being one of the most important parts of a really good DAC design. It DOES seem possible to build a PDN to the receiver circuit that can radically cut down on the packet noise generated by the receiver, besides making the DAC sound much better this significantly cuts down on sensitivity to outside influences.

I don't know at what stage in a USB input the "depacketization" takes place. If it happens in the USB receiver chip, does this then mean that a DAC with a source-powered USB receiver chip would be preferable to one with a USB receiver chip powered by the DAC?

 

I would appreciate it if you could clarify the stages in the process, from USB source, to USB receiver to the DAC process.

 

Thx

[JohnSwenson]

I don't know at what stage in a USB input the "depacketization" takes place. If it happens in the USB receiver chip, does this then mean that a DAC with a source-powered USB receiver chip would be preferable to one with a USB receiver chip powered by the DAC?

 

I would appreciate it if you could clarify the stages in the process, from USB source, to USB receiver to the DAC process.

 

Thx

 

At the source computer there is a USB host chip (or block inside a larger processor or "chipset" which is connect to one of the computers busses. This host chip is in charge of grabbing data off the bus (connected to the memory somehow) and converting into packets and sending them out over the bus. There will be space between packets, the bus is not constantly busy.

 

At the receiver the packets are read in and their contents are put in a buffer. The "audio clock" independently pulls data out of the buffer at a constant rate and sends out an I2S stream (sometimes it's SPDIF). Most of the receiver's processing happens when the packet arrives, and a small amount happens in sync with the "audio" clock.

 

The packet noise I mentioned happens on both the positive supply voltages and the ground planes. It is less of an issue (but still definitely there) in a situation where the receiver is run off a separate power supply from the main clock and DAC. But even with separate power domains and isolators this packet noise still shows up on the power of the clock and DAC chips. I'm not completely sure of all the mechanisms going on here, there is still a lot of work, but it doesn't seem to matter if the separate power domain is provided by the USB cable or a separate power supply in the DAC.

 

John S.

[tranz]

Hi JohnSwenson,

 

Thank you for your valuable input!

 

It has been frustrating not knowing the underlying root cause and not having the engineering skills and tools to investigate, and yet my ears telling me something is wrong.

 

It also might explain why different listening sessions with the same equipment sometimes sound different, and why things like cutting OS processes or even different bit perfect playback softwares have such a big influence. And why people have such varying conclusions even when comparing the same two bit perfect playback software packages on different hardware and OS setups.

 

The chip calculation noise I guess is similar to the reason some high end receivers have separate power supplies for analog and digital (e.g. graphics chip) or perhaps the separation of the PCI card and the DAC in pro audio recording rigs, or why we have separate power filter banks for analog and digital gear. Or perhaps even why I prefer discrete ladder DACs.

 

And perhaps because it is so difficult to design is why I have had such a tough time liking any USB inputs, even from some really expensive gear.

 

Which brings me to an example of MSB, which has input modules that translate USB, SPDIF, or LAN into I2S and have multiple separated linear power supplies. Would that be an example, albeit very expensive, of a design that provides that filtering, separation and clean PDN?

 

On another thread someone had mentioned some DIY rigs using the ABC PCB (Swiss company) board for USB and LAN. Would that be an example of a good design, or is that then more related to what you do next with the board in terms of isolation, power and ground that makes or breaks the implementation?

 

Is using something like a NAS into a LAN DAC input, an SMS100, Sonore Rendu, etc. which have very few processes running and no graphics chips, help at all? Or does it really not matter? I guess with a properly insulated PDN it should not matter what happens upstream, unless packets are dropped?

 

And if there are bits or packets being dropped on the way, will it always result in a clearly audible stutter, or will it just not sound as good, for example with streamers or a LAN input in a DAC?

 

I guess you are working on a solution for this. Looking forward to it!

 

Please continue to let us know your thoughts and findings!

 

Cheers.

[Superdad]

Which brings me to an example of MSB, which has input modules that translate USB, SPDIF, or LAN into I2S and have multiple separated linear power supplies. Would that be an example, albeit very expensive, of a design that provides that filtering, separation and clean PDN?

 

On another thread someone had mentioned some DIY rigs using the ABC PCB (Swiss company) board for USB and LAN. Would that be an example of a good design, or is that then more related to what you do next with the board in terms of isolation, power and ground that makes or breaks the implementation?

 

Is using something like a NAS into a LAN DAC input, an SMS100, Sonore Rendu, etc. which have very few processes running and no graphics chips, help at all? Or does it really not matter? I guess with a properly insulated PDN it should not matter what happens upstream, unless packets are dropped?

 

And if there are bits or packets being dropped on the way, will it always result in a clearly audible stutter, or will it just not sound as good, for example with streamers or a LAN input in a DAC?

 

I guess you are working on a solution for this. Looking forward to it!

 

Hi Tranz:

Allow me to jump in here with some attempts to clarify and to answer your questions.

 

First, full disclosure:

John Swenson and I are working on several products/solutions (well, he is the design genius--I am just sponsoring and we work together to focus on practical realizations that can interoperate in the real world). One little item that is mostly done and just waiting on me to pay for enclosure machining and PCB production is a USB Regenerator (a single-port USB hub similar to the Schiit Wyrd, but tiny to attach direct to DAC w/o cable, and with some technical differences; started on it before the Wyrd was announced; a preview PCB pic is here: http://www.computeraudiophile.com/f8-general-forum/schiit-wyrd-universal-serial-bus-industry-standard-cables-connectors-and-communications-protocols-between-computers-and-electronic-devices-decrappifier-22085/#post361395). Such devices could obviate the need for fancy PCI USB cards as they put the generation of a clean USB signal (and clean power) close to the DAC--after the USB cable. And such is the only choice for Mac users since there are not really any USB output upgrades for us.

 

The other project we have been working on (and off) for a much longer time (2 years) is a USB>Ethernet Audio Bridge. Again, in recent months I have become a little more open about this one here at CA. And some very well-known DAC manufacturers are anxious to license this--totally compatible, totally non-DLNA--solution from us to provide an Ethernet input to their flagship DAC. Assuming it works of course.

 

Anyway, I put forth the above not as any promotion of what we are doing, but to illustrate that the very area of such concern to you Tranz (you have brought it up in many threads) is one of intense focus and testing for us. My system, like yours and that of many other's here, does respond to all these crazy things (between the computer and the DAC), and whether through DAC input and isolation methods or via external devices, John has been trying for years to make these interfaces more immune to the variables that cause ground plane noise, "packet jitter", and other pernicious minutia.

 

 

I think that in John's reports above, he uses the term "receiver" in a somewhat generalized way to make his point and to not divert too much into the details. But I think it is helpful at this point to be a little more specific and to examine the physical elements involved in the input interface of a modern DAC. Some has been written elsewhere, and you can easily look at the differences between various USB>I2S input boards (available for both DIY and OEM), but I want to point out what is common for all--including any Ethernet input.

 

Let's start with power supplies and isolation:

Any DAC designer aiming for high performance is going to incorporate multiple PS domains. At a minimum, separate supplies for analog and digital sections, but really the digital side needs at least two supplies itself: one for the "dirty" input side, and one for the DAC and clocking side. Some, like my friend Jeff Kalt with the Resolution Audio Cantata, will even do separate supplies all the way back to their own transformer (http://cdn.head-fi.org/3/31/311b8caf_6.jpeg).

 

The trouble is that, even if you divide sections onto separate boards to have discrete power ground planes, data still needs to move between them. That's where the various data isolation chips and methods come in. Giant-magneto-resistive isolators, opto-isolators, even some where there are tiny RF transmitters and receivers inside the chip. And while they will provide desired galvanic isolation, it is typically just at lower frequencies, and these devices add jitter of their own.

Also, where you put these in relation to the clocks and processors matters. Plus one should have a reclocking flop after each isolator.

 

But back to USB and Ethernet inputs:

The first thing the data cable "sees" when plugged into the port is a PHY chip (physical interface) and both the PHY and whichever protocol processor follows it need their own clock (typically a 13MHz or 26MHz XO). This is NOT at all the same as the audio clock--which ideally is being fed to the USB or Ethernet processor all the way back from a low phase-noise master clock next to the DAC chip (as opposed to having its own and expecting the DAC to slave itself to that.)

Actually, in the case of Ethernet, the first thing the signal encounters--before the PHY--is an isolation transformer, typically built into the RJ-45 jack itself.

And the USB PHY chips themselves are an extremely complicated piece of work. Remember, these things are designed for a whole array of "universal" functions. They have multiple PLLs and clocks with overlapping phase running around inside them. Just take a look at the data sheet for a typical PHY (http://www.ti.com/lit/ds/symlink/tusb1211.pdf).

Very few designers pay much attention to the PHY or its clock, but we suspect that some gains can be made there as well.

 

I am getting a bit off point here, so lets circle back to your questions:

John is very familiar with the ABC PCB Network Audio DLNA Renderer as he has had one in his lab several times in the last couple of years (it might be there still), along with the ABC-PCB Edel USB>I2S board that I bought for him. (And of course he has played with or analyzed close-up photos of many USB>I2S boards, as well as building his own as part of DAC designs).

Other than whatever benefits might come from an Ethernet interface (e.g. galvanic isolation from computer--assuming your Ethernet cable does not have attached shields at both ends), an Ethernet input board has to perform similar processing--and requires similar PS, clocking, and data isolation--as a USB input. Except that in the case of the ABC-PCB or any Ethernet audio input that relies on DLNA, you have MUCH more going on, both with DLNA s/w layers, and massive DSP (the ABC-PCB board uses two massive Blackfin processors-- http://www.analog.com/en/processors-dsp/blackfin/adsp-bf537/products/product.html).

 

And of course the output to the rest of the DAC from any of these boards--Ethernet or USB--is I2S. Generation, transmission, and isolation of that all important I2S signal can be improved, but here is where I will stay quiet since we are not ready to reveal John's new technique for that--until we release the USB>Ethernet Audio Bridge solution for OEM and DIY (once other engineers see the new approach, some copying will be inevitable).

 

Tranz, you mentioned in the same sentence "a NAS into a LAN DAC input, an SMS100, or Sonore Rendu." I am sure that you know you named 3 completely different kinds of devices. Well, maybe it is two since in the present market (other than perhaps a Resolution Cantata used with their Pont Neuf Ethernet dongle), a "LAN input DAC" is a UPnP/DLNA renderer just as the Sonore Rendu is. And the SOtM sMS-100 (or Sonore Orbiter, and others) is a Linux computer module running an OS and outputting USB.

But yes, fewer processes, inactive/disabled graphics processor and other shut off busses--those can all help SQ just as you have heard in your own computer experiments and tweaking.

 

Will we ever get to total immunity? Not sure, but we can all try. I have certainly been encouraged by my (well documented and shared by others) experiences with eliminating all but 3 connections to my i7 music Mac mini (USB to DAC, DC cable for LPS, and Ethernet cable direct to other Mac), and drawing my music from a shared drive on my desktop. Those Firewire drive enclosures each sounded different (and not good) when connected to the music player computer, but via the Ethernet connection they of course all sound exactly the same--and better.

I am hoping very much that our USB>Ethernet Audio Bridge will equal or exceed what we are able to do with a USB input DAC (it essentially puts the USB audio input at the USB port of the computer and then generates an Ethernet signal--able to got through a LAN switch and pair to the Ethernet input DAC elsewhere on the LAN).

 

Lastly, a few people here have begun using an Airport Extreme as a cheap NAS. It has good potential as a simple architecture since you can hardwire your music computer directly to it (the wonderful and affordable BlueJeans/Belden Cat6a is an excellent choice), have your USB hard drive library attached (sadly, the USB2.0 port is slow), and remote control via wifi from a tablet, laptop, or other computer. The flat-square Airport Extremes (2007-2011)--just before the current tall ones--used a 12V external DC SMPS brick and even a standard 5.5mm x 2.5mm DC barrel jack. So those are great candidates for a linear PS if someone is going to use it as a "cheapNAS."

 

Sorry I went on for so long. Now it's back to work for me and to preparing for a long Thanksgiving vacation with family. We are going to Venice! Sadly, Venice, California, not Venice, Italy.

[jabbr]

I have been doing some measurements of USB inputs, Ethernet inputs, S/PDIF etc and have come to some somewhat unusual conclusions.

 

First off the concept of the USB cable being a conduit for conducting a large amount of noise from the computer to the DAC is to a large extent a myth. Well done properly implemented USB interfaces just don't show it at all. Of course NOT well done ones can have significant problems with this, but it does not seem to be a law of the universe. And doing it well so that computer noise is not directly transmitted over the cable is not that hard or expensive to do.

 

Good to hear. There seems to be alot of myth around USB cables ... of course they need to be precisely 90 ohms which, for example a $6 TE Connections cable will do.

 

What I DID find was something else all together, I'm calling it packet noise and it happens with any interface that uses packets, including USB and Ethernet, and even to a small degree S/PDIF. With packet based interfaces the processing of data happens in bursts when the packets come in, with much lower processing in between packets. This bursty behavior is clearly visible as noise on power supply traces and ground planes. The problem is that the packet frequencies are all right smack in the middle of the audio range.

 

So DSD?

[tranz]

Hi Superdad.

 

Thank you very much for the detailed answer. I look forward to what you and John are designing. It is also good to read that there will be a Mac solution for what the SoTM/PPA cards have been able to provide windows boxes.

 

I knew that as soon as I had put "a NAS into a LAN DAC input, an SMS100, or Sonore Rendu" together it required a bit more explanation. All it was were a few examples that came to mind where a Mac or Win computer, which all have graphics chips and run far more continuous processes than necessary for audio purposes, could be bypassed and, for example, a Linux based NAS would be all that is needed. I should have mentioned the other big one at the moment, the Auralic Aries. But with John's mention of a major issue being the burst package chip noise it again all depends on how it has been implemented.

 

Then again, it sounds like we currently are still fighting two noise issues:

 

1. Packet burst noise at the receiving chip

2. Computer generated noise (chips, fans, OS, processes, switchers, etc. ) flowing down through the ground, shield, 5V

 

Unless I am missing something, the packet burst noise in the receiver chip will happen regardless of what has been done upstream, as that is just the nature of the chip running its calculations. The frequencies can alter a bit based on some changes done upstream, and from John’s testing it sounds like this is potentially a bigger bogey. This is one we as consumers have zero control over and are at the mercy of the manufacturer.

 

The second noise source is the one we have spent so much time and money trying to resolve, and we have heard benefits from all the tweaking. The LAN connection logically still being an easy way to cut this noise link with the computer. Perhaps in that case it really does not matter what harddrive, fan or not, playback choice, processes etc. you are using upstream. None of this logically would have much impact on the packet burst noise, but perhaps that is an incorrect understanding on my part.

 

Crazy that it has taken so many years, and specialized audio enthusiasts like yourself and John to look into it. Unless this is common knowledge with the big players?

 

Venice Beach California? Jealous...

 

Cheers

[JohnSwenson]

I see I need to clarify some of what I said earlier, it doesn't seem I explained it very well.

 

What the measurements seem to be showing is that noise from the computer is NOT, repeat NOT, going directly to the sensitive chips in the DAC. The most sensitive chips are the main clock oscillator and the DAC chip itself. The path from computer to DAC chips is more convoluted. I'm going to talk about several different topics, then bring them all together.

 

What I am seeing at the DAC chips is voltage noise generated by the USB receiver. There are two main parts to a receiver, the PHY and the MAC. The PHY is a very analogish block, it is the PHYsical interface to the data lines. It contains many circuit blocks whose purpose is to extract correct data off of the physical data wires. These blocks are used in various combinations depending on the "quality" (referred to as Signal Integrity (SI)) of the signal. If the receiver is fed a very high SI signal, very few of these blocks are engaged and the current demand of the PHY is low. As the SI gets worse more and more of these blocks are brought into play in order to correctly extract the data off the wires. This means that the amplitude and spectrum of the current pulses drawn by the PHY vary radically with varying SI on the wires.

 

The MAC is the "controller" part of the receiver, it knows about USB protocols etc. Its current draw is pretty much independent of SI.

 

Both the PHY and MAC have current draw that is hi when packets come in, and very low in between packets. BUT the PHY's current draw varies a LOT with the SI of the signal on the wire.

 

The second topic is "isolation", primarily between "dirty" side and "clean side". There have been a number of people working hard on this, using separate ground planes, power supplies and digital isolators between domains. The impetus for this has been to prevent the noise from the dirty computer getting into the sensitive analog parts of the DAC. No matter what was done bad stuff still seemed to get through. I have measured several DACs that do have these sorts of isolation schemes in place and I STLL see the packet noise at the clock and DAC chips.

 

So since the attempts at isolation do not seemed to fully work, how do we get rid of this noise at the DAC chips? The approach of most of the people here on CA has been to improve the SI of the signal getting to the receiver. This DOES cut down on the current draw of the PHY, which does decrease the noise at the DAC chips. But the amount of noise reduction with all this heroic effort is not huge, there is a long way to go.

 

SO, what to do? The isolation schemes don't seem to work as well as we think they should (nobody knows why). I am taking a different approach to the issue, rather than trying to increase the isolation, or improve the SI, I am aiming at decreasing the VOLTAGE noise in the first place. Remember that what I discussed above with the receiver is the CURRENT draw, that becomes voltage when it flows through the impedance of the Power Distribution Network (PDN). The lower the impedance of the PDN the lower the voltage noise produced by a given current draw. So by lowering the PDN impedance the VOLTAGE noise is decreased. That means lower noise at the DAC chips, and you don't have to improve the SI of the signal to achieve it. Ultimately this will hopefully mean a major decrease in sensitivity to cables and computer issues.

 

Why hasn't anybody done this before? I don't think anybody has thought about the system in these terms. The USB receiver is usually just thought of as a "digital" piece thus not a lot of effort or thought is put into it's PDN. The best designers put a lot of thought into the PDN for the DAC chips, but not the USB receiver. The other reason is that it is HARD. The PDN has to be very low from about 100Hz to over 100MHz, that is a HUGE range (20 octaves). There are people that DO know how to do this (my guess is less than 50 in the whole world), but I can guarantee that they are not working for audiophile companies, they are working for IBM, Intel, Cisco etc. I have moderate amount of knowledge in this field but am not a real expert.

 

So what I am doing right now is some crude attempts at significantly lowering the PDN impedance in a design I am working on and seeing if this decreases the packet noise generated by the receiver. This should also improve the sound.

 

BTW the PDN impedance is controlled by several factors: at high frequencies it is dominated by the board trace and plane geometries, the layer stack and bypass capacitors (number, type, size, inductance etc). The lower frequencies are heavily influenced by the behavior of the voltage regulators and capacitors before and after the regulators. This is all FAR more complicated than just looking at the "ripple noise" spec. If you have ever looked at the spec sheets for modern regulators you see 20-30 graphs, that is the information that is used in analyzing and optimizing a PDN.

 

So the upshot is that I think a lot of the issues we have with DACs can be addressed by optimizing the PDN of the receivers, it won't be easy, but I think it will help a lot and it is NOT voodoo, it is known engineering (although not wide expertise).

 

I hope that makes things a little clearer.

 

John S.

[tranz]

Hi John,

 

Thank you for the additional detail!

 

It really does explain why there are such varying experiences and sometimes heated discussions with many pointing to audiophoolery, as anything upstream could affect the SI. But with your efforts it has now moved beyond the anecdotal and provided an engineering view with measured result. I salute you.

 

Your point is well taken about those engineers that do tackle this type of noise are likely working for the big chip and defense players earning multiple 100Ks a year and would be too expensive for most audio companies.

 

Perhaps at some point we will see your design licensed in many brands.

 

Cheers

[Bob Stern]

The second topic is "isolation", primarily between "dirty" side and "clean side". There have been a number of people working hard on this, using separate ground planes, power supplies and digital isolators between domains. The impetus for this has been to prevent the noise from the dirty computer getting into the sensitive analog parts of the DAC. No matter what was done bad stuff still seemed to get through. I have measured several DACs that do have these sorts of isolation schemes in place and I STLL see the packet noise at the clock and DAC chips.

When you say "digital isolators between domains" are inadequate to solve the problem, have you tried the sort of solution proposed by Tony Lauck (on PC Asylum) in which the USB receiver and D/A domains are connected only optically, not electrically?

[Bob Stern]

Many people interested in the DAC noise isolation issues are not interested in Mac Mini's, so perhaps this topic should be moved to a new thread?

[One and a half]

Thanks John (and superdad in the background) for discovering packet noise and detailing the results. For AC power electronics with which I am familiar with, as soon as a piece of silicon and capacitance show themselves in a circuit, harmonics are created on the supply feeding the device.

Very much like a backwash when a wave reaches the shore, and with the same variability, the frequency bandwidth of this noise is incredibly wide, so designing a filter to notch this out is not going to work since it would need to encompass the audio frequencies as well, not the greatest of ideas.

 

I wonder how much of the packet noise is produced by the audio frequencies themselves coming back through the power supplies.

 

It's as if you need to develop a balanced "digital" system in the receiver to cancel out the effects of the packet noise, since hopefully it is asymmetrical. XLR is such a simple system of ignoring crud to the receiver. On another tack, one manufacturer has split the packets apart and introduced delays that feed into multiple DACs. This is not really new, but perhaps the effects of packet noise tend to be minimised with this system?

 

Great insight. Thanks again.

[alsterfan]

Sorry, made a mistake

[miguelito]

The lower the impedance of the PDN the lower the voltage noise produced by a given current draw. So by lowering the PDN impedance the VOLTAGE noise is decreased. That means lower noise at the DAC chips, and you don't have to improve the SI of the signal to achieve it. Ultimately this will hopefully mean a major decrease in sensitivity to cables and computer issues.

 

So what I am doing right now is some crude attempts at significantly lowering the PDN impedance in a design I am working on and seeing if this decreases the packet noise generated by the receiver. This should also improve the sound.

 

BTW the PDN impedance is controlled by several factors: at high frequencies it is dominated by the board trace and plane geometries, the layer stack and bypass capacitors (number, type, size, inductance etc).

This is very interesting... You mean some very carefully chosen cap bypasses very close to the chip power pins? I remember some stuff I did to my CD player when I was in school many years ago (physics, but in my free time I futzed around with modifying audio equipment). Basically I added tantalum caps (I want to say 10 uF... can't remember) around the DAC and the analog output opamp's power lines, very very close to the chips (looked disgusting). It made a huge diff.

 

The next thing I did was: I found a lab-grade regulated linear PS in the lab trash (+/- 15v, 1 amp) and cut off the power traces of the analog output stage (but ground planes where still there) and powered the analog stage off of this supply. Again major improvement. And this was just bypassing the DAC and analog stages - no USB nothing at the time (~20yrs ago!).

[miguelito]

Sorry, made a mistake

Wifi? How do you get data to the DAC over wifi?