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.

That's true. I guess we all also listen for different things in the music.

Hello everyone, I cannot agree with this finding. In my System most of the time I have the impression that bigger buffers give me more flued more organic playback. Rooms become bigger. If software buffers are programed correctly the data inside the buffer is addressed with address pointers. Data is not moves around or shifted around in the buffer. It’s just the pointers that count up and down. So the size of the buffer plays no role during playback.

That‘s true, but it seams that the Singxer-SU6 fills up the lower 8 bits bit serows L The SU-2 does not do that.

Hans Beekhuyzen was pretty impressed. May you share with us what the differences between the two Network chipsets are?

Yesterday I stumbled again over something that I find strange. I use a Singxer-SU6 as a client after the Opticalrendu. Singxer promotes on there webpage that the SU6 can send PCM 32bit over the I2S interface. But it tells the Opticalrendu / NAA and HQPlayer that it can only do 24Bits. Can anyone confirm that? This is what the Opticalrendu gets when reading the client parameters: Singxer USB Audio 2.0(SU-6) at usb-ci_hdrc.1-1.1, high speed : USB Audio Playback: Status: Running Interface = 1 Altset = 1 Packet Size = 72 Momentary freq = 44101 Hz (0x5.8338) Feedback Format = 16.16 Interface 1 Altset 1 Format: S32_LE Channels: 2 Endpoint: 0x01 (1 OUT) (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000 Data packet interval: 125 us Bits: 24 Channel map: FL FR Sync Endpoint: 0x81 (1 IN) Sync EP Interface: 1 Sync EP Altset: 1 Implicit Feedback Mode: No Interface 1 Altset 2 Format: S16_LE Channels: 2 Endpoint: 0x01 (1 OUT) (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000 Data packet interval: 125 us Bits: 16 Channel map: FL FR Sync Endpoint: 0x81 (1 IN) Sync EP Interface: 1 Sync EP Altset: 2 Implicit Feedback Mode: No Interface 1 Altset 3 Format: SPECIAL DSD_U32_BE Channels: 2 Endpoint: 0x01 (1 OUT) (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000 Data packet interval: 125 us Bits: 32 DSD raw: DOP=0, bitrev=0 Channel map: FL FR Sync Endpoint: 0x81 (1 IN) Sync EP Interface: 1 Sync EP Altset: 3 Implicit Feedback Mode: No access: RW_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 11025 buffer_size: 22050 Simple mixer control 'USB Audio 2.0(SU-6) ',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 127 [100%] [0.00dB] [on] Front Right: Playback 127 [100%] [0.00dB] [on] Simple mixer control 'USB Audio 2.0(SU-6) ',1 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 127 Mono: Playback 127 [100%] [0.00dB] [on]

I can answer the question myself. It does support QoS :-)

Strange timing effect: Yesterday I had an effect again that that I can’t really circle in. I had this before and maybe someone has a good idea what is happening. I start listening to music HQplayer -> Network -> Opticalrendu / NAA. Everything sounds pretty good and I enjoy the music. And then after 1 -3 hours the music flow stops just for a short time 0.5 – 2 seconds somewhere in a song. Then the music continues playing by itself just where it stopped. Normally this would be annoying, but when the music continues after 0.5-2 seconds the sound quality is way better than the relative high level it already had. The music is more fluid and the room opens up quite a bit. The music becomes organic in away. My idea is that some software or hardware PLL finally really looks in because all oscillators ( Clocks ) are in sync, or very near to each other so some looking mechanisms starts working properly. Or it’s a buffer fill mechanisms that stops pumping. I’m always happy when this happens because it shows me where the journey can go and what potential still is buried in the system J

Strange timing effect: Yesterday I had an effect again that that I can’t really circle in. I had this before and maybe someone has a good idea what is happening. I start listening to music HQplayer -> Network -> Opticalrendu / NAA. Everything sounds pretty good and I enjoy the music. And then after 1 -3 hours the music flow stops just for a short time 0.5 – 2 seconds somewhere in a song. Then the music continues playing by itself just where it stopped. Normally this would be annoying, but when the music continues after 0.5-2 seconds the sound quality is way better than the relative high level it already had. The music is more fluid and the room opens up quite a bit. The music becomes organic in away. My idea is that some software or hardware PLL finally really looks in because all oscillators ( Clocks ) are in sync, or very near to each other so some looking mechanisms starts working properly. Or it’s a buffer fill mechanisms that stops pumping. I’m always happy when this happens because it shows me where the journey can go and what potential still is buried in the system J

Thanks for the interest Miska It’s a highly modified L.K.S 004 ( 2x ESS9038pro ). I only use the I2S input fed by a highly modified Singxer-SU6. The SU6 is connected to an Opticalrendu. It’s a extremely resolving System. It’s probably one of the most resolving systems in Germany. Well known audiophiles that have been at my place say they haven’t heard anything like it. That’s probably the reason why I notice things that many others just can’t hear with their rig. I had manufacturers at my house that couldn't believe they were listening to a ESS Chip. There is nothing wrong with the ESS9038pro. It’s just the Manufacturers that don’t believe in good PS and extreme good XO’s. And buffers of course :-)

This is so unbelievable and strange. I have modded my opticalrendu to the extremes. So one would think that data coming into the device and being handed over to the NAA Client and then being decoupled from external influences by a big FIFO wold make it immun. Well, it doesn't seam to work to 100%. I can even hear the effects of vibration on the NIC Cards XO of my streaming PC even though there are two highly modified switches between the PC and the Opticalrendu.