Maybe when I was mucking about with Desktop, I might have inadvertently started something with that?
Yeh can be. Just properly close / quit the Desktop app.
Before doing RPi troubleshooting
I think i over-hyped myself a bit here. Lesson learnt. Stay humble.
1 Like
Or descend into drunken hubris 
2 Likes
When you hit “Apply”, it won’t reset all the timers, instead you will have running offset, depending on how much time it takes for you each time to go and hit “Apply”. You need to actually restart the hqplayerd process to get another 30 minutes.
For a satisfactory experience I would only use a pi4 and only run naa on it. Although embedded will run on pi4 it will give problems on >= 384. Stick to desktop for trialing. NAA will run perfectly on pi4.
1 Like
Ok, I’ve done what you’ve suggested and connected the SonicTransporter, by USB, directly to the DAC. I had no dropouts. Connecting once again via opticalRendu, I get the dropouts. So your theory about the Rendu having inadequate flow control seems correct.
I’m guessing Sonore is unable or unwilling to fix this, so it seems I need to find an alternative to the OpticalRendu, that handles the data better. Does anyone have suggestions?
Their upcoming OpticalRendu “Deluxe” addresses this according to what Sonore have posted
I thought that was an opticalModule Deluxe, not opticalRendu Deluxe. Or are they coming out with both?
I’m running two headphone-focused systems in two different locations with HQPlayer settings similar to yours, same rate limit, one on a Linux server (Embedded), the other on a Mac Mini (Desktop). Wired Ethernet via several switches (the servers are at the far end of both houses from the listening rooms) to small, low cost fanless PCs (UP Bridge models) running @jussi_laako’s binaries. USB via Intona isolators to DACs (Holo). I may have gone overboard with the endpoints, Pi 4-based endpoints might have done comparably – if one could find Pi 4s anywhere, that is. Just to say that even pretty simple DYI endpoints can do the job well. Optical interconnects are interesting (I used to be skeptical but recent experiences with my speaker systems convinced me.) but a baseline reliable setup is better than a fancy but glitchy one.
2 Likes
You’re right, I might have confused this,
Maybe @Jesus_Rodriguez can confirm if there will be a flow control friendly Rendu coming?
Rendu is flow control friendly, but it requires that the other network infra is also flow control friendly.
Since the flow control is implemented at hardware level, on opticalRendu, this also depends on the used SFP modules (both ends).
On smart switches it typically also requires configuring the switch correctly (some have it disabled by default, some have it enabled by default). On smart switches same goes for the 802.1p (QoS) and 802.3az (EEE) support as well.
UP Gateway for example has more than gigabit bandwidth between ethernet controller and CPU, so it is much less critical. But still good to have to avoid packet losses and related re-sends.
2 Likes
Sometimes dropouts occur.
I am using a media converter between roon and the switch (SFP port).
This media converter does not seem to support flow control.
I changed to a media converter that supports flow control.
As a result, the dropouts have stopped.
2 Likes
I would suggest trying different SFP modules in the opticalRendu and transporter. Different SFP modules might just make the difference regarding flow control.
I’m using the model below in my cisco switches (flow control is off on the Cisco by default, I turned it on for the relavant ports), my ultraRendu is connected to one of the switches and works fine passing PCM1536 / DSD1024 on my network.
SFP and cable I’m using:
10Gtek Gigabit SFP LC Multi-mode Transceiver, 1000BASE-SX Mini-GBIC (850nm, DDM, 550m)
FLYPROFiber OM2 LC to LC Fiber Patch Cable 1GB Duplex LC-LC 50/125um Multimode Fiber Optic Cable Cord
1 Like
I just keep flow control enabled on all ports. Looking at the pause frame statistics, even i9-9900K iMac and similar PC’s benefit from it (it keeps being used). This removes occasional packet losses and associated resends, reducing redundant network traffic.
1 Like
I have no access to settings, but flow control is enabled on the EtherRegen, OpticalRendu, and, I assume, the switch built into the SonicTransporter. But if you think SFPs can have an effect on flow control, perhaps I can explore that.
I’ve tried three pairs of SFPs, both single mode:
Finisar FTLF1318P3BTL, Planet MGB-TLX Mini GBIC LX, and StarTech 1000BASE-ZX.
Are there better SFPs that I should have been using?
The cable is Corning ClearCurve single mode.
I heard from Andrew, of Small Green Computer. He suggested going back to multimode. I’ve just reinstalled the multimode SFPs that came with the SonicTransporter and opticalRendu. I only have single mode cable, but it seems to be working with the multimode SFPs. If it solves the problem I’ll post the result, in case anyone else runs into my issue.
1 Like
I’ve played music for two hours straight, without any dropouts. It appears that single mode SFPs were the culprit. Presumably the OpticalRendu was designed around multimode. I’ll stick to multimode SFPs.
The fiber is still single mode. But since it’s working with multimode SFPs, is there an advantage in buying multimode fiber?
Thanks everyone for your suggestions!
3 Likes