No.Just a standard 8 port unmanaged switch.
So you have to have 2 oMs to make it work.
I am sorry. I donât see how that can work. Maybe Jesus can shed some light here for you
Mods have deleted a number of inappropriate posts. Please donât talk about other users.
You need two opticalModules and two power supplies to preserve the infinite galvanic isolation inherent to the system. The opticalModules each come with the SFP transceiver. From the second opticalModule to the ultraRendu you need to use an ethernet cable. Remember the opticalModules are bidirectional from cable to fiber and fiber to cable.
1 Like
What is the purpose of the femtoclock?
Both the network and the USB are asynchronous.
They need timing, but the audio-critical timing is outside the connection domain.
Read Johnâs thoughts on the subjectâŚI posted them above.
I read it. Still donât buy it. (Is John in this forum? Would you forward, please?)
I think that whole discussion of clocking is on a different level of abstraction. The discussion of pulses at 49, 50 and 51 ns â is this about the network pulses, at the physical level? That has nothing to do with jitter is the DAC and the audio distortion it can create.
(Itâs like my old joke about FedEx causing jitter in my ripped CDs because they deliver from Amazon every 24 hours but not on Sundays. Improving the cruise control in the FedEx truck would not reduce jitter because FedEx is not part of the timing mechanism for the DAC.)
This is my view of how USB delivery works. Tell me if there is anything wrong with this description.
Audio delivery over USB is packetized, as is the network. But that isnât even the point. The real point is that delivery from the network stack to the receiving code is buffered, packetized. (A packet is like a slip of paper, the sender writes some information on the piece of paper and sends it.) When a packet of data arrives, the low level network stack in the kernel calls the recipient code and says, Iâve got some data for you, please give me a buffer (another slip of paper) to put it in. The recipient hands over the buffer, the buffer gets filled in with data, the recipient then takes that buffer, reads out the data, and feeds it into the DAC under the control of its own clock.
Jitter in the DAC output and any kind of related distortion depends on the accuracy of the DACâs clock.
The senderâs clock â its audio level clock â is not involved in how the data is read out of the buffer. Itâs not involved with how it is written into the buffer either.
The audio clock, which is involved with jitter, is owned by the DAC (thatâs what asynchronous means).
Delivery of packets over the isochronous USB link (not related to asynchronous) comes every so many milliseconds, thatâs a quality-of-service (QoS) thing, to prevent audio from getting bogged down by other USB traffic.
And down at the lowest level of the network there are pulses, and they have timing, and shapes of the voltage levels.
And those three levels are entirely unrelated. Of course they are: the audio signals are related to the the sample rates, the isochronous USB timing is standardized but without any precision demands, and the network clock depends on the network speed, I guess.
So what is that talk about fingerprints and overlays?
Does it mean that imprecision in one clock can spread through the electrical infrastructure (power and ground, the âPG networkâ) and mess with the precision of another clock? How? They are not related. John talks about 49 and 50 and 51 ns, but Redbook samples are 22,675.73 ns apart, and 48k samples are 20,833.333 ns apart. So how would clock shift at the Ethernet level cause audio jitter?
So I donât buy it. Explain if Iâm wrong. Or show measurements of how the Rendu clock precision affects aiding distortion.
Note, Iâm not saying that the Rendu devices are bad. I have a MicroRendu that I like. Iâm not even saying they donât have a positive effect on the audio quality. Iâm just saying, whatever good it does, I donât see how it can be caused by clock precision.
EDIT The description of the API with the buffer applies to networking as well. Except for the isochronous thing, standard networking does not have QoS.
1 Like
@AndersVinberg I think that @Jesus_Rodriguez is referring to John Swenson, who â amongst other things â designs products on the basis that USB receivers inject noise into host circuitry. You can take or leave his explanations; in general, I feel it is good to feed a clean signal to something rather than a dirty one, but if I have to remediate, I do it as cheaply as possible.
No, so itâs probably best you ask John directly over on CA Forum, if you want the meaty answers, from the main man himselfâŚ
⌠or he can try this stuff for himself, and learn hands on experience if they bring anything to the table. Everyone with a Google Machine in their hands is an engineer nowadaysâŚ
Itâs quite fair for anybody to ask John (the designer) questions directly⌠as many already have done on CA ForumâŚ
John has always been open to questions (as long as they are polite and respectful, and not rude). Heâll tell you what he knows and what he doesnât know.
Asking these detailed technical questions here and expecting answers here is a waste of time since John (the designer) is not here. Jump on CA Forum to ask the questions about Johnâs posts (shared above).
I was just bringing up an alternative to asking questions, which is trying for yourself. Especially since Jesus just shared two lengthy articles from John S. Obviously there is nothing wrong with asking questions, but from my experience in the Internets and forums recently, those âquestions â are often asked for a different purpose than actually trying to learn something. Hopefully I am wrong on this.
It doesnât have to be one or the other⌠itâs quite fine to ask questions first and then buy later, as I have done in the past with many of Johnâs products 
John is ok with that tooâŚ
Yes of course⌠thus my word⌠âalternativeâ. I hope you get my gist on this. Put it another way: does âquestioningâ equals with âtrying to learnâ? Not alwaysâŚ
In my case yes⌠itâs a tremendous waste of energy to worry why others ask questionsâŚ
Anyway I was originally quoting Anders directly and suggesting he asks any questions about Johnâs posts above, over on CA Forum. We seem to be going in circles here.
I apologize for derailing the questioning process
1 Like
Yes, I know who John is. I could ask him, although I hesitate to get into the CA forum, likely to lead to lengthy and inconclusive debates.
But @Jesus_Rodriguez is here arguing for the product, if he canât or wonât defend them he should not be making claims. Referring to God somewhere else is not right.
No. I can try it and note if it has a positive effect on sound. But I cannot identify the effect of the femtoclock, I canât determine if clock precision is a factor, thatâs 2hat I am questioning.
And I canât, in practice, test everything, I have neither the time or the money. Sensible engineering descriptions are a factor when I choose what to buy and try (why I bought Chord).
Thatâs fair. I have previously argued that source or transport jitter is not a factor in asynchronous DACs. So I have a dual purpose: if I am wrong, I would like to learn why. If I am right, I want to stop misleading marketing.
That makes sense. Although the cost of optical Module is not extremely prohibitive to get it to try. They also have a 30-day money back guarantee that makes it easy to return for full refund if it does nothing for you. But I understand the time constraint. This is a hobby, not life or death situation
As Sean mentioned, if you have access to Audiophile Style forums, you can message John Swenson directly since his rationale Jesus shared did not convince you.
1 Like