Euphony OS w/Stylus player setup and issues thread

[di-fi]

2 hours ago, aangen said:

For $30 or less you can buy a Wi-Fi extender that has an Ethernet port on it.

TP-Link Wireless N300. The price is kinda high right now but these things make it easy.

Great idea. And if you can stretch your budget a little more feed the wifi extender with a LPS. To isolate the music stream you can create a separate tunnel for the wifi extender in your home network or use 2.4 ghz vs 5 ghz for music.

[aangen]

Can’t edit for some reason. Look at the N450, $27.99.

 

Fun, I can edit this. I just bought two N450s. They come in handy.

[The Computer Audiophile]

 

[davide256]

13 hours ago, lwr said:

Does anyone know if there is a usb wifi network dongle that is known to work with Euphony v4?  I want to set up a small bedroom system and there is no network hardwire connection there.

Ethernet over Powerline has been more useful for me, assuming that you don't have a bad power grid.

 

Connect one to the router and power outlet near it, connect the other into the server and power outlet

near it and done for ~$50. The only caveat I'm aware of is that you may not be able to use more than 1 per home. 

Actual throughput will likely be less than wired GigE, my older version does 700 mbps.

 

https://www.amazon.com/TP-Link-AV1000-Powerline-Ethernet-Adapter/dp/B08M13B8B6/ref=sr_1_2?c=ts&keywords=Powerline+Network+Adapters&qid=1670601895&refinements=p_89%3ATP-Link&rnid=2528832011&s=pc&sr=1-2&ts_id=1194444

 

 

[flkin]

For us audiophiles that take extreme measures to reduce interference on cables like AC, DC, Ethernet, USB etc and try to isolate them the best we can, I’m not sure that sharing music data through power lines heavily contaminated with electrical noise from fridges, lighting transformers, air-cons etc is a good thing. Moreover surely this adds to the grunge in the AC that needs to be removed later. 

 

A matter of audiophile hygiene! My opinion is wireless signal reconstituted in the listening room is a better approach. We only have to worry about good power for the receiver and the usual best practices to carry the music into the streamer. 
 

But since Euphony/Stylus totally buffers the music data before playback all accumulated jitter and timing issues would be removed. 

 

So perhaps any contamination upstream doesn’t matter? 🤔

[di-fi]

On 12/10/2022 at 2:02 AM, flkin said:

Euphony/Stylus totally buffers the music data before playback all accumulated jitter and timing issues would be removed. 

Interesting statement. Correct me if that’s not what you are saying but this means using buffer in Euphony equals reclocking the signal and making the stream 100% jitter free?

You did not specify buffer used in “ramroot” mode or only “100% buffer” activated in both “ramroot” & non-“ramroot” mode. 
 

Even though I wish this is happening I have a hard time to imagine. To buffer or not in Euphony, the latter should be sounding of much lesser quality (with jittter and less precise timing/clocking). 

What about the chosen buffer or RAM quality, does this have any influence?

 

Thanks for clarifying.

[Yiakubou]

Everytime I tried different SSD or RAM or ramroot, in Stylus modes or HQP, I've never heard any difference. It all sounds the same to me.  Ramroot only added problems to me since it's an experimental feature, so I stopped using it completely. And obviously none of this should have impact on whatever jitter you guys are talking about (e.g. with asynchronous USB audio transfer, the signal going from your Euphony PC is reclocked and jitter is removed or added by receiving DAC/transport anyway).

[davide256]

3 hours ago, di-fi said:

Interesting statement. Correct me if that’s not what you are saying but this means using buffer in Euphony equals reclocking the signal and making the stream 100% jitter free?

You did not specify buffer used in “ramroot” mode or only “100% buffer” activated in both “ramroot” & non-“ramroot” mode. 
 

Even though I wish this is happening I have a hard time to imagine. To buffer or not in Euphony, the latter should be sounding of much lesser quality (with jittter and less precise timing/clocking). 

What about the chosen buffer or RAM quality, does this have any influence?

 

Thanks for clarifying.

 Had to go through some fact finding when I was having problems with a Stylus PC that had only 4gb RAM.

 

Server buffers complete track before play + next track  if it has time before start of play. Only exception I've seen is when running Roon

Stylus Endpoint will start play before full track is received but retains the full track as it is received.

With high rate files (705/ DSD256) Stylus play can abort  due to out of memory on a 4gb RAM machine

 

Other applications such as Roon, HQPlayer and UPNP appear to chunk files  at endpoint as memory use remains small during play.

 

I have not found ramroot, buffer or disk cache to help SQ when using an endpoint but do find that  7i7/8i7/8i3/11i3 NUC

server yields a "dirtier" USB output than USB out from  an Atom endpoint.  If using a 1 box solution, buffer entire album to cache

