Hi all,
So, what we want to achieve for a future version of audio-widget are:
1. Minimization of PC noise from getting to the DAC, MCLK and other important analog parts of the widget through common mode or other effects;
2. Breaking of any ground loop effect;
3. Other noise reduction strategies.
We have so far one specific proposal, ie optoisolation of MCLK (DAC to uC) and I2S signals (uC to DAC) with possible pulse shaping with flipflops (which itself may generate noise, especially on the power rails).
How do the discussions on common mode, transformers, differential input/output etc. above translate into a specific design? Any block diagram or rough schematics?
On the issue of USB-I2S-DAC vs other possibilities:
1. Looks like there is consensus that Firewire is not worth implementing as it does not have overwhelming advantage over USB given the complexity of design. Also my question is whether there are "standard" Firewire drivers for rate feedback (other than from Mac OSX).
2. No one has answered my question about "standard" Ethernet audio drivers with rate feedback yet. We are actually very interested in the possibility of an eth-widget equivalent of USB-widget. But there is no clarity on standard drivers.
3. As discussed previously, we are not keen on SPDIF or HDMI unless there is a standard way to implement rate feedback.
Alex
So, what we want to achieve for a future version of audio-widget are:
1. Minimization of PC noise from getting to the DAC, MCLK and other important analog parts of the widget through common mode or other effects;
2. Breaking of any ground loop effect;
3. Other noise reduction strategies.
We have so far one specific proposal, ie optoisolation of MCLK (DAC to uC) and I2S signals (uC to DAC) with possible pulse shaping with flipflops (which itself may generate noise, especially on the power rails).
How do the discussions on common mode, transformers, differential input/output etc. above translate into a specific design? Any block diagram or rough schematics?
On the issue of USB-I2S-DAC vs other possibilities:
1. Looks like there is consensus that Firewire is not worth implementing as it does not have overwhelming advantage over USB given the complexity of design. Also my question is whether there are "standard" Firewire drivers for rate feedback (other than from Mac OSX).
2. No one has answered my question about "standard" Ethernet audio drivers with rate feedback yet. We are actually very interested in the possibility of an eth-widget equivalent of USB-widget. But there is no clarity on standard drivers.
3. As discussed previously, we are not keen on SPDIF or HDMI unless there is a standard way to implement rate feedback.
Alex
Hi Alex,
thanks for summing things up!
I'd like to add:
4. Understand more about how to implement the same UAC2 support Linux offers on Windows platforms.
Regarding isolators, one option is to make a board which sits between the USB-I2S module and the Analog Board. Isolators for outgoing signals (DAC I2S) would have to be powered by the "analog" power stemming from a battery and/or wall wart. Isolators for incoming (MCLK) will run off "digital" power like the module itself, i.e. USB VBUS.
Flip-flops for buffering can be added to the layout with the option of bypassing them with a 0R resistor. I agree that we should only buffer what's needed and not waste supply noise where rise/hold times are within spec.
I can voluntare to put together a schematic for the optos.
Any takers on the analog power supply?
Børge
thanks for summing things up!
I'd like to add:
4. Understand more about how to implement the same UAC2 support Linux offers on Windows platforms.
Regarding isolators, one option is to make a board which sits between the USB-I2S module and the Analog Board. Isolators for outgoing signals (DAC I2S) would have to be powered by the "analog" power stemming from a battery and/or wall wart. Isolators for incoming (MCLK) will run off "digital" power like the module itself, i.e. USB VBUS.
Flip-flops for buffering can be added to the layout with the option of bypassing them with a 0R resistor. I agree that we should only buffer what's needed and not waste supply noise where rise/hold times are within spec.
I can voluntare to put together a schematic for the optos.
Any takers on the analog power supply?
Børge
One suggestion is to use USB isolator circuits.
(E.g ADUM4160 | Full/Low Speed USB Digital Isolator | Digital Isolators | Interface | Analog Devices)
Make a good layout and use the PC USB supply for one side and one "pure" voltage for the other side and the result is very good.
(E.g ADUM4160 | Full/Low Speed USB Digital Isolator | Digital Isolators | Interface | Analog Devices)
Make a good layout and use the PC USB supply for one side and one "pure" voltage for the other side and the result is very good.
Using usb isolators is also an option. (E.g ADUM4160 | Full/Low Speed USB Digital Isolator | Digital Isolators | Interface | Analog Devices)
Good layout, using PC supply for the PC side and a "pure" voltage for the receiver give good results.
Good layout, using PC supply for the PC side and a "pure" voltage for the receiver give good results.
I think this is one of those questions where someone could give a definitive "yes" if they know of a driver, but it's hard to give a definitive "no" just because there might be an unknown driver.
I do know that the CoreAudio system on OSX is designed to make it possible for a custom driver to integrate rate feedback no matter how the hardware presents the information. So, it seems possible that someone could write an ethernet audio driver for CoreAudio and then it would work with any enx-widget, provided that the feedback follows the same protocol. That's basically the long way of saying that I don't know of anything existing, but it wouldn't be that difficult to create a standard. Such a driver would allow CoreAudio software to SRC match to adapt to the hardware rate, or to flow-control the data source to avoid SRC, either way it would be the audio program in control of which method is used, with the driver just providing the rate information.
Hi rsdio,
That's the problem for Ethernet audio. Who are going to write the drivers for Linux and Windows? How are you going to get the music playback software to support the "standard" you have created for rare feedback? There will be folks who want their favorite player to work.
For USB, with uac1 and uac2, Foobar, vlc, media monkey, mpd etc all work out of the box
Alex
That's the problem for Ethernet audio. Who are going to write the drivers for Linux and Windows? How are you going to get the music playback software to support the "standard" you have created for rare feedback? There will be folks who want their favorite player to work.
For USB, with uac1 and uac2, Foobar, vlc, media monkey, mpd etc all work out of the box
Alex
Those systems don't have pull-model audio standards anyway, at least not so far as I am aware. I made it clear that I was talking about CoreAudio only.
Well, all of the music software on Mac OS X would immediately work. That's the beauty of CoreAudio: they have already trained the audio software developers to work within a pull-model, so now all new rate feedback hardware will automatically work. Meanwhile, developers who are trying to port existing Windows and Linux audio software to OSX are whining that CoreAudio doesn't support their legacy push-model code base.
I have little hope for Windows, but it seems like someone should develop a CoreAudio-like system for Linux. PortAudio is still push-model (again, just my understanding).
For the design to be of the lowest noise the ground currents on/off the boards in the system need to be minimized as far as possible. This in practice means using differential signalling (suggest LVDS) for all interfaces except the very low speed ones (like status LEDs).
Do you know if Atmel offer any device where the USB high-speed PHY can be a separate part? That might allow Demian's point about radiated noise to be taken on board by minimizing the area of circuit able to act as antenna. Otherwise the whole MCU board has the potential to be an EMI aggressor
@borges - you asked about analog power supply. That to be designed without picking a DAC chip first?
What about those Salas ones, they seem to be quite popular. Not that I have used one myself. Then we have the Sjöström Super Regulators by peranders as well - they can do from 2.5V to over 30V. So the should fit to whaterver DAC that is choosen.
Brgds
I posted a really good regulator circuit here:http://www.diyaudio.com/forums/digi...imate-weapon-fight-jitter-11.html#post2710526
Less than 1 nV/rt Hz noise and simple and cheap to implement. The output impedance is not as low as some other designs but the source isolation is really high. It can be "mapped" to negative use and even as a shunt with a little fiddling. Its ideal for crystal oscillators and works well in other applications as long as you understand its limitations.
I'm starting to implement it in some commercial products with good success.
Less than 1 nV/rt Hz noise and simple and cheap to implement. The output impedance is not as low as some other designs but the source isolation is really high. It can be "mapped" to negative use and even as a shunt with a little fiddling. Its ideal for crystal oscillators and works well in other applications as long as you understand its limitations.
I'm starting to implement it in some commercial products with good success.
is there any such thing as a standard Ethernet soudncard at all?
For a network-based option I was suggesting an embedded MPD server, thus using a "de facto standard" protocol (sort of).
some more free suggestions besides the already mentioned good points...
* provide a "DACless AW" board (I2S + S/PDIF + Clock outputs) to ease integration with existing DACs!
This would be very easy to do and IMHO would pay back a great deal in term of project widespread and popularity. People who have recently spent big money on some DIY or commercial DAC would hardly be willing to buy "another DAC"... but they may be more than happy to integrate a state-of-the-art UAC2 interface such the AW with what they already have!
* design a truly "no-compromise", hi-end AW DAC. Use top-of-the line DAC chip (such as ES9018), possibly two of them (one per channel, "dual mono" design) with best possible clocks, indipendent PSUs, etc. No USB power or wall-wart! Use as many internal linear PSUs as required for best SQ.
Agreed. But, as already suggested some time ago, a few auxiliary (no special efforts, just bare functionality) spdif/toslink I/O ports for integration with existing "mid-fi" consumer devices (such as DTVs, etc) would be a nice plus. Of course no one would/should expect "top SQ" from that, but being able to easily integrate common devices with the main audio system would be a nice and useful feature. Needless to say, such a "commodity" feature should only be considered if its implementation does not compromise in any way the overall SQ of the AW when used in its "primary" way (USB-to-analog).
my take would be as follows.
On a dedicated PSU board, put:
* schottky diodes bridge, with R-C (or CCS-C) filter to minimize rectification noise (including current peaks in the power transformer, diodes and first filter cap).
* a simple, low noise voltage pre-regulator
This parts may be common to more than one load (of course you'll need at least two of these with dedicated power transformers if you use galvanic isolation).
Now you have to distribute the power. Use one separed, indipendent supply line for each indipendent load!
Rather than trying to supply costant voltage, having variable currents running all around (=noise, undesired interactions, etc), do distribute constant currents instead!
That is, use CCSs. Use simple but effective ones, based on cascoded high-impedance depletion devices (depletion MOSFETs or JFETs). One CCS for each supply line (that is, one for each load).
Then, on the board(s) where the loads are, as close as possible to each of them (e.g. right on each supply pin of the ICs), convert back to voltage supply using a Zener in parallel with plenty of capacitance (use A LOT of capacitance!).
Last edited:
I understand your concern. Long ago I learned to never connect at a cross for the reasons you mentioned.
The TL431 was added to get a higher accuracy and more stable voltage long term which is why its below the ground.
I need to redraw it so its more understandable. I'll also fold it into a shunt version. I don't have the time to do the spice stuff.
I have attached a quick LTSpice schematic. They did not have a TL431 or equivalent so I used another device to show the connections.
Attachments
I found the LT1431 under opamps but its so different I'll pass on revising the drawing for now.
This regulator is optimized for static loads that need really good low noise DC. It may not be ideal for an opamp that has high dynamic loading (driving a headphone). It may not be possible to meet both requirements (low source impedance and low noise) in one circuit.
This regulator is optimized for static loads that need really good low noise DC. It may not be ideal for an opamp that has high dynamic loading (driving a headphone). It may not be possible to meet both requirements (low source impedance and low noise) in one circuit.
In my experience the radiated noise from the rectifier/cap/transformer network is the hardest to deal with. My best experience uses a complex network in front of the transformer to limit the rate of change of the current through the network (power factor correction). But this requires heavy iron. Buy or make a pick up coil and watch the noise with a scope as you try variations on bypassing and arranging the wires. There is more technique than circuit involved ultimately.
JFet current sources are great but they have gotten more expensive. Linear Systems still sells them. Please use them liberally so they can justify making them still.
that's why I was suggesting to limit and slow down the charge currents adding a series R after the diode bridge (before the first filter cap). In principle using an inductance (inductive input filter) would be even better, but in practice there are also drawbacks. Fortunately in this project we are dealing with relatively little power and can afford to waste more power than we actually use. In higher power application it would be a really hard to solve problem...