Open-source USB interface: Audio Widget

oh, its a flaw in their design, but the saving grace is that you can buy or keep rj45 cables as spares and they cost less than the gas it takes to drive to buy it ;)

hey, I'd even be ok with a db25 and pairs that are twisted. now THAT's a secure connector that just plain works, is nicely keyed, is available everywhere, there are 1:1 cables and extensions around, its diy friendly and so on. its a bit big but a db25 would be able to support this, I'd bet. box to box distance is, what, a few feet? we're not talking long haul or across the room or room to room. a few feet of wet noodle would carry current and could be made to work if you try hard enough on both ends ;)

hdmi, for its high speed, is a good one to consider. but it has a lot of non-love going for it and I'm not sure it would be #1 in my list to try out. maybe #2 or #3, even.

what about dvi? its also all the benefit of hdmi AND its nicely bulky and locking. and you can get cables, etc, etc.
 
Member
Joined 2004
Paid Member
HDMI has its problems but there are over two billion HDMI connectors in products in service so it can't be that bad. I have not encountered fried HDMI inputs not that its impossible, it just doesn't happen very often. I'll try to show you some of the HDMI connector options when we next meet. I have a solution that gets 10 Gbps over a 1/8" cable. Its amazing what happens when there is a lot of money to be made.

I'm getting statistics on HDMI cable failures.
 
if we truly needed such speed, then hdmi would probably be one of the few choices for existing cable and connector types. but I'd want to know that cat6 or similar thru an MJ just won't work or works poorly. I'm not so sure rj45's are unusable for audio. if the driver circuitry needs to be smarter to drive it vs hdmi, I still think its a win.

btw, something to think about when using existing connector types for very different purposes: what will happen if someone plugs this device into a real hdmi or ethernet system? can we pick wires such that minimal or no harm is done?
 
Member
Joined 2004
Paid Member
Using the LVDS driver will not harm an HDMI receiver or transmitter so that is not an issue. The RJ45 connections are shorted through the transformers on each end of an Ethernet link. If power over Ethernet is implemented its "unpredictable" what will happen.

If you want to go nutso use Infiniband cables. 4 high speed paths each way. 40 Gbps for the number freaks and optical options. . .

My vote, especially given the upswing I'm seeing in the I2S over HDMI starting with PS Audio, would be HDMI. The parts are cheap, the cables can cost as little as $3.00 and up to Audiophile silly money. You will need a driver if you go off board anyway and a receiver at the other end. We could implement clocking at the DAC with the clock coming back on the HDMI cable pretty easily along with I2S communications.There are provisions for that in the cable that PS Audio didn't use.
 
Last edited:
You will need a driver if you go off board anyway and a receiver at the other end. We could implement clocking at the DAC with the clock coming back on the HDMI cable pretty easily along with I2S communications.There are provisions for that in the cable that PS Audio didn't use.
This idea gets my preliminary vote. Maybe I2S in both directions? I realize that the clock might be the only thing used in the reverse direct, though, but perhaps having both bit clock and word clock would be beneficial in some configurations.
 
Guys... among many others, "North Star Design - Hi End Audio Equipment - ♫" have used standard Ethernet patch cords (Cat5, RJ45) to transmit I2S on their world-renowned "Model 192" transport+DAC pair (also on following models) and it works just fine.

I personally own a Model 192 DAC, which I currently drive (again via a short piece of cat5) by tapping I2S from an ESI Juli@ PCI card. That's my main source since several years now.

I don't see why it shouldn't work for the widget too.

Oh, should you choose the same pinout used by NorthStar, you'd do me (and to the so many happy owners of an NS DAC) a big favor. Of course I can build a custom cable myself, but being able to just use a short standard ethernet patch cord would be soooo nice... ;)
 
Last edited:
Now, what ever you lads decide on try to keep it to some standard. I will in every case build my own but that might not be the case for everyone. Be sure of that nothing gets destroyed due to the opendness of the project. God only have the answers where the cables will end...

Brgds
 
Member
Joined 2004
Paid Member
HDMI I2S with DAC side clock option

The problem is a little more complex but can be sorted out.

First- the legacy link is per Paul's post. That is already in use and it would be nice to be able to connect to a PWT or a W4S dac and have it work.

There is an I2C link in the HDMI spec called DDC. Its used for EDID and for the security handshake. If we connect it it can be used for volume, balance, mute etc. Software implementation can come later. Much easier to implement software when the connections are in place. It uses pins 15, 16 and 17. Its in Paul's spec.

HDMI 1.4 has provisions for Ethernet across HDMI (HEC). It uses pins 14 and 19 as a differential pair. I propose we use that to send the M clock back to the host from the DAC. It is used for sync so the data comes at the right rate. It does not need to be ultra jitter free. Pauls legacy has pin 19 grounded so we must use this single ended, or not see the following.

We need to communicate the following info with the remaining lines:
1) selected master clock. Two options (44.1 and 48).
2) Is the DAC compatible with DAC driven clocking?
3) Is the host compatible with DAC driven clocking?

Need to communicate three pieces of data with one line it seems. I want to keep it simple and hardware only.

1) We know Paul's legacy has pin 19 grounded. We can use that to indicate if the host supports DAC driven clocking (grounded = no) If not grounded its the other half of the DAC clock diff pair.

2) CEC, pin 13, is unused still We can use that to tell the DAC which master clock to use. High = 22.5792 MHz and Low = 24.576 MHz.

How do we tell the host to look for a clock on pin 14? Or does it just look for the presence of a clock and switch? This would be the simplest.

Comments? What did I overlook? If this works I'll propose it back to Paul as an enhancement.