was worthwhile (reduced processing during play?) but ramroot and disk cache weren't improvements

 

Apacer RAM as well as the FEMTO SSD do help tame digital nasties vs other commercial products if you want to go down the very expensive rabbit hole

of a 1 box solution.

[di-fi]

On 12/11/2022 at 11:57 AM, Yiakubou said:

whatever jitter you guys are talking about

Maybe I was not clear but it was about the (jitter in) upstream part between modem/router and the NIC until the buffer in RAM in Euphony. The signal being totally immune in the upstream part. Not the downstream ''wireless signal reconstituted in the listening room''.

 

The wifi solution is great if the signal is stable, but hardly anyone is using it, as far as I know. It avoids switches, with clocks or not, their power supplies and ethernet cables or similar fiber solutions.

Also wifi could be more (the most?) economical. 

[Yiakubou]

Still not sure what kind of jitter you're talking about :-) If at the end you send the signal to a DAC via USB asynchronous transfer, as far as I know jitter should not matter - it's all just data where audio-related timing aspects are unimportant as there is enough correction mechanisms to ensure your data between router and NUC arrive bit-perfect. After that, it gets reclocked by the DAC, so whatever happens before that is then impacted by DAC reclocking anyway.

 

As for wifi - if the wifi network is not too busy (which can easily happen in dense residential areas) and if it works, it works, so yeah. The only problem I'm aware is that as opposed to ethernet, wifi transfer works only one way - either you are sending data from sender to receiver or the other way around. It does not do both in parallel. This can be a problem for apps like Roon which is sending lots of data back and forth - this is also why Roon guys recommend to use ethernet for the best experience.

[StreamFidelity]

41 minutes ago, Yiakubou said:

as there is enough correction mechanisms to ensure your data between router and NUC arrive bit-perfect.

 

43 minutes ago, Yiakubou said:

The only problem I'm aware is that as opposed to ethernet, wifi transfer works only one way - either you are sending data from sender to receiver or the other way around. It does not do both in parallel.

Now I would have thought that it can only work bidirectionally, because the protocol provides that lost packets are sent again, right? And how should the router know which packets to resend if it doesn't get any information from the receiver?

[Yiakubou]

I didn't say that the router and receiver (or the two ends basically) don't talk to each other. It's just that it can't happen simultaneously on wifi. So let me rephrase:

 

- Ethernet is full duplex data transmission

- Wifi is half duplex data transmission

 

You can read about the differences here for example

[StreamFidelity]

33 minutes ago, Yiakubou said:

- Ethernet is full duplex data transmission

- Wifi is half duplex data transmission

Okay thanks, I got it. 👍 My source: https://wlanport.de/information/wlanwiki/was-bedeutet-duplex-datenuebertragung-im-wlan

 

Addendum: 802.11b/g and 802.11n in the 2.4 GHz and 5 Ghz frequency range as well as 802.11ac on 5 GHz enable the use of multiple channels. Thus, transmitter and receiver can communicate in parallel after all. 

[Miska]

WiFi6 (aka 802.11ax) is the current thing and the one I use. There multiple devices can transfer data to/from access point(s) simultaneously.

 

I have multiple access points around the house, each with it's own dedicated wired connection (powered over PoE). In terms of speed, the wired connection is the limiting factor in my case.

[davide256]

On 12/10/2022 at 2:02 AM, flkin said:

For us audiophiles that take extreme measures to reduce interference on cables like AC, DC, Ethernet, USB etc and try to isolate them the best we can, I’m not sure that sharing music data through power lines heavily contaminated with electrical noise from fridges, lighting transformers, air-cons etc is a good thing. Moreover surely this adds to the grunge in the AC that needs to be removed later. 

 

A matter of audiophile hygiene! My opinion is wireless signal reconstituted in the listening room is a better approach. We only have to worry about good power for the receiver and the usual best practices to carry the music into the streamer. 
 

But since Euphony/Stylus totally buffers the music data before playback all accumulated jitter and timing issues would be removed. 

 

So perhaps any contamination upstream doesn’t matter? 🤔

It‘s no longer about jitter, its about how clean of noise the USB leads are to the DAC connection. I trust a NIC more than I do a WIFI card for least noise generation into endpoint MOBO. You can clean up external wired ethernet noise pretty well with an inexpensive refurbished Cisco Catalyst switch

[di-fi]

4 hours ago, Yiakubou said:

Still not sure what kind of jitter you're talking about :-)

Right, I should have mentioned sound-degrading influences in the upstream Ethernet connection. Like for example the EtherREGEN is designed to radically decrease leakage and clock phase-noise vs. the wifi route. 

[flkin]

On 12/11/2022 at 10:09 PM, di-fi said:

Interesting statement. Correct me if that’s not what you are saying but this means using buffer in Euphony equals reclocking the signal and making the stream 100% jitter free?

