Open-source USB interface: Audio Widget

Jump to Latest
oneoclock

oneoclock

Member
Joined 2010
Jitter J-test

Thanks for the work you do. It's great.

I want to collaborate with measures of jitter. J-test 44,1k 16b file:

An externally hosted image should be here but it was not working when we last tested it.

UAC1 Win7 Windows Media 44,1k 24b.

An externally hosted image should be here but it was not working when we last tested it.

UAC2 MAC iTunes 192k 24b

An externally hosted image should be here but it was not working when we last tested it.

UAC1 Win7 Windows Media 44,1k 24b.

An externally hosted image should be here but it was not working when we last tested it.

UAC2 MAC iTunes 44,1k 24b


An externally hosted image should be here but it was not working when we last tested it.

UAC2 MAC iTunes 192k 24b
 
UnixMan

UnixMan

Member
Joined 2005
audiofaidate.org
johnm said:
UnixMan: Interesting - I'll try that. In regards to the supply lines, do you mean cap positions: C21/31/28?
Click to expand...
See previous posts. Replace all of the 5 OsCon el. capacitors, plus add some of the "missing" (optional) ones: C15, C21, C31, C32, C33, C35 and C36/C37. Be careful not to damage the PCB when desoldering the old caps!

You may also try the suggested value on the (optional) C34, but IME it did not make much of a difference so I'd leave it out.

Currently I'm using what you can see in a previous post ('cause that was what I had at hand at the moment), minus C34 that I have later removed. Although it is sub-optimal, it was already a sensible improvement in the right direction (same one you'd like).

I believe that the small sized 6.3V silmic IIs should be a good (and relatively inexpensive) solution for this board. You can try using 220uF everywhere (they should fit in the same places foreseen for the small OsCons on the PCB). Not tried them yet, though.

Nevertheless, "thin", "too dry" and "edgy" are IME quite typical characteristics of the sound you get (almost) wherever OsCons are used for audio. I'm quite confident that higher capacitance (more energy storage, lower Xc @ low frequencies...) together with the usually warmer, fuller and smoother sounding silmics IIs will do the trick! ;)
 
B

borges

Member
Joined 2003
Hi Starn02,

could you please try the track from my post 748 with the newest firmware? I was having some problems with that today, but didn't have the time to finish debugging. It would be interesting to see if it plays flawlessly and with correct word clock on other people's systems.

Børge

starn02 said:
My "extremely personal" experience with WinXP and "custom made" UAC2 drivers .... and with foobar2000: everything is OK, sample rates are all accepted and played without problems. Sound quality is constantly high, with hard to hear differences when upsampling (with SOX plugin) from 44.1 to whatever else.

"Reasonable" behaviour (not perfect, some little delay and sometimes hic up, but perfectly tolerable) when switching songs, and even when changing the upsampling rate while playing.

From what I read (on the forum) and see (on my setup) the firmware should be quite OK since the versions of Chrystmas .... if you have so much problems maybe the reason is in the PC / OS / driver ....
Click to expand...
 
oneoclock

oneoclock

Member
Joined 2010
UnixMan said:
perhaps there's an error in picture labeling? :cannotbe:
Click to expand...
I do not know what is wrong?

Maybe it's because I write in English incorrectly. :(

File Jtest 44.1 Kbit 16 bit.
Windows 7.
Foobar2000 program v.1.1.10
Device (24b): WASAPI: (DG8SAQ-I2C)
DSP manager: SoX 48k resample

An externally hosted image should be here but it was not working when we last tested it.


other measures:
An externally hosted image should be here but it was not working when we last tested it.

Windows 7.
Foobar2000 program v.1.1.10
Device: DS: (DG8SAQ-I2C)
DSP manager: SoX 48k resample.

Best measure in MAC and WinXP.
 
1

1audio

Member
Joined 2004
Paid Member
Windows workaround - Possible?

The Windows problem is lack of an opensource driver. Perhaps we could "package" a Linux player and small Linux distro so that it could run in a virtual box inside Windows. The big roadblock would be whether Windows would get in the way of the hardware access. Otherwise it may be possible to package a mini Voyage MPD in a way that it would run inside Windows as a virtual session. The UI would still be on the Windows side.
 
UnixMan

UnixMan

Member
Joined 2005
audiofaidate.org
borges said:
any specs on the cable you're using?
Click to expand...
no, sorry. I had it laying around, may be from some external HDD or photo camera. But other people have had similar results with different cables or even adding "crimp-on" ferrites to cables which did not have it. I guess anything that's able to reduce the common mode noise will do. One may also try to wound the USB cable for a couple of turns around a ferrite donuts.

Perhaps whe should suggest to "Cablerie d'Eupen" to start producing USB2 cables with their special "EMC/COM" compound... :D

KABELWERK EUPEN AG
 
Last edited:
S

starn02

Member
Joined 2005
borges said:
Hi Starn02,

could you please try the track from my post 748 with the newest firmware? I was having some problems with that today, but didn't have the time to finish debugging. It would be interesting to see if it plays flawlessly and with correct word clock on other people's systems.

Børge
Click to expand...

I can confirm that on my Win XP with UAC2 everything is OK! I tested with the file you indicated.
Perfect reproduction at 96 and 192k. Also fast forward and rewind work flawlessly at any rate (always in foobar 2000 1.1.10).

I can also add that:
- my PC is actually a 11" notebook from Acer, with ULV CPU, so no much horsepower here, but the CPU stays at 2 - 6% even when upsampling
- everything was ok even with a 800KBPS download from 2L in background ...

Even if you switch on and off the resampler while playing there are no strange noises, only a very small silence (0,1 sec) and then music again. Perfect.
 
oneoclock

oneoclock

Member
Joined 2010
borges said:
Hi John,

Try removing R26 and feed your +5V to pin 2 of J5. Then your supply powers the entire Audio Widget.

Alternatively, remove L2 and put your supply to the + pin of C21 to power the DAC. Or remove L1 and put your supply to the + pin of C31 to power the XOs. These two may be combined.

There are numerous I2S to SPDIF converter chips. You'll have to patch such a device onto the analog board or module. This should be fairly doable, the largest challenge probably being the pinout and control of the converter chip.

Børge
Click to expand...
I want only replace power supply AVCC and VCC-XO.

If you remove L2 and put supply to pin C21 you do external power analog DAC supply.
If you remove L1 and put supply to pin C31 you do external power clock supply.
Yes, but through ADP151 regulators.

Remove R23 and put supply to connector J4 analog DAC supply.
Remove R22 and put supply to connector J3 clock supply.
This put power supply to DAC and clock without through ADP151 regulators.

What is the function of pin 3 EN ADP151 regulators?
What is the function of J2 J3 and J4 connectors?

I think that putting 3.3 V. on connector J2 ADP151 regulators off (ADP151 EN pin 3).

And you can put external power supply to J3 and J4 without desoldering components R22 and R23, or L1 and L2. And without through ADP151 regulators. It's easier.

Thank you very much for your help.
 
S

sampler

Member
Joined 2010
mvaudiolabs.com/
1audio said:
The Windows problem is lack of an opensource driver. Perhaps we could "package" a Linux player and small Linux distro so that it could run in a virtual box inside Windows. The big roadblock would be whether Windows would get in the way of the hardware access. Otherwise it may be possible to package a mini Voyage MPD in a way that it would run inside Windows as a virtual session. The UI would still be on the Windows side.
Click to expand...

That's exactly my thoughts too, but from lack of responses it's seems no one has tried that yet. Theoretically this sounds doable and would enable at least some uac2 support for higher sample rates without hacking 3d parity drivers of other vendors. Borges, UnixMan, anyone ?
 
B

borges

Member
Joined 2003
Hi Oneclock,

The EN pin is to enable/disable the regulators. It will play a role for USB power down. It is called VBUS_EN because it determines wheter or not additional points of load from VBUS may be in use.

J2 is a future upgrade power sense by which the MCU may learn something about an external power. It is connected to an ADC pin of the MCU.

J3 and J4 are for bypassing the ADP151s. Or for tapping their output to whatever you choose to patch onto the board. Remove R22, R23, respectively, for bypass.


Børge
 
B

borges

Member
Joined 2003
Driver Convergence

Hi guys,

I'm sensing the same kinds of thoughs on a lot of different channels here: screw the driver, let's make a VM. This we can do!

I'm all for it! There is much more Linux knowledge than Windows knowledge in our group. Here are some loose thoughts. Let's bring out our ideas first before we start cutting them down. Do pardon my lack of proper lingo...

- Which VMs are available with sensible licenses?
- Will a VM forward a raw USB port not supported by the host OS?
- A "driver" should be split in multiple parts/layers to make it portable and
spread out our efforts
- UAC2 hardware interface on (realtime?) stripped-down Linux kernel
- Target "HW" is VM on host, lowcost Linux box in stereo kit, eventually
Android phone
- GUI over httpd to put it on browser or player plugin
- GUI may be pyisically separate from player kernel
- Audio data over streaming or mounted fs
- Player program(s) installable and accessible through X/ssh
- We might even make a Windows ASIO driver which talks to the VM :)

