Euphony OS w/Stylus player setup and issues thread

[Miska]

3 hours ago, ASRMichael said:

So what is going on with the performance (not sound quality) with AL & Euphony. Seems (in my case anyway) the performance of AL is much faster/more efficient than Euphony. It''s a pity that Euphony cannot cope with my HQ player settings, because I do like the tonal difference that Euphony brings, but without the HQplayer settings I really enjoy, thia leaves me staying with AL for the time being.

 

Maybe the two use different build of HQPlayer?

 

[Miska]

8 hours ago, stefano_mbp said:

It seems the issue is all on HQPlayerd (Embedded) side as there are other issues with upnp gapless.

Unfortunately, Jussi doesn't see gapless with upnp as a major problem ....

 

As far as I know, Stylus - HQPlayer interaction is not related to UPnP in any shape or form.

 

You can queue as many items as you want in HQPlayer's playback queue and HQPlayer transitions to the next ones automatically.

 

[Miska]

Just now, stefano_mbp said:

... then the gapless issue is with and without upnp .... at least with Euphony

 

Then there is something for them to fix...

 

[Miska]

On 3/20/2021 at 4:10 PM, TheAttorney said:

I've attached a screenshot of my RAM BIOS settings. The values on the left are display-only. I can't seem to change them.

One immediate thought: The display shows speed of 2400 despite this model's spec being 2666.

 

What do you suggest the speed and voltage be changed to?

I'm looking for one-shot change - I can't easily keep trying things out in BIOS as I don't have a monitor or keyboard.

 

You don't need to touch any of those other settings. Just select XMP Profile 1 from the "Memory Profiles" list and it should go with the 2666 spec and correct values.

 

[Miska]

7 hours ago, davide256 said:

Interesting. I've tried 1411/24 upsampling to Ares II using Stylus, got lots of static in playback. WIll try this and see if it changes anything with either HQP embedded or Stylus.

Not good though to lose that 5 additional usable bits of dynamic range for an R2R DAC.  1536/24  wouldn't work at all

 

If you use suitable noise-shaper, you don't lose any dynamic range, since it is limited by analog noise floor. Instead you may win on improved SINAD....

 

If you look at Ares II linearity sweep measurement results, it begins to go off around -100 dB. So 16-bit setting is pretty much optimal for it.

 

[Miska]

34 minutes ago, RickyV said:

Could it be that it is a faulty setting in HQplayer? I only use Qobuz. @Miska maybe, any idea?

 

Do you get same results playing Qobuz or similar using mConnect Player app through HQPlayer's UPnP support?

 

[Miska]

9 minutes ago, RickyV said:

So far I have downloaded mConnect lite end I have switched on upnp in Euphony but it only finds my tv. 
Can’t find anything about upnp in the hqplayer user interface.

 

No, you shouldn't be touching any UPnP stuff in Euphony. HQPlayer Embedded has UPnP Media Renderer feature built-in, it is enabled by default and should appear as "HQPlayerEmbedded" in your UPnP Control Point. (your Title setting in HQPlayer settings)

 

Point of this exercise is to use HQPlayer Embedded standalone without Euphony involvement. Make sure you save HQPlayer settings in HQPlayer web interface!

 

[Miska]

17 minutes ago, 87mpi said:

Example: a local 24/96 file in hqplayer input remains 24/96

 

Your DAC can do only 96k?

 

17 minutes ago, 87mpi said:

@Miska

Is it normal that Hqplayer converts streams from qobuz to 16bit?

 

It doesn't... I just tested today too.

 

If unsure whether it is HQPlayer or Euphony related, please boot the HQPlayer OS image and check with it first.

 

[Miska]

58 minutes ago, 87mpi said:

No, my dac is Spring 3 KTE. 

 

In Euphony, if I play a 24/96 file from Qobuz, in the HQPe WI it shows 16/96/2 as input format.

 

This does not happen with local files.

 

If I play a local 24/96 file, in the HQPe WI it shows 24/96/2 as the input format.

 

