Jump to content

TheAttorney

Members
  • Content Count

    151
  • Joined

  • Last visited

2 Followers

About TheAttorney

Personal Information

  • Location
    UK

Recent Profile Visitors

1369 profile views
  1. This SQ degradation matches my experience of Roon's volume control, but for me it was even more obvious well before I got to the -30db level. It was particularly noticeable when using Roon's auto levelling volume function, which was such a disappointment SQ-wise that I raised the topic on Roon's forum - only to be batted away by that forum's vocal bits-is-bits brigade. In short, I would avoid Roon's volume control (and other DSP functions) when trying to determine the maximum potential SQ. I haven't tried this on the latest Roon versions because I've since moved on to Euphony Stylus. The Roon design team are not as "audiophile" as many here, so it's pot luck whether the next Roon update will sound better or worse than before. I've read some posts that that v1.7 came with improved SQ, but this appears to follow the Law of Unintended Consequences because the team was not claiming any improvement in this area.
  2. Regarding CPU loading by the Web App, the latest March release includes an option to "Optimize UI performance" (in Settings->Music Service". This stops the track play progress displays from being constantly updated. And it does indeed improve Web App CPU usage: On W10, Edge and Firefox are now much the same in the steady state case of playing a music file - both result in a very low total system CPU load of around 3%, and minimising the window has minimal effect. And my Android smartphone's battery doesn't seem to discharge anywhere near as quickly as before, although this is harder to measure objectively. Incidentally. I find I'm using my phone as control app much more these days - the weight/size convenience often outweighing the screen size limitation. The obvious downside of this new option is that there is absolutely no visible indication of track progress - you have to actually listen to the music to know that it's being played 🙂. But at least you can still skip to different parts of the file by clicking/touching the static progress bar.
  3. It may be worth trying buffering, and even ramroot - it should make the playback process a touch more efficient - and 4GB RAM should more than enough for buffering several redbook or mp3 files. I'm not sure where you're booting from, but there's a knowledge base item about booting from usb stick requiring more RAM than when booting from internal drive - can't remember if this only applies to ramroot. Are the CPU/temp graphs and disc traffic tables showing any CPU/RAM/disc overloading when the glitches happen? Finally, Euphony Support is very responsive, so I suggest you raise a support ticket with them - you may be asked to send in some log files.
  4. I can hear this with my 7i7DN fanless NUC. I can also hear the same noise from my 2 laptops, one with an older i7 CPU and one with latest 10th gen i7. Very easily heard with ear next to the keyboard when CPU is under load. It doesn't matter if the laptops are battery or mains driven. I've always assumed it was primarily the CPU vibrating slightly under load, with possibly other components like RAM, clock, etc contributing. That cause is just a complete guess, but I'm sure that it's not specific to NUCs.
  5. Update on Web Browser CPU usage: I hadn't checked this for a few while, but did just now on my brand new W10 laptop, and the results are much better now. Typical total CPU usage when simply playing a file is hovering 2 - 5% most of the time (with occasional higher spikes typical of W10). So not sure what's changed, but CPU now acceptable, at least on W10. My Android phone's battery still seems to discharge rather quickly though. Maybe very system dependent? All this on latest Euphony 20200227
  6. Yes, I've found the web browser side to be very power intensive - I've tried Firefox, Edge and (I think) Chrome on Windows 10. And all consumed significant power. Of these, Edge seemed slightly better. Also the web browser on my Android phone consumed significant power. Way more than, say, running a full screen video. The Euphony team really need to look into this. I've tried disabling any obvious track progress/frequency-of-update displays and and it's still power intensive. Enough to often get my laptop's fan to kick in (around 20-30% CPU usage). One thing that does work is to minimise the window when you're not using the interface. In contrast, Euphony/Stylus on the server end is commendably low on CPU power, at least for my non-DSP usage.
  7. As it happens, I still haven't got it completely right, even after a thousand times 🙂
  8. Actually, there are two separate options: 1. Buffer next track (the original option) 2. Buffer the whole queue of tracks to be played (the recently introduced further option). If you disable both options, then there is no track buffering, so 4GB RAM should be enough to play any sized file in theory (I haven't ever needed to test this in practice). However, I find it strange that @organics1 has gone to the trouble of getting huge DSD files (presumably for SQ reasons), yet continues to struggle with a paltry 4GB of RAM. And thereby misses out on a variety of SQ improvement options. IMO, attention to server improvements (not just RAM) is more important to ultimate SQ than the file type of the music tracks. I am frequently astonished by what can be achieved with my redbook FLAC files (a lot does also depend on the DAC design for this PCM/DSD question).
  9. I've had Lush 2 on both sides of my ISORegen. Between IR and DAC, it replaced a USPCB hard connector, and the Lush sounded better. My 2 Lush's are 0.4M and 0.8M long. I haven't done direct A/B comparisons, but my overall impressions over time is that they both sound about the same. So length is not something to worry about. One unexpected downside of the USPCB is that it is unforgiving if you accidently knock the IR sideways - the total lack of flexibility of this short hard connector means that there is more chance of damaging the USB sockets of the components it's connected to (borne from direct bitter experience). For this reason, I'd go for a longer cable that can absorb accidental knocks better. Regarding my new cables, I'm not ready to post about them yet, as I'm still doing some tests on both BNC and USB. But in a few days time, I'll post something in the "Chords new M -scaler" thread in the DAC forum, as it directly relates to others' earlier posts in this thread.
  10. A great post that answers so many questions, but I can still think of a few more on RAM 🙂: 1. Is 2 better than 1? E.g. is 2 x 4GB better than 1 x 8GB? (Some say 2x is better because of load balancing. OTOH it may result in slightly greater power consumption and noise. And greater cost). 2. Is it a bad idea to mix 2 slightly different memory specs? In particular, a 2400 Apacer and a 2666 Apacer in adjacent slots. 3. How big a SQ step is the 2666 above a 2400 Apacer, compared to a 2400 Apacer above a typical non-industrial RAM? And same question for ECC above non-ECC? I'm guessing there are diminishing returns here. Thank you
  11. As I understand it, "White always connected" means that White is in effect always connected to signal ground, i.e. black. Therefore it is impossible to do TANF on Blaxius2D because TANF has none of the shields connected to signal ground. Anyway, this is a moot point for me now, as I have recently moved on to different cables. Sorry about that Peter, but even though the Blaxius and Lush remain great value giant killers at their price points, it is possible to do better still, albeit at higher prices - much higher prices in some cases. For other suggestions for Blaxius 2D, see my old post #644 here. However, if you found my favourite to be "boomy and fat sounding", then I'm not sure that my other recommendations will be of much use to you. There must be some variables with our different systems that are skewing the results.
  12. And for non-NUC users. whose motherboards support ECC (typically those intended for server, rather than consumer, use), then they can use the ECC version of this RAM, which some have said is a bit better still. ECC RAM: D31.23185S.001 DDR4 4GB ECC UDIMM 2666 CL19 WT
  13. It's not possible to get TANF on Blaxius 2D because of the fixed white wire. So I settled for [W]BY [W]BY as best sounding to me for Blaxius 2D, but it has nothing to do with TANF, which is only suitable for Lush2 (and maybe the non-D version of Blaxius2)
  14. I forgot about the power supply because I already had a spare rail waiting on my PH SR7, so I didn't need to buy anything extra. But yes, upgrading the power supply would indeed be the first thing to do. The supplied one was the usual cheapo switching power supply, which was enough to get a flavour of what the NUC could do, but easily improved upon. This is a whole topic in itself. I don't follow. I am indeed very happy with the Apacer RAM. My only consideration at this point is that I went for just 4GB RAM, which was sufficient to run Stylus even in ramroot mode. But now with the new queue buffer option, that is stretching what can practically be achieved: 4GB is still enough even for 200+ redbook tracks buffered into RAM, but with that amount queued, RAM usage gets to around/beyond 90% and that seems to impact SQ. So now I'm thinking of getting a second 4GB (2400 speed) Apacer. Or spend quite a bit more to get the new 8GB 2666 Apacer, which apparently sounds better still.
  15. Just about every DAC designer in the universe will give a great explanation as to why their super design is totally immune from upstream issues. And you can have a whole series of galvanically isolated devices in the chain, each one of them apparently perfect. And yet.... they're simply not perfect. I think it's more a case that the better the source (the server/streamer with specialist audiophile USB boards, clocks, power supplies etc), the less gain there is to be had from external reclockers/cleaners. I don't have a diagram of WYR to hand, but just connect the White, Yellow and Red wires to 3 of the of 4 pins that are close together (nearest the red dot in the 4 + 2 pin block), and leave the black wire dangling in air. Do the same at both ends.
×
×
  • Create New...