I want to hear your ideas too before we start eliminating and straightening things out!


Børge
 
oneoclock

oneoclock

Member
Joined 2010
UnixMan said:
I see two different pictures with the exact same label... what's the difference between the two? :confused:
Click to expand...

What I made ​​is two types of details in the measurements. One covers 20 to 20 kHz and another one of 9 kHz to 13 kHz. The label is program and settings used.

The J-test signal is Explained here:
http://www.nanophon.com/audio/diagnose.pdf

I use J-test 44.1 khz. 16 bit. It is a tone of 11 kHz at -3 dBFS over a square wave of 1 bit to 229 hz with many harmonics.

The best measure of Jtest that I have is Hiface Buffalo DAC and has an analog output + 3 dBu in the spectrum analyzer.

In absolute values ​​for hiface images should have a scale of 6 dB less.

An externally hosted image should be here but it was not working when we last tested it.

Jtest: Hiface+ Buffalo DAC

AB-1.1 has output + 5 dBu. It should come down 8 dB to absolute values.
 
Last edited:
oneoclock

oneoclock

Member
Joined 2010
AB-1.1exceptional measures. In AM700 Tektronix spectrum analyzer similar measures to Benchmark DAC1 USB and Hiface + Buffalo USB DAC.

All DAC I measure, have many differences in quality between programs with default setings.

This DAC with proper program settings, all programs measures identically, as well as Hiface work. It works really asynchronous.

In other DAC, is always very big differences one program to other in quality when the clock is provided by the PC and there are only DAC PLL clock.
 
johnm

johnm

Member
Joined 2003
I've attached an external 5v supply to J5. Nothing exotic just a Black Gate 1000uF 50v cap before and after a 7805 OnSemi regulator. MUR860 rectifying diodes. Too early to tell yet if it's made a day and night difference - need to dosome serious listening tomorrow. It's allstill working fine however and doesn't sound any worse ;)

A very Happy New Year to you all folks :D

John
 
You must log in or register to reply here.
Top Bottom