Then your output should be 786k or 1.536M at 20-bit in case of PCM output, or 12.288M in case of SDM output.

 

How do you play Qobuz then if HQPlayer shows such as source format? How does HQPlayer play view look like?

 

[Miska]

Here's HQPlayer Embedded playing Qobuz to Holo Spring 3:

[Miska]

37 minutes ago, 87mpi said:

On Euphony, If I play a local file 24/96, on HQPe WI at input format I can see 96/24/2 and in output I can see 768/20/2.

If I play the same file, but this time from Qobuz instead HD, in HQPe WI i can see 96/16/2 as input format, and output is 768/20/2.

 

There is something in Euphony messing with the input. What does HQPlayer web interface show about the source? This is why I recommended to try with HQPlayer's UPnP support since then Euphony software is out of picture.

 

[Miska]

54 minutes ago, davide256 said:

I have found Stylus using HQP up sampling to be buggy with Qobuz... looks like buffers in Stylus and buffers in HQP have contention problems

 

What ever plays Qobuz using HQPlayer should just send the content URI to HQPlayer and HQPlayer plays it straight from the cloud CDN.

 

[Miska]

Windows stores local time in the hardware clock. This has problem that when you are traveling and jumping between time zones, it may get confused what the real time is since it has no way of knowing which time zone the hardware clock was set to.

 

While Linux(/Unix) stores UTC time in the hardware clock and local time for presentation is computed by the OS depending on current user's time zone (each user may have a different time zone). This way there's never confusion what time the hardware clock represents.

 

Windows is built to be a singe concurrent user OS where only single user having a specific time zone is logged in at a time. Not that multiple users across the globe are simultaneously logged in and accessing the machine. While Linux/Unix systems are built ground up on the fact that there may be any number of logged in users at any time and they may be located anywhere on the globe, on different time zones.

 

[Miska]

On 11/16/2022 at 5:53 PM, davide256 said:

Auto rate is mostly for PCM up sampling, to insure that 44.1 rates aren't forced to a 48 k multiple and vice versa. Not sure if it applies to DSD.

 

To both yes.

 

On 11/16/2022 at 5:53 PM, davide256 said:

It should not interfere with playback and will prevent aggravation from poor sound due to mismatched up-sampling

 

Why would conversion between rate families affect sound?

 

[Miska]

23 minutes ago, davide256 said:

My experience was that up sampling 48 to a 44.1 multiple or vice versa  yielded degraded sound versus staying with a natural multiple. No  idea whether this was software or some other reason.

 

At least from objective point of view there's no reason for that. I've never noticed a difference.

 

[Miska]

2 minutes ago, Smaragdhk said:

Many DACs including my Marantz SA KI Ruby do exactly that… upconvert to DSD from PCM but based on the base sample rate…

 

Most DACs that support DSD, don't support DSD at multiples of 48k. One example of such is the Marantz HD-DAC1.

 

9 minutes ago, Smaragdhk said:

there are 2 premium clocks, everything for 44.1 kHz  and multiples…

 

And if you use one of the many ESS Sabre based DACs, there's only single 100 MHz clock that is used for all sample rates.

 

2 minutes ago, Smaragdhk said:

It doesn’t make sense to resample one to the other base rate, this only introduces artifacts.

 

No it doesn't if your rate conversion algorithm is proper. For example HQPlayer can do it perfectly cleanly. For example here's HQPlayer conversion of 0 - 22.05 - 0 Hz sweep from 44.1k to 192k:

 

[Miska]

6 minutes ago, Smaragdhk said:

Thanks for the info… The HD-DAC1 is indeed a different DAC from the SA KI Ruby where the latter has it’s own Marantz designed DAC, called the MMM (Marantz Musical Mastering + Marantz  Musical Filtering DAC), concept designed by Reiner Fink. Any incoming PCM signal is up-converted to DSD, and any DSD signal is left alone… the filtering applies to the analogue output. The concept is that DSD sounds the closest to analog vinyl sound as reinforced by the late Ken Ishiwata. Before we get into another rabbit hole this is again a matter of taste :)

 

