Open-source USB interface: Audio Widget

[borges]

USB is the most obvious interface. It allows data and clock to travel in opposite directions. Its main drawback is the lack of Windows drivers.

My hope is that one day soon an audiophile Windows USB expert joins our efforts :-)

Alex does have some good points. The project is mainly for hackers. But it is possible to buy a kit which which plays out of the box and needs no technical interaction.

Børge

[Turbon]

Originally Posted by counter culture

I think this is an unfortunate line to take, there's plenty to indicate that 44k1/16 is perfectly adequate and that a 'superior SQ' is not achievable.

To describe somebody who is 'satisfied with ... 44.1/16 CD quality music' as a 'casual user' is to denigrate the judgement of the many users and professionals who have assembled and weighed up the evidence in a far from casual manner.

Doubtless, superior paper performance is achievable, and a performance margin is desirable, but encouraging people to believe that an audible superiority is achievable is to fly in the face of the available evidence.

I've thought a few times about offering assistance to what has appeared to be a very worthwhile project but I'm certainly not encouraged to put my skills behind a development driven by ideology. To my mind the purpose of a device such as the audio widget would be to put audible differences beyond question, not to encourage further in-fighting and an overkill 'arms race' in an already confused and confusing arena.

Please Counter Culture - don't count yourself out. There will allways be all kinds of animals under the heavens - and it's OK - it help's to keep things dynamic in a groupcontext. I have lots of ordinary CD's which are of very good quality and I have also lots that is of lesser quality. The lesser ones are perfect as remastering candidates - If and when time is given (or taken sometimes). I have only done two so far but I got them to sound fine to me - sorry for the slight OT...

There will allways be different camps but as long as the discussions are kept on topic and that everyone understands that UAC2 implementationwise is a moving target - this will undoubtly be an succesful project.

Brgds

[rsdio]

Originally Posted by borges

USB is the most obvious interface. It allows data and clock to travel in opposite directions. Its main drawback is the lack of Windows drivers.

My hope is that one day soon an audiophile Windows USB expert joins our efforts :-)

FireWire Audio also allows data and clock to travel in opposite directions. An advantage that FireWire has is that it is peer to peer, rather than host to device, so you can sometimes connect devices without a computer. There's even the possibility that FireWire could replace SPDIF in this aspect as a component to component audio transport.

I have no idea what the driver situation is like for Windows, though.

[UnixMan]

Originally Posted by rsdio

it would be interesting to create a board that has all three (USB, FW, EN), even though that would be even harder.

sure, it may be interesting to do something like that (definitely it would be a big technical challenge...). But, from a practical point of view, I don't quite see the point on doing that.

To our purpose, USB and FW would be practically equivalent. AFAICT, any machine which has an FW interface also have some USB ones too. Unless windoze have native drivers for async FW audio (does it? I doubt), we would need a driver anyway. So what would be the advantage?

Besides, IMHO FW is kind of vanishing, if not dead already.

FW400 was about on par WRT USB2, which is cheaper and simpler (and way more common). With USB3 already around, even the newer (and rare) FW800 has become basically useless. Apple Mac was about the only architecture which were kind of "pushing" for it. But recently I've even seen new Macs which does not have any FW port (e.g. the "air").

Thus, IMHO developing an FW interface would be just a waste of time and effort.

A network (Ethernet and possibly WiFi) based device would be a different story. Yet it is extremely simple to get some small and cheap "SBC", install Voyage MPD on it (on an SSD or other small SS media) and plug in an USB AW to it...

Of course, one may consider the possible advantages (and disadvantages) of having some kind of SBC directly producing the data stream for the DAC, avoding the extra interface, ecc.

[1audio]

I see a lot of assumptions but fewer facts flying here.

I2S standard can have the clock originate at either end per the spec. Its the implementation that is a limiter.

AES and SPDIF can be locked to an external clock. Word Clock is used for that commonly in professional applications where several ADC's need to be locked to a common clock. You can spend a fortune on fancy word clock generators. It becomes unmanageable with a mixed sample rate playlist.

The AB 1.1 could be isolated pretty easily at the I2S end. Hardware to do it at the PC end really doesn't exist yet. I'm told that there will be a USB2 isolation solution from ADI next year. Probably expensive and hard to get. I would use transformers for master clock and bit clock and opto's for word clock and data. I would resync the data returning at the dac chip with a fast D latch so the edges are all within spec for the DAC chip.

This would be a re-layout and to get benefit you need separate isolated supplies on each side of the isolation barrier and very careful layout to minimize the coupling from input to output. Putting the MCU and isolation stuff inside a floating can with a double shield may be the best and the hardest to do.

When you are comparing different PC's keep in mind that they well might be radiating a lot of noise and no physical connection is required to degrade the sound. It has been many years since we have had EMI and RFI free listening spaces so introducing a new source of EMI may be less obvious. I have had experience where digital displays (LED's etc) have made obvious degradations in sound even though they are not connected in any way to the audio system.

Adding a mix of ferrite and steel around a USB cable would increase the common mode impedance and should make an audible difference. Not too difficult to try.

[rsdio]

Originally Posted by 1audio

I2S standard can have the clock originate at either end per the spec. Its the implementation that is a limiter.

I do not doubt you, but where is this written down? Can you cite a reference?

AES and SPDIF can be locked to an external clock. Word Clock is used for that commonly in professional applications where several ADC's need to be locked to a common clock. You can spend a fortune on fancy word clock generators. It becomes unmanageable with a mixed sample rate playlist.

Read the white papers from Dan Lavry. Due to the complications of interconnects, no external clock can outperform a properly designed internal clock. It's a matter of physics. Granted, when you have more DAC channels than will fit in a single chassis, you must have at least one set running on external clock if they are all to be locked together. That's a common situation in studios with 32 or more channels. But for the purposes of stereo or basic multichannel surround, sound quality is going to be much better when a properly design internal clock is used.

[alexlee188]

Are there "standard" drivers with rate feedback for Ethernet soundcards?

Alex

[rsdio]

I'm not saying that the open-source USB interface should be modified to add FireWire. I'm merely pointing out that FireWire is a viable option. It's probably not practical, but it's certainly technically possible.

Originally Posted by UnixMan

Besides, IMHO FW is kind of vanishing, if not dead already.

There have been several new audio products released this year alone which are exclusively FireWire. People have been saying that "FW is vanishing" for a decade or more. So far, it hasn't come true.

FW400 was about on par WRT USB2, which is cheaper and simpler (and way more common). With USB3 already around, even the newer (and rare) FW800 has become basically useless. Apple Mac was about the only architecture which were kind of "pushing" for it. But recently I've even seen new Macs which does not have any FW port (e.g. the "air").

There is more to an interface than the raw clock rate. FW400 far exceeds USB2 because of the nature of the data, particularly the fact that in FW isochronous data gets assigned specific clock cells where in USB there is just a vague idea that the host should fit the data in "somewhere" in the frame. The reason that FW handles this more precisely is because it is a peer-to-peer interface, and cannot rely on the concept of a "host" to have full control over all timing. USB3 is even rarer than FW800 when you consider that there are no USB3 audio interfaces and there isn't even a specification for USB3 Audio Class devices. USB3 is nothing but a combination of USB2 and ESATA wires coiled into the same cable, which does nothing to make it compete with FW800 in terms of real performance. At least FW800 audio interfaces exist and work with all audio software.

As for Apple, they periodically introduce lower models that do not feature FireWire, but the top, pro models always have FireWire. The Air is a space-constrained product targeted for people who aren't even doing audiophile music, so the lack of FW makes perfect sense. The Air doesn't have an optical drive, either, which is the most common physical medium for audio.

I do agree that USB and FW are basically equivalent for the purposes here. I just want to be clear that for every disadvantage that FW has, there is a bigger disadvantage with USB.

[abraxalito]

Originally Posted by borges

In keeping with the nomenclature above, the USB-I2S module is not a "push interface". The clock generators on the analog board are located right next to the DAC. This means MCLK goes from the analog side to the digital while the other I2S signals go from the digital side to the the analog.

I see - thanks for the clarification. I'd just suggest then that the lowest frequency needs to be sent back from the DAC -> uC, not the master clock. Not all DACs have MCLKs (PCM1704 comes to mind) - how about just sending a word clock or the BCLK?

So my idea, although not yet implemented, is to use optos from AB to module for MCLK and from module to AB for I2S. Adding a bit of jitter to the clock seen by the MCU isn't such a big deal, I _blieve_. But adding jitter to the DAC is absolute taboo.

So optos should work fine, choose optos which are just fast enough to keep power and cost down.

Making the DAC board the clock master makes the most sense from the point of view of jitter. But this does rather force multi-channel solutions to be all on the same board. There's no chance of adding on extra channels afterwards as its impractical to have more than one clock master in a system. Do you intend to produce boards in various numbers of output channels?

[abraxalito]

Originally Posted by rsdio

The easiest point to break the loop should be PC-to-USB, since the data lines are differential and the power is optional. It seems like the safest choice is to not even connect the traces from USB jack for Vusb and GND.

As Demian points out, such a solution running at 480Mbits/s is not yet available, and even when it becomes avaiilable may well be cost-prohibitive. If I were doing the design I'd be looking at powering the PHY from the PC's USB supply and seeing if it were possible to isolate the ULPI between PHY and uC. But I've not looked at the details - of course this could only work where the USB PHY isn't on-chip.

I personally prefer balanced audio, even with a DAC output, so that affords another opportunity to break a potential ground loop. Balanced outputs connect ground for shielding purposes, but proper balanced inputs should not connect the ground at all since the signal is differential and doesn't need a reference to ground. Thus, you can also break the DAC-amp ground.

This isn't quite correct. A professional (XLR) balanced connection does indeed connect pin1 (which is the GND). This is to control the common-mode voltage. Only a transformer isolated balanced feed can operate with no ground connection at all.

Between these two easy options, it should be fairly simple to avoid ground loops. Designing an audio grade power supply will be less easy in comparison.

In my view the opposite - its the system level considerations which are hardest because so many variables are outside the designer's control (common-mode voltage and common-mode interference being just two). Totally self-contained designs (like power supplies) in comparison are relatively easy.