Xoverman

Thanks for the quick Response. Are you talking about flow control of the network chip on the main PCB?

I have an Opicalrendu Ver. 1.3 full version. I have the opportunity to get a used Opicalrendu Ver. 1.3 ROON only as a spear part. Can I use the ROON only Opicalrendu in case my full version brakes down and put the SD-Card of the full version Opticalrendu in the slot of the ROON only and have a full version again?

What SoC NAA - RAV bridge do you have ?

Don’t get me wrong, I don’t want to bash the developer !!! This is an affect that also john Swenson describes in his article “Understanding how perturbations on digital signals can affect sound quality without changing bits, and how these issues are addressed by the UpTone EtherREGEN” This effect is very well known in Test and Measurement, just the HiFi industry seems to be surprised by it J

ChatGBT : If the NAA's FIFO buffer is completely asynchronous, meaning it is fully decoupled from the timing of the incoming data and the output clock is generated independently, the situation becomes more interesting. In this case, the FIFO buffer should, in theory, isolate the output from any timing variations in the network or upstream devices like the switch. However, if changing the clock in the switch still affects the audio output, several factors could still be in play: 1. Clock Domain Interaction Even with a fully asynchronous FIFO, there is still a clock domain where the data enters the FIFO (network side) and a separate clock domain where the data exits the FIFO (audio side). If the timing of the data entering the FIFO is affected by the switch clock, it could influence how full or empty the FIFO gets over time. If the buffer levels fluctuate significantly, it could eventually lead to subtle changes in the output timing or behavior of the downstream DAC, even if the FIFO is supposed to handle such variations. 2. Clock Quality and Power Supply Noise Changing the switch’s clock could introduce noise or interference that indirectly affects the NAA. For instance, if the switch's clock affects the power supply or ground plane shared with the NAA (or even radiates electromagnetic interference), it could lead to subtle clock instability or noise in the NAA’s output clock, which could degrade audio quality. 3. Network-Induced Artifacts The switch clock change might introduce slight changes in packet timing or jitter that, while not directly affecting the asynchronous FIFO, could cause minor timing errors elsewhere in the signal chain. For example, if the NAA has some hidden dependency on the network timing for processes like packet handling or error correction, this could manifest as an audible change. Conclusion: Even with a fully asynchronous FIFO, non-idealities in clocking, power supply interaction, or network timing could still lead to audible changes. The FIFO decouples the data streams but does not eliminate all potential influences from the upstream components, especially if there are secondary paths through which the clock changes can affect the audio chain.

Is there some setting that I can reach inside a XML file or in any NAA Client directory where I can set the receive buffer to 500ms ? I just want to get this idea out of my head J

After modifying the Opticalrendu, a D-Link Switch, a Buffalo Switch and a Solarflare NIC with OCXO’s and LT3045 regulators I still can’t get the NAA input buffer of my mind. In my system I get the best results when using big buffers wherever I can. In the HQPlayer “settings.xml” I stumbled over the value : period_time="250" and changed it to "500". The sound didn’t change, but focus of big instruments and the impression of being in the same room as the recording improved noticeable. Hey Miska did I really change the Receive Buffer size of the NAA Client with this setting?

By the way Super Dad, I'm can absolutely confirm John Swenson theory, I used to design ultra low noise high resolution ADC's for sector field Mass Spectrometers and ultra low noise ion preamplifiers. These Instruments are the kings discipline in all of measurement instrumentation. And I stumbled over John Swensons theory many times. And still do.

Hello Super Dad, What an honor. The OCXO is underneath the 1000μF tantalum capacitor next to the heat sink. You are absolutely right, the SMPS is pretty bad, even though I added a much bigger common mode choke and a nother low ESR output capacitor. Witch already gave a huge improvement. But I will take the SMPS out in the near future. The switch is placed on a antivibration platform, but the switching supply generates micro vibrations the give intermodulation with the XO.

Yesterday I upgraded my Buffalo with a 25MHz OCXO J

Intention is that it works nicely even over not so good WiFi connections, etc. With a huge FIFO buffer. You can take a look at NAA output buffer fill level with Client. As long as it doesn't run empty you don't get drop-outs. But I truly believe that these points need further investigation. Maybe there is a way to program the NAA FiFo even better so low frequency jitter has less chance to bleed threw. I am still not very sure if it’s a problem of the NAA Software buffer or a PCB ground plain problem if the Opticalrendu. But fact is, that it doesn’t matter what you do on the primary side of the NAA, it is clearly audible. Changing Network cards, Switches, Clocks in Switches, PS’s in switches…….It’s all audible. And it’s not just me experiencing that phenomena. Dear Mica this is not critic on our software !!! It is the will to help explore the problems and of digital playback and join in in solving the problems.

I ran the SolarflareTools-v1.9.1. And thay told me that the low Latency Bios was installed and the default Bios. I hope that that’s all I have to do. Pleas correct me if I’m wrong. At the moment i'm using Windows 10 on that PC, but I will switch to Server 2022 soon. It’s so good to have a Network expert in this forum.

So far I tested Receive Side Scaling + Receive Packet Steering + Receive Flow Steering on NAA side. It did help buffering stability. Before setting RSS+RPS+RFS on my SoC NAA - RAV bridge, Anubis' receiving buffer looked ziggy-zaggy How did you do that ?

I have the X2522. The NIC has two XO's. One 20MHz for the NIC controller and a high precision clock chip. I think the Clock Chip is the Stratum 3 compliant oscillator. Not the controller XO. And if you look at the specs, then Stratum 3 isn't that great at all. OCXO have much lower phase noise next to the carrier (10Hz, 100Hz). The cable is a 50 Ohm Coax and I terminated it. It's only 15cm long. The NIC is cooled from the fans of the RTX card above it.

I managed to contact a OCXO to my SOLARFLARE NIC. It helped a lot. But the SOLARFLARE NIC still doesn't play as fluid (liquid) as my intel x540 server NIC. I guess the SOLARFLARE is really optimized for ultra fast reaction, but has problems with ultra low frequency jitter (closed in band jitter). I had to interrupt one pcb trace between the installed clock and a via going to the other side of the PCB. Then I placed the OCXO with it's 3.3V 2x LT3045 PS on a concrete brick sitting on gel dampers to keep vibration from the PC case away from the OCXO.