You did not specify buffer used in “ramroot” mode or only “100% buffer” activated in both “ramroot” & non-“ramroot” mode. 
 

Even though I wish this is happening I have a hard time to imagine. To buffer or not in Euphony, the latter should be sounding of much lesser quality (with jittter and less precise timing/clocking). 

What about the chosen buffer or RAM quality, does this have any influence?

 

Thanks for clarifying.

 

8 hours ago, davide256 said:

It‘s no longer about jitter, its about how clean of noise the USB leads are to the DAC connection. I trust a NIC more than I do a WIFI card for least noise generation into endpoint MOBO. You can clean up external wired ethernet noise pretty well with an inexpensive refurbished Cisco Catalyst switch

 

Hi Paul, when I referred to "totally buffers the music" I meant that Euphony buffers up to 2 tracks from streaming sources into RAM during playback. Well, that used to be true in V3 but I’m not totally sure about V4. With V4 Stylus this is probably still true but it doesn’t seem like it for other payback options like HQPe or UPnP.

 

I don’t subscribe to the idea that DACs receive bit perfect info and reclocks the data and therefore it doesn’t matter what comes before that. If this was the case, all streamers and methods of sending data would sound the same and this is clearly not the case. In the many discussions on AS, the overall consensus is that there is some attached noise to the signal that causes the DAC to sound different.

 

I believe that clock phase-noise is cumulative and only a very large buffer, while the input is completely shut down, can this phase-noise overlay be eliminated. With a 2 track buffer in RAM this is what I think Euphony is trying to address. With the option to shut down the LAN signal during playback Euphony further attempts to reduce any other signal generated interference from getting through. In my case, despite the LAN card being shut down (data lights off), I’m aware that power might still being drawn through the card (at least for some LAN cards) so I suppose how effective this shutdown technique is depends on the LAN card design itself.

 

Then there is still the issue of leakage currents by way of the connected LAN cable. This new challenge of streamed music might be the main reason why older stand alone CD players without any LAN cables attached still sound pretty good in comparison with streamers. The changes in sound we hear might be to do with insidious high frequency currents moving into or out of attached LAN cables and devices.  Good or bad sounding streamers might have nothing to do with the music bits and how they move information to the DAC but just leakage currents moving through the streamer components and perhaps into the DAC.

 

Anyway, the overall effect of having a LAN cable and all measures upstream to manage the data or whether leakage currents are affecting the sound, can be heard by removing the cable! Since both local and streamed music is fully buffered in Stylus for at least 2 tracks, the streamer can continue to play albeit temporarily without playback controls. I have done this experiment and find that I cannot tell the difference between having the LAN cable attached or not. Therefore I conclude that there is nothing more I need to “fix” upstream of the LAN input.

 

Also whether LAN or WiFi is a better solution, my take is choose whichever is more convenient keeping in mind the above points I’ve raised. But as far as speed of connections is concerned, so long as the 2 buffers tracks are being maintained, it shouldn’t matter which form is faster than the other.

 

All of the above is about the music data and nothing to do with another point of using ramroot to keep and operate the OS in RAM. The concept being to replace OS access to the boot drive with RAM access instead.  The only similarity with music data buffering is that they both should be residing in RAM. That said, I am not sure that V4 Euphony ramroot is working fully as my drive access lights still blink whilst in ramroot so local drive access doesn’t seem to be reduced like it was in V3.

 

Finally if the above clock noise and leakage current smacks of being a John Swensen follower, that is because I am :-D. A lot of his discussions are easy to understand and based on solid common sense and engineering.

 

 

[Zauurx]

There is also the lan card buffer and the type of stream (e.g. multiplied by 2 or 4 depending on whether it's PCM or DSD, or Dop).
I don't know if it's a good idea to put all this in ram on the server, if the lan card is used as a funnel.
It's more complicated + galvanic isolation, etc... and in the end quite simple : big output buffer on the lan card and a cable isolation before the streamer (DX) (and on my system : an independent IPV6 subnet direct -without switch / HQPlayer)

[Miska]

6 hours ago, flkin said:

but it doesn’t seem like it for other payback options like HQPe or UPnP.

 

When you use HQPlayer Client you have option to choose. Playback progress indication, etc will naturally still require periodic network traffic.

 

6 hours ago, flkin said:

I believe that clock phase-noise is cumulative and only a very large buffer, while the input is completely shut down, can this phase-noise overlay be eliminated.

 

Which clock are you talking about?

 

6 hours ago, flkin said:

despite the LAN card being shut down (data lights off), I’m aware that power might still being drawn through the card (at least for some LAN cards) so I suppose how effective this shutdown technique is depends on the LAN card design itself.

 

It is still active unless you are using 802.3az enabled hardware.

 

6 hours ago, flkin said:

Then there is still the issue of leakage currents by way of the connected LAN cable.

 

It is isolated unless spoiled by use of shielded cable. For this reason, always use only U/UTP cables for audio. Or as alternative use optical ethernet to be absolutely sure no electrical stuff goes through.

 

6 hours ago, flkin said:

Good or bad sounding streamers might have nothing to do with the music bits and how they move information to the DAC but just leakage currents moving through the streamer components and perhaps into the DAC.

 

Have you considered using galvanic isolator for the DAC connection?

 

[di-fi]

20 hours ago, flkin said:

Hi Paul, when I referred to "totally buffers the music" I meant that Euphony buffers up to 2 tracks from streaming sources into RAM during playback.

Hi Kin, thank you for taking the time. Great insight, as always ;-).

 

