Uncle Sam considers the ultra low phase noise a critical technology, probably for radar systems or some microwave thing and they are pretty careful about it.
The streamline oscillators are a different story and can be exported.
You will need a really good power supply to get the performance and probably a distribution amp etc.
I hope to have the AKM ADC board soon and can make some comparisons, it should be very interesting.
I am also planing to make a phase noise test fixture etc. I have done the setup with the external mixers etc but I want to reduce it to a PCB etc. so it's more useful.
The streamline oscillators are a different story and can be exported.
You will need a really good power supply to get the performance and probably a distribution amp etc.
I hope to have the AKM ADC board soon and can make some comparisons, it should be very interesting.
I am also planing to make a phase noise test fixture etc. I have done the setup with the external mixers etc but I want to reduce it to a PCB etc. so it's more useful.
true, we dont want to enact the patriot act lol. At 1500 its not going to happen anyway considering i need 2, but 500 and considering i can claim it as a business expense for measurement and it matches the OTT nature of the rest of the build seems reasonable.
I figure it should last many years and be useful for many things including a plan to actually build a sabre es9102 ADC for measurements (speakers, amps etc) and run it from the same master as the dac. the board I intend to use it with has suitably high quality fanout buffer, but i'd like to take your advice about not corrupting all the good work by connecting to system ground, so i guess i'm on the lookout for suitable transformers; perhaps something from scientific conversions. i'll probably just start with 1 for the 22.1x and see if its worth the trouble.
a suitable PSU is a given and a big part of the fun
I figure it should last many years and be useful for many things including a plan to actually build a sabre es9102 ADC for measurements (speakers, amps etc) and run it from the same master as the dac. the board I intend to use it with has suitably high quality fanout buffer, but i'd like to take your advice about not corrupting all the good work by connecting to system ground, so i guess i'm on the lookout for suitable transformers; perhaps something from scientific conversions. i'll probably just start with 1 for the 22.1x and see if its worth the trouble.
a suitable PSU is a given and a big part of the fun
Everyone,
here is the latest AB-1.12 update. I'd like you to look over the schematic befor it hits the printing press. There's a bit of routing left but not much.
Demian,
I'm not a CAT5 expert. Is your opinion on PIN#<->colour or on I2S<->PIN#?
Børge
here is the latest AB-1.12 update. I'd like you to look over the schematic befor it hits the printing press. There's a bit of routing left but not much.
Demian,
I'm not a CAT5 expert. Is your opinion on PIN#<->colour or on I2S<->PIN#?
Børge
Attachments
The standard connections for Ethernet are here TIA/EIA-568 - Wikipedia, the free encyclopedia shown as clearly as anywhere.
There are two options for the pairing/colors but that doesn't really matter much as long as the pairs are kept the same at each end of the cable.
I would use pair 1 for the master clock since its the highest frequency and most sensitive. I would also drive it with 100 Ohm source Z since that will match the cable, reduce radiated noise etc and terminate it that way as well.
Use pair 2 for word clock Use pair 3 for bit clock and pair 4 for data.
This will be compatible with any standard ethernet cable. A crossover cable will leave the user lost. . .
There are standard isolation transformers in some versions of the RJ45 connectors that do an exceptional job of isolating. The only real question is whether the data (and to a lesser extent the word clock) can pass through a transformer. I'll have a look this evening. if it can work this would be a good alternative to the HDMI based solutions.
The other version that is gaining traction is the PS Audio standard that uses HDMI cables and connectors. Its benefit is unlimited bandwidth and very high performance transmitters and receivers.
Electrical definition: The electrical interface is defined by the National Semiconductor DS090LV032 LVDS differential Line Receiver.
Mechanical definition: The interface uses the following pins on a standard HDMI connector: Pin 1: Send Data (SD) –
Pin 3: Send Data (SD) +
Pin 4: Bit Clock (BCK) +
Pin 6: Bit Clock (BCK) –
Pin 7: Word Clock (LRCK) –
Pin 9: Word Clock (LRCK) +
Pin 17: Ground
Pin 19: Attached – (goes low to indicate there is a connection I think)
More here: http://www.raleighaudio.com/I2S%20Interface%20v1.0.pdf
There are two options for the pairing/colors but that doesn't really matter much as long as the pairs are kept the same at each end of the cable.
I would use pair 1 for the master clock since its the highest frequency and most sensitive. I would also drive it with 100 Ohm source Z since that will match the cable, reduce radiated noise etc and terminate it that way as well.
Use pair 2 for word clock Use pair 3 for bit clock and pair 4 for data.
This will be compatible with any standard ethernet cable. A crossover cable will leave the user lost. . .
There are standard isolation transformers in some versions of the RJ45 connectors that do an exceptional job of isolating. The only real question is whether the data (and to a lesser extent the word clock) can pass through a transformer. I'll have a look this evening. if it can work this would be a good alternative to the HDMI based solutions.
The other version that is gaining traction is the PS Audio standard that uses HDMI cables and connectors. Its benefit is unlimited bandwidth and very high performance transmitters and receivers.
Electrical definition: The electrical interface is defined by the National Semiconductor DS090LV032 LVDS differential Line Receiver.
Mechanical definition: The interface uses the following pins on a standard HDMI connector: Pin 1: Send Data (SD) –
Pin 3: Send Data (SD) +
Pin 4: Bit Clock (BCK) +
Pin 6: Bit Clock (BCK) –
Pin 7: Word Clock (LRCK) –
Pin 9: Word Clock (LRCK) +
Pin 17: Ground
Pin 19: Attached – (goes low to indicate there is a connection I think)
More here: http://www.raleighaudio.com/I2S%20Interface%20v1.0.pdf
Cat5 (6,7) cables will have a small amount of skew between the pairs, typically less than a nanosecond over 100'. They also have carefully calculated twisting to prevent crosstalk between the pairs. Only the master clock timing is critical as long as the timing specs at the receive end are met.
HDMI has much tighter specs for skew etc. since it has to pass rates exceeding 3 GB per lane and one of the 4 pair is the clock.
HDMI has much tighter specs for skew etc. since it has to pass rates exceeding 3 GB per lane and one of the 4 pair is the clock.
The other item I would bring up is the use of an RCA for SPDIF. I would much prefer to see a BNC like this CONN SOCKET BNC ELBOW 75 OHM - 5-1634513-1.
The point of using CAT5 is to connect more or less straight to existing DACs with CAT5 input. We can define a standard and then defend it. Or we can recycle an existing one. The source for my pinout was this: I2S from Hiface Evo problem. Any solution? - Buffalo DAC - Twisted Pear Audio Support
I'll change the resistor values to 100Ohms. There is very little room on the board for transformers. Plus, we wouldn't know how to treat the data signal. So I suggest not pushing that issue for now.
The reason I've chosen SPDIF over RCA is that that's the usual connector for SPDIF, plus it is cheap to come by, I had the footprint in the CAD library etc. But the one Demian suggests is an easy redesign. I don't worry much about the mechanical strength of it. I'll give it some nice Cu pads on the board.
As for I2S over HDMI, show me the application and I'm all ears.
Børge
I'll change the resistor values to 100Ohms. There is very little room on the board for transformers. Plus, we wouldn't know how to treat the data signal. So I suggest not pushing that issue for now.
The reason I've chosen SPDIF over RCA is that that's the usual connector for SPDIF, plus it is cheap to come by, I had the footprint in the CAD library etc. But the one Demian suggests is an easy redesign. I don't worry much about the mechanical strength of it. I'll give it some nice Cu pads on the board.
As for I2S over HDMI, show me the application and I'm all ears.
Børge
Nikolays UAC2 ASIO driver...
I can't find any references to the happening it in sdr-widget - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting ... Nothing to download?
OK, I found it in the git but anyway - advertize it hard and advertize it now!
My very most sincere compliments to You Nikolay!
Brgds / Turbon
I can't find any references to the happening it in sdr-widget - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting ... Nothing to download?
OK, I found it in the git but anyway - advertize it hard and advertize it now!
My very most sincere compliments to You Nikolay!
Brgds / Turbon
BNC:
That connector was the first cheap one I found. There are many others that do have panel mounting. I used those on a product years ago that had 64 on the back with no failures. You do want an isolated connector to keep the isolation.
I2S over HDMI:
The PS Audio standard is getting some traction. Here is the basics from PS Audio along with some of the usual DIY dissembling (there is an amazing amount of not invented here in DIY audio). I have seen 8 Gbps over a single HDMI lane which would require very low jitter to work.
http://www.diyaudio.com/forums/digital-line-level/164366-i2s-standards-ps-audio.html
Here are three products using it:
PerfectWave Media DAC | PS Audio
W4S DAC-2 (DAC2) - DACs - DAC 2 Digital, High Definition Amplifiers, Stereo Pre Amp Audio Equip
Welcome to stahltek.com!
hdmi connectors, though, just plain suck. don't we all hate them? I do. the fat cabled versions don't have the right force to hold the plugs in and the thin cable versions seem to be underspec'd. the connector quality is bad and its not really diy friendly for soldering. however, the cables ARE cheap and pre-made and that's a huge plus. they are being used to carry audio and I have no doubts that audio can be carried well over this transport.
are there any locking hdmi assemblies? I just really hate the physical connector with a passion.
the rj45, otoh, locks, is diy friendly, is cheap, easy to find, cables are also pre-made and at various lengths. lots going for this.
either way, I'd want to encode and decode in balanced form (ie, differential). for home hacking, I'd just put one of the 2 wire pairs to ground; but for a real design, I'd prefer each pair be a balanced send and balanced receive on the other end.
and again, if you want to be really clean about cat5e and above, each pair has a twist rate that is different and this means the total physical length is different. perhaps a tiny delay inside (via trace trombones) would help fix the diffs. this would assume a certain fixed cable size, though. might not be a bad idea, anyway.
are there any locking hdmi assemblies? I just really hate the physical connector with a passion.
the rj45, otoh, locks, is diy friendly, is cheap, easy to find, cables are also pre-made and at various lengths. lots going for this.
either way, I'd want to encode and decode in balanced form (ie, differential). for home hacking, I'd just put one of the 2 wire pairs to ground; but for a real design, I'd prefer each pair be a balanced send and balanced receive on the other end.
and again, if you want to be really clean about cat5e and above, each pair has a twist rate that is different and this means the total physical length is different. perhaps a tiny delay inside (via trace trombones) would help fix the diffs. this would assume a certain fixed cable size, though. might not be a bad idea, anyway.
The flap on CAT5 cables sucks. It gets stuck. It sucks golf balls through garden hoses. It sucks galaxies through capilaries. It just plain sucks 
)))))))
I agree that differential signalling is great. A diff driver should be doable, a transformer needs an AC signal. I just don't wish to add much more to the AB-1.12 proto board.
Børge
)))))))I agree that differential signalling is great. A diff driver should be doable, a transformer needs an AC signal. I just don't wish to add much more to the AB-1.12 proto board.
Børge
the plastic key on MJ connectors (rj11, etc) breaks off when you pull it thru things in the real world. then it won't lock and it won't even stay in. good news is: cables are cheap and easy to find.
if gigabit ethernet can run over those (and data center all use cat cabling and MJ connectors) then it can be good enough for audio.
hdmi is better specd but that connector has no lock and its meant to be made cheaply. if consumers have drop-outs, well, 'oopsie!' and the vendor just tells the consumer to rebuy something. this is not acceptable for pro or near pro standards. hdmi is an abortion and nightmare.
my gut feeling is that MJ connectors can be made to work and are not nearly as fussy as hdmi. you just need to condition the signal so that its tolerant of all the issues that MJ has. ethernet guys have successfully used this for decades, now; and I don't see why it can't be used for audio in this way.
in a way, since the cables are lower spec for ethernet than they are for video, the sending and receiving ciruits have to go the extra mile to ensure the data gets there and is clean. in a way, I like that design. it assumes kind of the worst on the cable part and does more than the minimal to send and receive the bits. if the cables does all the work for you, arguably your protocol is less robust and now -requires- super-cables.
a truly good design will work even in the face of less than ideal cables.
if gigabit ethernet can run over those (and data center all use cat cabling and MJ connectors) then it can be good enough for audio.
hdmi is better specd but that connector has no lock and its meant to be made cheaply. if consumers have drop-outs, well, 'oopsie!' and the vendor just tells the consumer to rebuy something. this is not acceptable for pro or near pro standards. hdmi is an abortion and nightmare.
my gut feeling is that MJ connectors can be made to work and are not nearly as fussy as hdmi. you just need to condition the signal so that its tolerant of all the issues that MJ has. ethernet guys have successfully used this for decades, now; and I don't see why it can't be used for audio in this way.
in a way, since the cables are lower spec for ethernet than they are for video, the sending and receiving ciruits have to go the extra mile to ensure the data gets there and is clean. in a way, I like that design. it assumes kind of the worst on the cable part and does more than the minimal to send and receive the bits. if the cables does all the work for you, arguably your protocol is less robust and now -requires- super-cables.
a truly good design will work even in the face of less than ideal cables.
Keep in mind that ethernet is not a real-time protocol. Collisions are expected, resulting in data loss for UDP or retransmission for TCP. Distances are also much larger than they need to be for I2S. Frankly, I think that it is a mistake to look at ethernet and make the simple statement that it "works" without qualifying exactly what is being transmitted, how it is being transmitted, and the way in which failure is handled. Almost every aspect is different than it should be for digital audio. Thus, I think it is a mistake to assume that you can tack on an ethernet jack, or even a subset, and get any kind of reasonable performance.
I think you misinterpreted what I was saying. I never suggested ethernet, IS AS, is useful for audio. in fact, I said you want to make sure you encode the signal so that even this 'bad transport' (cat cabling) will work. doesn't that imply its quite far from just plug-and-play? you have me sounding like its a direct connect and it will just work. I never suggested that.
I'm fully aware of the buffering and retransmission that networks have; but that's neither here nor there. the cabling never was designed with or without realtime use in mind. cabling is cabling and the data mechanisms are orthogonal to that.
gig-e has a bit of help, though; as it splits the work over all 4 pairs. we can't divide the bits across more than 1 pair or play other compression games, so our baud and bit rates will be the same.
I'm fully aware of the buffering and retransmission that networks have; but that's neither here nor there. the cabling never was designed with or without realtime use in mind. cabling is cabling and the data mechanisms are orthogonal to that.
gig-e has a bit of help, though; as it splits the work over all 4 pairs. we can't divide the bits across more than 1 pair or play other compression games, so our baud and bit rates will be the same.