hi, i dont really understand clocks so - is the word clock connector on the back of the oladra to take a clock input or does it give a clock output? im am going from the oladra to a lynx hilo 2 over AES which has a word clock input. so will connecting the oladra to my lynx give better clocking than not connecting it? Or is there no need to connect a cable because the clock data will go to the Lynx with the AES cable? In that case should i set the clocking in my lynx to AES or leave it as internal?
No need as the clock is passed over AES. There might be a difference if you connect a clock cable but only your ears can decide whether it is an improvement. The Oladra has an excellent clock so you should try setting the switch to AES.
1 Like
The Lynx has a clock input and is commonly called âHouse Syncâ normally used for live recording / broadcast. We use Time Base Correction on broadcast cameras and micâs. When we are switching from Camera A to Camera B we need this so there isnât a delay/glitch. The frame and audio interpolation happen smoothly because both cameras and audio sources have the exact same time signature.
The above is a synchronous example.
Modern playback systems that take place over a-synchronous methods (USB, PCI-E, Ethernet), donât require any external clock input as the timing data is already stored in the PCM data and the systems that deliver this to the DAC can literally deliver your entire audio track in seconds or even sub seconds. This is because the music isnât live. The DAC just reads the embedded clock data and it knows how to put those packets back in the correct order and and all properly reconstructed.
1 Like
I have an Innuos Statement > Ethernet > Sonore Optical Module > Fiber > Sonore Signature Rendu > USB > Antipodes S20/S60 > Coax > Lampizator GG3.
Does the clock date get a-synchronously passed all the way down to the S20? Then does the GG3 receive synchronous data so it used its own clock?
In my system the Ethernet output of the Statement is better than USB. I used an UltraRendu to convert Ethernet to USB so as to compare both using the USB input of the DAC.
I also found the Coax input of the DAC is better than the USB which has been upgraded to JL Audio.
I really donât understand why having so many components between the Source and DAC, which are both (in my mind) excellent pieces of gear, is better than a direct connection with USB.
The S20 represents basically a DDC. Itâs taking digital input, taking the clock embedded in the data, and just ensuring itâs playing back out to the Lampizator.
Could just be a poor USB implementation on Lampizatorâs part. ÂŻ_(ă)_/ÂŻ
When it comes to serial synchronous data connections you have to understand there is the concept of DTE and DCE.
Data Terminating Equipment is the source and itâs the clock generator. The DCE is the receiver and itâs job is to sync to the master clock coming from the DTE.
The S20 is the clock domain boundary for your GG3.
Clocked serial data connects generally sucks. In networking we donât even use them anymore. I havenât touched a clocked digital line in almost 20 years. We used to run telemetry on the jitter for clocked serial lines and with truth table in Excel look it up and tell you how long the entire span was.
Jinjuku
So, like Tommytowtimes I donât understand clocks and as such, I am not confident I understood all of your response.
So the GG3 is the DCE and it is synching to the incoming clock generated by the DTE S20 over COAX.
The S20 is receiving an asynchronous connection over USB from the SignatureRendu, which clock data is used, its own or the clock data from the SignatureRendu? And also with the OpicalModule from the Innuos Streamer.
It does sound like you are not a fan of the path I use from the Innuos streamer to the GG3 DAC. It seems like the sound should be unpleasant, but it is for me amazing. It seems intuitive to me that adding more components and connections should degrade the audio.
I would have expected the USB to sound better. The new Lampizator JL Audio USB has strongly positive reviews on WBF over the previous Amanero USB.
I also preferred the USB from the Statement going thru the S20 over the direct USB connection. Maybe the Lampizator USB is as you say.
The S20 is receiving UNCLOCKED (ASYNC) data. The entire point behind ASYNC is that you replace tightly timed busses with a bit of buffer (RAM) and you have you have a control plane that just request enough data to keep the buffer filled on the USB input side so that the steady state digitally clocked, syncâd side, never under-runs. The Signature Rendu is basically doing the same thing I do with my Pi4 and Ropiee XL and Power over Ethernet hat feeding my DAC.
In RTP (Real Time Protocol) applications like Broadcast/Live TV/Radio/Concerts etc there are still Time Base Correctors sold and implemented for the analog domain. BUT there are also PTP (Priority Time Protocols) like AES67, AVB, SMTP 2110, and others that ride over traditional Ethernet were we are taking Analog inputs, converting them to a packetized stream, and unencoding them on the other end much to the same effect.
I came from the Broadcast side of the house initially but Iâm now a network engineer so Iâve seen this stuff soup to nuts in about every way that it can be implemented.
Iâm a fan of your setup if your a fan of your setup. Iâm simply trying to help with the initial ask of understanding clocks.
Hereâs an interesting tidbit: On Aegis Destroyers, they have massive computing power to multiple plot guided missile launches. But if you take a 1:1 scenario a WWII destroyer can calculate faster with itâs analog system when you start with the data inputs at the same time. What the WWII destroy canât do is 72 at a time.
If you want to deep dive read this. Cover both Sync and Asynch and youâll see the merits of Asynch for a lot of applications.
Remember your system is ASYNC to the point it its the S20.
Jinjuku
Interesting article, more than way above my head but still interesting reading. Is the information below from the article relate to why âclocked serial data connects generally suckâ?
Asynchronous Clock Domain Crossings
Clocks which do not have a known phase or frequency relationship between them are known as asynchronous clocks. Whenever there is a clock crossing between two asynchronous clocks, their active edges can arrive very close together leading to metastability. Here the phase difference between the clocks can be variable and unlike synchronous clocks it is unpredictable.
Does this somewhat get cleaned up as the final leg of the data connects is synchronous?
Also, I am confused by the following parts of your posts, can you clarify if asynchronous input has clock data.
And finally, can you explain what you mean by this.
I appreciate your efforts to give me some basic understanding of data and clocking via synchronous and asynchronous clock domain crossings.
This is absolutely true. It is also why buffers exist to make it a non-issue. We donât worry or care about making the joins between disparate clock domains. We setup static buffer that one writes to, the other reads from, and the only thing implemented is a control plane that monitors the buffer and pre-fetches based on the buffer conditions.
Does this somewhat get cleaned up as the final leg of the data connects is synchronous?
Also, I am confused by the following parts of your posts, can you clarify if asynchronous input has clock data.
Not sure what is meant by âcleaned upâ.
Asynch, by itâs nature, doesnât have clocking on the actual signaling line. USB and Ethernet are Asynch and they are packet networks. Their job is to avoid collisions (switched networks, CDMA, etc) and transfer at their max line rate.
The clocking for the samples that are packetized are included in the data and the receiver is responsible for reassembly.
And finally, can you explain what you mean by this.
My Pi4 running Ropieee XL is a Network to USB bridge. The S20 is like this, a Digital to Digital Converter. Itâs a format shifter.
The S20 has a USB input. So thatâs going to be Async.
Jinjuku,
I think Iâm beginning to wrap my head around some of this.
Hopefully a final question.
Are the ASYNCH data packets with the clock embedded, originated by the Statement Streamer, passed on first to the OpticalModule and then SignatureRendu as the original data packets or are they remade before being passed on?
If that is the case is the S20 as the DTE embedding the clock information of the Statement for the DCE or is the S20 embedding its own clock?
I guess in a nutshell I was wondering where the clock information the GG3 is synching to originates.
The data packets have the timing embedded by the mastering software. If you use Audacity or Reaper for audio recording and mastering and you just record something off your mic and save it as a .wav file all the timing is there.
In an network environment when a packet goes from L3 interface to L3 Interface itâs literally rebuilt from scratch each time. The final L3 (your gateway IP) then sends it to your host (called a receiver).
L3 interfaces and L2 segments work on the concept of a Packet and Frame. Add to that L2 and L3 MTU and IP MTU. MTU is the max size of a single packet or frame. The internet operates at 1500 MTU. I mention MTU as a way to talk about the Packet being regenerated at each hop. In the networking space we have the concept of fragmentation. On our local network we may have hosts (storage typically) that want to max out their MTU. So instead for 6 packets at 1500bytes we send 1 at 9100. Less processing over head. So what happens when that packet with 9100 bytes hit an interface destined for the internet? Well the L3 gateway (router) then FRAGMENTS it in to 1500 bytes and attaches a sequence #. Forwards it on to itâs final destination. The router closest to the receiver will get the packets in the order it gets them with no guarantee of getting them in sequential order. It just sends them onto the receiver and the receiver is 100% responsible for having enough buffer to store enough data that it has enough at the point of demand to properly look at the sequence #'s and reorder them.
So itâs a long winded way of saying: Itâs a copy of a copy of a copy of a copy of a copy, and what you get is guaranteed to be the exact samw as the file on a server say at Tidal, Qobuz, Amazon, Apple, or your streamer.
If you go in USB and then to AES thatâs a Digital to Digital Converter (DDC) and we still arenât talking about the actual timing data in the audio. We are talking about the AES busses mechanism to get data to the GG3.
The GG3 is ultimately syncâd up and getting data at an agreed upon rate over AES that it needs to guarantee glitch free playback. AFTER your GG3 gets the data from the AES buss it does what a USB based DAC does and unpacks the samples including the instructions (timing data) on how to properly put the samples in order and play them back without error.
AES is an older, synchronous, protocol with error correction and detection, and a great strength is itâs ability to go a long distance and go for up to 1000 meters depending on the cabling type.
1 Like
Blockquote
Hereâs an interesting tidbit: On Aegis Destroyers, they have massive computing power to multiple plot guided missile launches.
Tidbits of the workings of weapons of mass destruction and assets of the criminal child murdering uniformed terrorist industry are not of any interest or relevance on this forum
I must have missed that in the Terms of Service.
1 Like