Yeah, they likely realized that by listening to HQPlayer and then tried to make their own implementation... ;)

 

That upconversion requires digital filtering. They have some kind of algorithm for that. Any DAC regardless of PCM or DSD always requires analog post filter for proper reconstruction.

 

If you do upconversion without digital filtering, you will create a lot of artifacts!

 

Regarding the rate conversions, also remember that a lot of RedBook content has been originally recorded for example in 96/24 PCM and then converted to 44.1k for distribution. Unfortunately many of these conversions are made with less than great algorithms.

 

[Miska]

14 minutes ago, Smaragdhk said:

As the inventor of the CD (Reiner Fink is ex Philips) they pretty much knew this all the time without having to listen to HQPlayer which didn’t even exist at that time ;)

 

HQPlayer existed way before those Marantz devices with PCM to DSD conversion. HQPlayer has existed since 1998. Those Marantz DACs are very recent. Also my DSC1 DAC design was published (Apr 2014) before these manufacturers started to make discrete DSD DACs. And if you look at such implementations, you may see some familiarity. (SA KI Ruby is from 2019)

 

Until very recently, Marantz was using regular off the shelf DAC chips. And they still use those a lot, including ESS Sabre.

 

[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.

[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?

 

[Miska]

1 hour ago, bos3812 said:

A question to you all. I stepped back from Tidal Hifi + to Tidal Hifi. I can't escape the impression that the sound quality has decreased, also for 44.1 Khz songs. I get less air and detail. Does anyone have the same experience?

 

Are they pushing "MQA CD" encoded files to you? That would at least explain...

 

[Miska]

2 hours ago, BCRich said:

Here are my current HQPe settings and my Dac Diagnostics from my Signature Rendu SE Optical. To be honest I am not sure about the Bit Depth; I have a fairly new Bricasti M12 Controller, I have to double check its setting’s.

 

Edit: DAC is ADI 1955; Bit Depth is 24 Bit. Looks like HQP is sending it to 32 on my end as well Not sure the newer MDX Board comes into play here. Both manuals I’ve looked at online reflect those #’s but are dated 2016/2018. I have find the one that shipped with it. I’m pretty sure it is newer.

 

Either way I like how my system sounds using HQPe. If only Euphony gets it updated all would be perfect on my end.  Hope this gives you some food for thought.

Mike

 

If Output Mode is SDM, then DAC Bits doesn't matter as DSD is being sent.

 

But for PCM output mode and AD1955, 24 is correct DAC Bits setting. You seem to have 20 bits set at the moment.

 

Most USB interfaces (XMOS, etc) present "32-bit" format, because it is most efficient for the microcontroller. However, it depends on the DAC behind the USB interface how many bits it can actually utilize. For AD1955 this is 24. The XMOS device could also express the actual resolution, but most DAC manufacturers don't bother, or don't have skills, to modify the USB firmware so that it would tell the correct figures. So the manual setting becomes useful in such cases.

 

Any S/PDIF or AES/EBU is maximum 24-bit. But since the interface is unidirectional, the device at the other end could be also 16, 18 or 20 -bit.

 

[Miska]

15 minutes ago, Johnseye said:

@Miskacan you shed some light on what complications Euphony is having with HQPe?

 

I don't really know much about Euphony, so I cannot comment on that respect.

 

[Miska]

43 minutes ago, Johnseye said:

@Miska Euphony's latest response to me was "it not our issue. It is HQPe integration issue. So we need to wait for Jussi."

If you aren't working with those at Euphony then I'm not sure what's going on.  I'm going to stop stirring the pot and hope that you both are working together.

 

I have not heard from Euphony in a while (some months) and nothing Euphony specific going on. I think their long standing goal has been to replace HQPlayer with something else.

 

[Miska]

6 hours ago, Foggie said:

This is encouraging (at least to my OP) in that it would appear this would work with the Aqua LinQ HQPe module - similar to how roon handles HQP.

 

Yes, if something works generally with HQPlayer, it should work the same no matter where HQPlayer is situated. Including LinQ HQPlayer Core module.