None of those have very high frequencies/data rates when compared to the connections to the hard disk of your computer (or between the computers). And just for clarity, standard-rate DSD is 2.8 Mbit/s per channel, 192k/24 is 4.6 Mbit/s, so DSD won't be an issue. Even 384k/24 is only 9.2 Mbit/s, compared to 100 Mbit/s for 100BASE-TX ethernet and 4.8 Gbit/s for SATA 3.0.
Hello Ian,
I know you have a Pi board but had you a look at the design of the Odroid c1+ with its own I2S plug (in line : Wd-Bck-Sd-5V-Gnd) very close to the emitter chip ? Does it change things vs the Pi board at 192 Mhz max (I assume we can't with both boards oversampling to 384 MHz) ? Finally with the FIFO after, do we have to bother of splitted I2S line between the FIFO and the PC board ? (but for shielving behavior : EMI)
Last edited:
Said like that it's clearer...
(So we have more to bother first about matching the impedance between the boards to transmitt at the best all these low signals)
Thanks for all these previous inputs fellows
Last edited:
You guys think too much, just do it, raspberry into fifo and clocks isnt hard and hear for yourself . I dont usually get too excited about stuff, I've been around a long time, but no usb is all about depth, height, width of soundstage, big sound, more 3D, but also sounds like cheap microphone has been replaced with much superior one in recording, closer to the music.
(But you also need speakers that can replicate this.)
(But you also need speakers that can replicate this.)
Hi Eldam,
I'v noticed that board. But it was out of stock. I'm gonna buy one once available.
I heard it can go up to 384KHz, but I have to confirm.
I'm also thinking of how to pick up native DSD signals from those small board.
Ian
Last edited:
I think this was sort of asked before, just in a different way, seems still unresolved?..
Q. If FIFO fed with bit perfect signal via USB to I2S converter, or fed with bit perfect direct I2S via RPi, if the FIFO is working as designed, should the result not be exactly the same; and if not, how then so?.
WRT to I2S isolation vs USB, I am certain that it has more to do with localising the ground reference to the DAC itself ...
Ian ??
L.H/S
Q. If FIFO fed with bit perfect signal via USB to I2S converter, or fed with bit perfect direct I2S via RPi, if the FIFO is working as designed, should the result not be exactly the same; and if not, how then so?.
WRT to I2S isolation vs USB, I am certain that it has more to do with localising the ground reference to the DAC itself ...
Ian ??
L.H/S
Last edited:
You are free to say whatever you like, but to set the record straight J is not an audio hobbyist, but a telecoms engineer with the equipment and knowledge to measure gigahertz signals.
My comment was based purely on Eldam's explanation of the differences of view. I would love to hear the full arguments from both J and Marce.
Seems to me that it is responses like this which add lots of noise to which should be rather straight forward considering the designer of the device foremost in this thread is an active poster.
I believe the current thought is how or why the different subjective results with feeding FIFO with equally bit perfect I2S signals... and possible reasons for this.
If we are to get anywhere, please keep on topic.
L.H/S
Last edited:
Which is where the electrical specification of I2S is less than ideal - we have to remember that it was originally designed to connect chips on the same circuit board (it is called Integrated Interchip Sound for a reason), and never intended for longer distances.
It is somewhat ironic that while we are able to transmit tens or hundreds of gigabits of data error-free thousands of miles under oceans, between our computers and to and from our hard disks (even USB can do several gigabits/s when talking to a fast enough device), but transmitting a few megabits/s for a few feet to a DAC is still an issue.
Ian, have you actually come across situations so bad that you get bit errors? I suppose it is a possibility with I2S (USB is a bit more robust). Perhaps what we need is a standard for transmitting I2S with better electrical specifications - perhaps a differential, balanced (and insulated) spec, such as twisted pair ethernet, but I guess the ubiquity of USB and the migration to stuff like AES67 makes it a bit futile at this point.
I believe there are in many forums comments about the weak I2S signal of the raspberry which causes sometimes dropoits etc. Not that I have personal experiences or data, but that is what I read...so if you use it, you need extreme care and short cables.
Hifiduino did a comparison with the bbb
https://hifiduino.wordpress.com/2014/03/01/low-cost-audiophile-music-servers/
...and found that bbb might be the better platform as it natively support the external clock option.
"natively" is relative as it nevertheless need a Linux-System which makes as well use of it, I understand that is where the botic driver comes into play for the twistedpear hermes-chronus solution at least.
So my question: Has anyone used Ian's clocks to fireup a BBB ? Which software adoptions did you use ? Is there maybe a chance to get a pcb for the bbb which is pin campatible with what the botic driver expects, so that we have a hardware-solution and a software solution at the same time ?
Hifiduino did a comparison with the bbb
https://hifiduino.wordpress.com/2014/03/01/low-cost-audiophile-music-servers/
...and found that bbb might be the better platform as it natively support the external clock option.
"natively" is relative as it nevertheless need a Linux-System which makes as well use of it, I understand that is where the botic driver comes into play for the twistedpear hermes-chronus solution at least.
So my question: Has anyone used Ian's clocks to fireup a BBB ? Which software adoptions did you use ? Is there maybe a chance to get a pcb for the bbb which is pin campatible with what the botic driver expects, so that we have a hardware-solution and a software solution at the same time ?
Indeed. And it is especially sensitive to cable capacitance.
Unfortunately they only looked at the clock problems - and that should be a non-issue with a FIFO.
That's why I wanted 2" uf-l cables to connect all the Ian's devices together avoiding the flat cable. Although without to know if it's really hearable !
Can we consider than between two boards, e.g. FIFO and Clock board, each board is a signal regenerator as well like are the repeaters in a WAN (wild aera network) ? If at each nod, the I2S signal is reboosted it would don't care to have this extra length between the emitter (a Pi for instance) and the dac chip ?
I don't know for instance, as bit perfect is not really a problem, if we can use a soft plateform for the treatment : Library, DRC, FIR : then send it to a streamer : so the Pi or whatever to avoid this USB if the experiment confirms (like Supra did) than a Pi like platerform is better than any usb to I2S plateform. Like Squeezebox players did with Squeezebox server then the Squeezebox Appliance as streamer itselves?
Of course I say that because the all in one soft on Pi are limited by the power of the hardware (for te moment : lake of RAM mostly).
Well as say Supra to rephrase him : easy to try oneself; but here it's also to share. We know all we have a good core system with Ian's devices, the extra becomes to optimize the whole chain if the gain can be heared.
The uf-l are probably a good idea as long as we use single-ended TTL signals, but a better solution would be a balanced, differential connection using twisted wires (or cat 5 cable). Remember the hard disk cable on your computer (that handles much higher speeds and frequencies) is a flat cable.
Electrically yes, and from a clock/timing point of view, that is exactly what the FIFO does.
The squeezebox systems use TCP/IP over ethernet - you should see the jitter levels on that
, but the squeezebox players also have the FIFO functionality built in, so it doesn't matter. The ethernet connection also has the benefit of being both differential and magnetically coupled (tiny transformers), so noise isn't an issue between the devices.
What we are discussing is all about signal integrity. http://www.keysight.com/upload/cmc_upload/All/GTL11.pdf?&cc=CA&lc=eng
For a 192KHz I2S signal
1. Even for the low frequency 192KHz LRCK wire, both raising edge and falling edge can have very high frequency component extended up to decades of MHz;
2. The SCK itself is already 12.288MHz
So, in either case, I2S signal has to be treated as RF signal. Impedance control, termination, transmission line, ground plate, returning path, reflection, cross talk,rail collapse,EMC......all those stuffs have to be taken into consideration for a designer.
According to my real debugging experience, I2S signal becomes very sensitive to transmission line impedance and return path when the Fs is higher then 192KHz. To avoid wrong receiving bit, coaxial cables or other impedance controlled cables are always highly recommended except the connection length is very short (within 2 inches).
Ian
Last edited:
Ian the Odroid C1+ is updated with the C2,64-bit quad-core, 2Ghz processor,2gb ddr3,a version 64 of Volumio 2 is planned,but a beta (32b)is already available Index of /gkkpch