Absolutely my 3 streamers do sound different with the same LAN connection same DAC, I understand what you refer to but the mobo's are very different also.

 

''Buffer albums to queue'' or ''buffer 100%'', you keep using? I will try without album buffer or ramroot (keep OS on Optane) for now.  Buffer being in RAM, even only two tracks, we can not ignore the quality of the RAM, I think you agree?

 

Upstream I isolate with fiber now (router - ER - server network card) so that should be as good as it gets, except for the chosen SFP module. I also try Etherregen (indeed thanks JS!) after the server to the player (Ered-dock or Intel Celeron with two bridged Ethernet ports). 

U/UTP cables to be tested and as Miska mentioned, in Euphony as well, playback progress indication can be disabled. 

[flkin]

19 hours ago, Miska said:

 

When you use HQPlayer Client you have option to choose. Playback progress indication, etc will naturally still require periodic network traffic...

 

 

 

Hi Miska

 

Good to know we can choose to play fully buffered tracks using HQPe. I know from reading other HQP threads that you suggest frequent but low amounts of music data is better than an all at once approach - which you say might cause internet delays on other devices sharing the same internet access. But instead of sipping the data, I prefer to chug the data shot down all at once! What is the setting to fully buffer a track? Playback can start immediately with the download happening in the background is fine too. Can we set it for 2 tracks like what Stylus is doing now? Will fast forwarding be possible once the track is fully buffered? I'm finding that the current HQPe default settings don't allow me to fast forward in Tidal but it's possible in Qobuz but takes many seconds to do so.

[flkin]

19 hours ago, Miska said:

 

Have you considered using galvanic isolator for the DAC connection?

 

 

A few years ago I tried using the optical USB cable Monoprice SlimRun USB 3.0 Type-A Extension Cable  to break the electrical connection for this exact reason. Some people in AS found it helpful but for me it didn't work out.

 

This cable is externally powered so perhaps the power supply I used at that time wasn't good enough. Or perhaps it was the process of switching to optical format and back using a basic internal clock that caused the issue.

[flkin]

5 hours ago, di-fi said:

...we can not ignore the quality of the RAM, I think you agree?

 

Totally agree, different RAM brands sound clearly different! I'm using what everyone said sounded good - the Apacer industrial high temp ECC versions.

[Smaragdhk]

15 minutes ago, flkin said:

 

Totally agree, different RAM brands sound clearly different! I'm using what everyone said sounded good - the Apacer industrial high temp ECC versions.

 

A thought about RAM... if one uses the FEMTO M.2 SSD and set enable "use cache" and disabling  RAM buffering then the tracks are loaded into the FEMTO SSD and played from there... So this totally negates the type of RAM used? 

 

According to the Euphony Knowledge base:

Stylus and 'Use cache' option

Option 'Use cache' is a convenience option which will make a copy of any song added to the queue from external resources (mounted USB drives or network shares) and put it in a special /data/Music/E_CACHE folder. Next time you need those songs, they will be accessed from that cache. This can help in several ways:

• Songs that you listen to often will be available even if your external storage is not attached or your network share not connected.
• Songs will load faster (if your Euphony installation drive is fast) and there will be much less USB or network traffic. If buffering options are not enabled this can also improve sound quality.

[flkin]

54 minutes ago, Smaragdhk said:

 

A thought about RAM... if one uses the FEMTO M.2 SSD and set enable "use cache" and disabling  RAM buffering then the tracks are loaded into the FEMTO SSD and played from there... So this totally negates the type of RAM used? 

 

I think the Cache folder is useful for local storage kept outside of the streamer like on a networked NAS. Automatically copying music to a local drive inside the streamer makes it faster to access and play the next time. Especially if you are playing high res files and using something like the EtherRegen which limits LAN speeds to only 100mbps throughput from it's A to B moats. I don't think this function is designed for fast local storages inside the streamer. Just takes up more space.

 

I'm not an expert in PCs but I gather that playback, no matter where the files are kept, will require the music data to pass through the RAM. Will experts please chip in?