For reference here are the available connections:
Pin 1 TMDS Data2+
Pin 2 TMDS Data2 Shield
Pin 3 TMDS Data2–
Pin 4 TMDS Data1+
Pin 5 TMDS Data1 Shield
Pin 6 TMDS Data1–
Pin 7 TMDS Data0+
Pin 8 TMDS Data0 Shield
Pin 9 TMDS Data0–
Pin 10 TMDS Clock+
Pin 11 TMDS Clock Shield
Pin 12 TMDS Clock–
Pin 13 CEC
Pin 14 Reserved (HDMI 1.0–1.3c), HEC Data- (Optional, HDMI 1.4+ with Ethernet)
Pin 15 SCL (I²C Serial Clock for DDC)
Pin 16 SDA (I²C Serial Data Line for DDC)
Pin 17 DDC/CEC/HEC Ground
Pin 18 +5 V Power (max 50 mA)
Pin 19 Hot Plug Detect (All versions) and HEC Data+ (Optional, HDMI 1.4+ with Ethernet)
 
just wondering since you guys are playing with sabre dacs here too and as has been discussed elsewhere lately with synchronous usb->i2s setups for sabre. the sabre internal oversampling filter has to be turned off unless the driving clock for PCM is 192*FS, so for 192kHz audio a 22.xx or 24.xx MCK speed is not good enough, let alone for higher bitrates. for OSF bypass mode it can be 24*FS so the clocks you are running now are going to be good up to 88.4 or 96kHz with OSF enabled; but above that your screwed.

now if youve got the clocking well sorted and perhaps doing OS in an even wider 64bit floating point operation in puremusic or similar player software i suppose its not a big deal, but the OSF is one of the more powerful things about the sabre IMO. this would also rule out DSD over USB with the current clocks if OS is enabled

thoughts?

otherwise this project is looking pretty exciting tbh, especially if combined with the fifo (also in sync)
 
Last edited:
Here's what is needed to put in an ES9012:
- Good bipolar power supplies
- Good IVC design (output not very well documented)
- Reliable supply of ESS chips in low quantities

We may be close to a PSU design but far from the other items. That's one reason I'm designing the AB-1.12 so that you can experiment with it. Then I can lay out the solutions which work on later boards.

Børge
 
I was about to suggest having an i2c control line in there, too. being a remote control guy (lol) that would be right up my alley.

how about a 'device type sense' set of pins or something? ie, if we defined a standard and allocated enums to match (somehow), then when dac A is connected to this connection, the upstream host could know that and maybe do something differently. ie, it might be useful into to know you just plugged dac A into this vs dac B or even repeater C. the concept of 'discovery' and being able to sense what is connected is powerful. EDID over i2c is one way, but this means that there has to be an i2c responder on the other end.

how about something very very simple like a voltage divider or resistor programming, so that the device would set a certain code and it would be sensed over this analog signaling. just to be super easy. there could be a dip switch that sets the returned voltage key or just the R value that is remotely sensed.

even if its just informational, it would be nice to 'query' a connection and find all the things on that 'bus'. hdmi has that (due to drm, sigh!) but the idea of an auto discovery of what's on is a nice one and long overdue for audio systems (imho).
 
Did you check it against the schematic I posted?
OK, done.

Your proposed pinout (post #1224, file Ab-1.12_20120229_pC06_sch.zip) seems to match that of the m2tech "hiFace Evo" as reported in the m2tech app note above.

Unfortunately, as stated that one is NOT the same pinout as the one used by NorthStar. :(

I have found the original source of the info used to build my own Juli@ to NS cable. They came from these two threads on Head-Fi: I2S with my NorthStar DAC and Easy I2S from Juli@ PCI sound card. There is also a picture of the setup (not my own).

Eventually, the NorthStar pinout is as follows:

PIN : Definition
8 : Bit Clock
7 : Bit Clock Ground
6 : Data
5 : Data Ground
4 : Left/Right Word Clock
3 : Left/Right Word Clock Ground
2 : Master Clock
1 : Master Clock Ground

I can testify that (at least if using very short I2S cable) it works even with 3.3V single-ended (as is from the Juli@ and would be with your proposed scheme).

But! IIUC, according to the m2tech app note it should rather be 5V differential!

Indeed, many people over the net claims that it sound much better using 5V rather than 3.3V and even better with proper differential drive (and I can guess why).

At this point, I would reconsider your original idea of the "patch board" daughter-card header. Bring there also 3.3V and 5V PSU lines and one may build different adapters for different DACs on it... :cannotbe:
 
Here's what is needed to put in an ES9012:
- Good bipolar power supplies
- Good IVC design (output not very well documented)
- Reliable supply of ESS chips in low quantities

We may be close to a PSU design but far from the other items. That's one reason I'm designing the AB-1.12 so that you can experiment with it. Then I can lay out the solutions which work on later boards.

Børge

On the two first parts - do your best and allow others to add their fancy parts.

The third one I'll leave to you Börge to sort out.

Brgds
 
ahh the OSF would have to be disabled for the DSD over USB anyway wouldnt it?

At this point, I would reconsider your original idea of the "patch board" daughter-card header. Bring there also 3.3V and 5V PSU lines and one may build different adapters for different DACs on it... :cannotbe:
sounds messy IMO, 'Jack of all trades, master of none' is a (perhaps AU indigenous) phrase that comes to mind

as for the IVC for sabre, it does tend to have some rather special requirements for best performance. ive played with many ivs for it and its critical to have the AVCC/2 bias available for the input of the IV. the AVCC L/R DVDD L/R supplies for the dac are the most critical along with lowZ return to AVCC from the IV stage. i2c control is vital or you are stuck with defaults. small quantities of chips (5+) are available from Shaw still afaik.
 
Last edited: