Hi guys,
the perhaps easiest way to get galvanic isolation in my latest hardware is to insert optocouplers between the USB-I2S module and the Analog Board it sits on.
To everyone who is new to this project: AB-1.1 is split in two parts. One is a digital module with all the hard-to-solder stuff. It has connectors for USB, I2S and lots of other IO.
The other board is purely for analog things; clocks, power, DAC and audio connectors. We encourage analog hackers to toy with the analog board. Optocouplers and non-VBUS PSU are just some out of many options.
Cheers,
Børge
the perhaps easiest way to get galvanic isolation in my latest hardware is to insert optocouplers between the USB-I2S module and the Analog Board it sits on.
To everyone who is new to this project: AB-1.1 is split in two parts. One is a digital module with all the hard-to-solder stuff. It has connectors for USB, I2S and lots of other IO.
The other board is purely for analog things; clocks, power, DAC and audio connectors. We encourage analog hackers to toy with the analog board. Optocouplers and non-VBUS PSU are just some out of many options.
Cheers,
Børge
Hi all,
1. Isolation - there are no cheap and effectively USB isolation at HiGH speed (480MBPS). Isolation of the i2s signal may be possible. Isolation of the MCLK at 24 or so MHz is also difficult. You will NOT match the <1 ps jitter of the MCLK with our design. All the power supply onboard (digital to uC, digital to ES9023, analog to ES9023, XO etc can be supplied by external psu, eg LifePO4 or Silas shunt selectable via jumpers. We have considerable experience with USB noise (RF and AF) with our companion project sdr-widget where we run an AK5394A ADC with quiescent noise level of < -120 dBm WITH USB power.
So have a listening test of our AB1.1 powered by external power first - u will be surprised by the sound quality - at a cost an order of magnitude cheaper
Having said all these, it may be worthwhile to try the widget with a high quality HIGH speed USB hub, which can block most of the noise from the PC.
2. 7.1 channel 192/24 widget - yes we are designing one.
Alex
1. Isolation - there are no cheap and effectively USB isolation at HiGH speed (480MBPS). Isolation of the i2s signal may be possible. Isolation of the MCLK at 24 or so MHz is also difficult. You will NOT match the <1 ps jitter of the MCLK with our design. All the power supply onboard (digital to uC, digital to ES9023, analog to ES9023, XO etc can be supplied by external psu, eg LifePO4 or Silas shunt selectable via jumpers. We have considerable experience with USB noise (RF and AF) with our companion project sdr-widget where we run an AK5394A ADC with quiescent noise level of < -120 dBm WITH USB power.
So have a listening test of our AB1.1 powered by external power first - u will be surprised by the sound quality - at a cost an order of magnitude cheaper
Having said all these, it may be worthwhile to try the widget with a high quality HIGH speed USB hub, which can block most of the noise from the PC.
2. 7.1 channel 192/24 widget - yes we are designing one.
Alex
Hi guys,
I agree with Alex, isolating the MCLK is not good jitter-wise. The crystal oscillator and its power supply are IMHO the _most_ important analog component. The analog core of clock, DAC and filters must be made together without any noise sources.
But the digital core with MCU and USB interface may very well be isolated from the analog core. One opto isolator option could send MCLK in one direction and remaining I2S lines the other way.
In our AB-1.1 design the DAC is MCLK master and the MCU is MCLK slave and I2S master.
Børge
I agree with Alex, isolating the MCLK is not good jitter-wise. The crystal oscillator and its power supply are IMHO the _most_ important analog component. The analog core of clock, DAC and filters must be made together without any noise sources.
But the digital core with MCU and USB interface may very well be isolated from the analog core. One opto isolator option could send MCLK in one direction and remaining I2S lines the other way.
In our AB-1.1 design the DAC is MCLK master and the MCU is MCLK slave and I2S master.
Børge
So is it correctly understood that the AB clock is "pulling" the correct bit stream out of the computer through the MCU? What happens if the clock is "too fast" on the AB, does it increase pitch of the music?
Hi all,
1. Isolation - there are no cheap and effectively USB isolation at HiGH speed (480MBPS). Isolation of the i2s signal may be possible. Isolation of the MCLK at 24 or so MHz is also difficult. You will NOT match the <1 ps jitter of the MCLK with our design. All the power supply onboard (digital to uC, digital to ES9023, analog to ES9023, XO etc can be supplied by external psu, eg LifePO4 or Silas shunt selectable via jumpers. We have considerable experience with USB noise (RF and AF) with our companion project sdr-widget where we run an AK5394A ADC with quiescent noise level of < -120 dBm WITH USB power.
So have a listening test of our AB1.1 powered by external power first - u will be surprised by the sound quality - at a cost an order of magnitude cheaper
Having said all these, it may be worthwhile to try the widget with a high quality HIGH speed USB hub, which can block most of the noise from the PC.
2. 7.1 channel 192/24 widget - yes we are designing one.
Alex
Hi Alex.
Sounds promising.
You should have the guy called Raytech ( even though he's a bit involved in the Exa project) comparing your device against his modded EXA2UI. Just to see where you're at in the real world.
From my rather limited background I havn't seen any interface which could live up its promises. Perhaps you got the first which does it.
Meanwhile most of the folks around here (after years of following this or that marketing claim) know that (noise) measurements and or buzzwords like aynchronous USB won't tell us everything.
Those little hidden secrets, that nobody is talking about, are usually the limiting factors, which will make the difference.
Anyhow. I'm more than interested to have a look at your device - especially
if it comes to multichannel I2S. Let see when that'll be available.
Cheers
Hi,
That's "YES" on both questions! This is the essence of asynchronous USB.
But the rating of the oscillators on AB-1.1 is quite good. Jitter-wise it is superior to the USB bus. Long-term stability wise it is probably much better as well. So if anything, I belive having the AB "pull" the clock as you say gives steadier pitch.
Børge
That's "YES" on both questions! This is the essence of asynchronous USB.
But the rating of the oscillators on AB-1.1 is quite good. Jitter-wise it is superior to the USB bus. Long-term stability wise it is probably much better as well. So if anything, I belive having the AB "pull" the clock as you say gives steadier pitch.
Børge
We actually try to accomodate the people who are keen on sorting out the hidden secrets (myself included as an old analog hack). The goal is to let the USB-I2S module provide bit-correct digital audio on its own.
Then on the analog side of the fence please try your favourite discrete shunt regulators, class-A output stages, non-oversampling DACs, passive IVCs or indeed any topic on this forum
When hunting for the hidden secrets, I hope it comes as a relief that the analog side controls the clock.
Cheers,
Børge
Then on the analog side of the fence please try your favourite discrete shunt regulators, class-A output stages, non-oversampling DACs, passive IVCs or indeed any topic on this forum
When hunting for the hidden secrets, I hope it comes as a relief that the analog side controls the clock.
Cheers,
Børge
Meanwhile most of the folks around here (after years of following this or that marketing claim) know that (noise) measurements and or buzzwords like aynchronous USB won't tell us everything.
Those little hidden secrets, that nobody is talking about, are usually the limiting factors, which will make the difference.
Anyhow. I'm more than interested to have a look at your device - especially
if it comes to multichannel I2S. Let see when that'll be available.
Cheers
Great, just wanted to be sure. In my mind this is a better approach than to do FIFO reclocking or ASRC.
Does anyone have any experience with how this affect the sound timing when watching videos? Are some players automatically adjusting the rate to accommodate any slight pitch variations between "computer time" and "usb sound card time"?
Does anyone have any experience with how this affect the sound timing when watching videos? Are some players automatically adjusting the rate to accommodate any slight pitch variations between "computer time" and "usb sound card time"?
We actually try to accomodate the people who are keen on sorting out the hidden secrets (myself included as an old analog hack). The goal is to let the USB-I2S module provide bit-correct digital audio on its own.
Then on the analog side of the fence please try your favourite discrete shunt regulators, class-A output stages, non-oversampling DACs, passive IVCs or indeed any topic on this forum
When hunting for the hidden secrets, I hope it comes as a relief that the analog side controls the clock.
Cheers,
Børge
To me above thinking incorporates a big mistake.
Jitter sources must be avoided as far upstream as possible. Jitter, noise, intermodulations, power variations asf accumulate to a big mess the
further downstream you go.
Leaving it up to downstream devices to get the mess fixed later on is IMO the wrong thinking. The further downstream you go the more complex it gets to clean the mess up.
If your interface just offers a naked I2S you'll blow all the mess into the downstream DAC. That wouldn't work if I just hookup a TP Sabre or similar. The I2S signals you provide need to be
as perfect as possible.
Not any usb device I'm aware of, I'm honestly not sure if there's any, has managed to decouple from the incoming USB stream related mess.
It's been proven a million times that optimzations on the PC side (my key area of involvement), which is also an example for upstream improvements mentioned above btw, do have an impact
even on asynchrounous USB DACs.
Those PC related optimizations (I've been doing it for years on Linux environments / SB Touch) relate to getting the load down on the PC side, giving USB stream related processes high exlusivity, improving power supplies, running realtime kernels on the PC side asf asf...
The key issue is and was that the USB interfaces were not able to get rid of those little variations (logical and physical), which go beyond that bit-transparancy discussion ( which used to be a hot topic 4-5- years ago).
Bit-transparency is the least of all problems nowadays. It used to be much higher on the priority list. If you ask me, people had to find something that could be blamed for the bad sound quality we all experienced on earlier USB interfaces. Luckily somebody invented "audiophile" PC setups and players, to get around the still existing USB audio interface limitations. No. I'm not talking midfi stuff like EMU or similar being affected.
I'm talking about mega bucks audiophile USB audio interfaces such as Wavelength, Ayre you name it, which respond to those kind of optimizations. All those manufaturers still use Amarra or similar to present their interfaces for a good reason.
Next time at RMAF you should ask those manufacturers to use standard iTunes - which is also bit-transparent - just to see what's actually in charge for the sound quality. Audiophile PC setups do obviously have a much higher impact on lower quality devices.
Anyhow:
If you guys tell me that applications like Pure Music or Audiophilio on a MAC, Fidelizer+JRiver+Wasapi/Wasapi Event Style or XXHighend on a W7 or any other well known PC sided optimizations (I could even try your interface on my modded Squeezebox Touch which runs a standard Alsa driver with asynch USB being supported btw.) won't make a difference compared to normal audio applications and PC setups on your design, I'll place an order immediatly to check that out !!!
Let me know if you think it's worth to hand in an order. I'd love to.
Cheers
Last edited:
The PC side driver and music playback software make a difference to the Sound Quality.
One key issue is to avoid any re-sampling by the PC. If the source material is in 88.2khz/24bit, then it has to be transferred via the USB as 88.2khz audio. Many PC programs re-sample the music to another sample rate before presenting to the USB. For example, in Linux pulseaudio, the pulse server runs at a FIXED sampling rate when the pulse server is started. If music is played back through pulseaudio (which is the default used by many Linux music player programs and movie players etc.), then any source that is NOT the same as the FIXED sampling rate gets automatically resampled -> loss of SQ. So far I have only found MPD to be able to faithfully avoid resampling under Linux, if you specify auto_resample "no" in .mpdconf. I'm sure there are similar gotcha's under OSX and Windows.
The other issue is the audio driver. You need USB Audio Class 2 drivers to work well with rate feedback. UAC2 is only available under OSX snow leopard or later, and Linux kernel 2.6.37 or later. Under Windows, you need proprietary uac2 drivers. We have tested experimental uac2 drivers under Windows and many Windows music players have poorer SQ compared with Linux. There is only one - the "minimalist" player, that plays back as good as Linux.
As Borge said, we encourage experimentation and testing. There is no need to argue based on theoretical considerations. Try the widget. Design and build you own Analog Board to mate with our USB-I2S module. The widget is under US$200 including shipping, and the USB-I2S module is well under $100 We do not claim that it will outperform the big boys costing thousands of $. How close is the SQ to the big boys - that is for you to find out
Alex
One key issue is to avoid any re-sampling by the PC. If the source material is in 88.2khz/24bit, then it has to be transferred via the USB as 88.2khz audio. Many PC programs re-sample the music to another sample rate before presenting to the USB. For example, in Linux pulseaudio, the pulse server runs at a FIXED sampling rate when the pulse server is started. If music is played back through pulseaudio (which is the default used by many Linux music player programs and movie players etc.), then any source that is NOT the same as the FIXED sampling rate gets automatically resampled -> loss of SQ. So far I have only found MPD to be able to faithfully avoid resampling under Linux, if you specify auto_resample "no" in .mpdconf. I'm sure there are similar gotcha's under OSX and Windows.
The other issue is the audio driver. You need USB Audio Class 2 drivers to work well with rate feedback. UAC2 is only available under OSX snow leopard or later, and Linux kernel 2.6.37 or later. Under Windows, you need proprietary uac2 drivers. We have tested experimental uac2 drivers under Windows and many Windows music players have poorer SQ compared with Linux. There is only one - the "minimalist" player, that plays back as good as Linux.
As Borge said, we encourage experimentation and testing. There is no need to argue based on theoretical considerations. Try the widget. Design and build you own Analog Board to mate with our USB-I2S module. The widget is under US$200 including shipping, and the USB-I2S module is well under $100 We do not claim that it will outperform the big boys costing thousands of $. How close is the SQ to the big boys - that is for you to find out
Alex
The PC side driver and music playback software make a difference to the Sound Quality.
One key issue is to avoid any re-sampling by the PC. If the source material is in 88.2khz/24bit, then it has to be transferred via the USB as 88.2khz audio. Many PC programs re-sample the music to another sample rate before presenting to the USB. For example, in Linux pulseaudio, the pulse server runs at a FIXED sampling rate when the pulse server is started. If music is played back through pulseaudio (which is the default used by many Linux music player programs and movie players etc.), then any source that is NOT the same as the FIXED sampling rate gets automatically resampled -> loss of SQ. So far I have only found MPD to be able to faithfully avoid resampling under Linux, if you specify auto_resample "no" in .mpdconf. I'm sure there are similar gotcha's under OSX and Windows.
The other issue is the audio driver. You need USB Audio Class 2 drivers to work well with rate feedback. UAC2 is only available under OSX snow leopard or later, and Linux kernel 2.6.37 or later. Under Windows, you need proprietary uac2 drivers. We have tested experimental uac2 drivers under Windows and many Windows music players have poorer SQ compared with Linux. There is only one - the "minimalist" player, that plays back as good as Linux.
As Borge said, we encourage experimentation and testing. There is no need to argue based on theoretical considerations. Try the widget. Design and build you own Analog Board to mate with our USB-I2S module. The widget is under US$200 including shipping, and the USB-I2S module is well under $100 We do not claim that it will outperform the big boys costing thousands of $. How close is the SQ to the big boys - that is for you to find out
Alex
Hi Alex.
I've been around for a while. I you feel bored you can have a look at my Linux Audio Thread in the PC area over here.
I do consider myself one of the very early people that have shown the impact of PC based optimizations on audio devices.
I'm not refereing to resampling, volume controls, playback software which changes the actual data that makes the difference btw.
Those I take out of consideration, since the negtive impact of those is more than obvious.
Believe me, I tweaked Linux, the (rt-)kernel and MPD, ecasound and more years back and other stuff like the Squeezebox nowadays - which is IMO one of the best Linux based transports - quite heavily.
In the end I pretty much got tired of that never ending story. And it is a never ending story, unless
---
and here's my conclusion:
Provided bit-transparent data are delivered, the audio interface must
not show any differences in sound quality at whatever PC/Transport based
setup feeding it.
That should be the ultimate goal of any interface designer.
100% decoupling from PC induced mess is the goal. Not any device I'm aware of can manage this.
If a device can't manage that stay away from it.
---
The impact of different samplerates, resampling asf. I consider a different subject.
Cheers
Last edited:
Any data manipulation or filtering is causing losses.
Resampling:
Assume your DAC device resamples everything to 192khz.
It might be the case that the resampler on the PC works better
than your DAC device.
Though if you use the wrong resampler or the wrong options for the resampler it might sound worse. Resampling is an art on its own.
Next you'll see the differences between offline sampling and realtime sampling.
Hmmh. Offline sampling sounds better than realtime sampling!?!?!
Now you might start resampling your entire collection for best sound.
You like it? Hmmh. At least for now.
On the next DAC which accepts native 44.1/16 and won't resample to 192/24, 44.1/16 might sound better then your upsampled stuff. Bad luck.
(Hint: Always keep a copy of the originals.)
Now you can get a copy of native 192/24 master material of that
very same disc. Surprise, surprise. It sounds better than your PC offline upsampled material. Hmmh. You like it? Go for it.
Two obvious reason for that. If we talk about the real 192/24
master, your 44.1/16 copy faced serious losses during the
downsampling process. Beside the actual resampling you'll see
attenuation being applied to avoid clipping and dither being applied.
That's not nice.
Of course there another reason. Todays HiRes, typically 24/96, stuff is usually "remastered" stuff. Many of them are DSD copies or tape copies
transfered to PCM. Yep. They usually still talk about masters.
That remastering makes a huge difference on it's own.
People compare 44.1/16 material mastered in the eighties with remastered 24/96 stuff done 2 months ago on DACS which resample to 192khz.
That won't work. What are we comparing here!?!?
Oh man - what's next in that jungle?
All that is more than exhausting and much too complex to get a definite answer.
I think we had a great time when just throwing in those little silver disks
into our CDPs and just enjoyed what's got delivered.
Sorry to be a little off-topic here.
Hi Soundcheck,
You have some good points there. My background is as an analog and embedded guy. When I program I rarely need a task switcher and an OS. So maybe I'm just assuming the PC side of things is more perfect than it actually is.
I'd like to have you on the team. Mainly because we well use some more input on "tool chains" of players, drivers etc, particularly on Windows. Pluss I wouldn't mind selling you some hardware
You won't have a hard time convincing me that a modern computer has lots to do and that it may not feed the USB perfectly. Please enlighten us on how to get the best out of it.
But when it comes to analog things I'm quite certain the core analog parts (DAC and clock) should be tight together. The MCLK edges are used for internal latching inside the DAC, not the other I2S signals. And as long as I2S word clock, bit clock and data bit have the right edge/update relationships - and are synchronous with MCLK - we should be safe. This is my experience on ES9023 an PCM1704.
Cheers,
Børge
You have some good points there. My background is as an analog and embedded guy. When I program I rarely need a task switcher and an OS. So maybe I'm just assuming the PC side of things is more perfect than it actually is.
I'd like to have you on the team. Mainly because we well use some more input on "tool chains" of players, drivers etc, particularly on Windows. Pluss I wouldn't mind selling you some hardware
You won't have a hard time convincing me that a modern computer has lots to do and that it may not feed the USB perfectly. Please enlighten us on how to get the best out of it.
But when it comes to analog things I'm quite certain the core analog parts (DAC and clock) should be tight together. The MCLK edges are used for internal latching inside the DAC, not the other I2S signals. And as long as I2S word clock, bit clock and data bit have the right edge/update relationships - and are synchronous with MCLK - we should be safe. This is my experience on ES9023 an PCM1704.
Cheers,
Børge
absolutely...
is there any chance this solution will be included in a future release of AB?
Hi Soundcheck,
You have some good points there. My background is as an analog and embedded guy. When I program I rarely need a task switcher and an OS. So maybe I'm just assuming the PC side of things is more perfect than it actually is.
I'd like to have you on the team. Mainly because we well use some more input on "tool chains" of players, drivers etc, particularly on Windows. Pluss I wouldn't mind selling you some hardware
You won't have a hard time convincing me that a modern computer has lots to do and that it may not feed the USB perfectly. Please enlighten us on how to get the best out of it.
But when it comes to analog things I'm quite certain the core analog parts (DAC and clock) should be tight together. The MCLK edges are used for internal latching inside the DAC , not the other I2S signals. And as long as I2S word clock, bit clock and data bit have the right edge/update relationships - and are synchronous with MCLK - we should be safe. This is my experience on ES9023 an PCM1704.
Cheers,
Børge
If you follow up the SD-Card player stories (these guys IMO push the limits) you'll realize that those players work best if just one clock is used.
ec-designs clocks the pic with the same clock as the DAC and Bunpei with his Micro-SD player recommends to just take the MCLK of the transport and to get rid of the DAC clock (external TP Sabre if I recall it correctly). Somehow slightest clock interferences obviously should be avoided for best sound.
PC setup:
If you want to achieve a close to reference sound from a Windows 7 system, you might try below 20 minutes exercise:
1. Install and run Fidelizer.
Fidelizer turns a lot of non relevant processes and system services off.
It changes task and scheduler priorities asf asf. It also turns network, firewall, wlan asf off.
2. Install the test version of J.River Media Center 16. Look for the latest built in the JRMC forum. Install that one over the base installation.
You enable full ramplayback and W7 wasapi exclusive mode.
The USB driver might even support wasapi event style, which was
developped having asynch. USB devices in mind.
3. Then you avoid realtime flac conversion. Either you run native .wav
or decode your flacs prior to playback.
If all that won't make a difference on your setup compared to a standard player your USB device is doing quite a good job or your systems resolution is not top notch.
At that point nothing was done to the actual data. Just system optimizations were applied.
On a Linux system
1. You install a realtime kernel ( checkout liquorix) and latest Alsa and
throw out Pulseaudio. Latest Alsa you can install by using the Alsa Upgrade script I developped some time back which you should find at Ubuntu forums.
2. You install ecasound
3. You boot into recovery mode (that one got most of the processes off)
4. You copy your flac or wav to /dev/shm or any other tmpfs.
5. Decode your flac first
6. As root you run e.g. ecasound -q -b:rt -r:90 -i:/path/file.wav -o:alsahw,0,0
If you want a little player script for all that Linux playback let me know.
If I had an interface in my hand I could test it also on a tweaked Squeezebox Touch, to see if it works at all and if my SB tweaks make a difference.
As I said earlier. I'm actually interested in a USB based multichannel device. Don't count me in for your project. I can get you some hints as done above. That'll be it.
I'm still actively tweaking the SB Touch. And there are a couple of hundred people waiting eagerly for my Touch Toolbox 3.0.
For stereo playback I'll stay with my SB Touch. I still havn't seen any other solution which beats that solution on price/performace ratio, usability (iPad control) ,
community support and more. You should notice that the audio interface is just a little part of a complex solution.
Cheers
Last edited:
Hi Soundcheck,
thanks for your input! Any opinion on different Windows UAC2 drivers?
Børge
thanks for your input! Any opinion on different Windows UAC2 drivers?
Børge
