Jump to content

TheAttorney

Members
  • Content Count

    152
  • Joined

  • Last visited

Everything posted by TheAttorney

  1. I don't have a Zenith server, but based on my own SR Blue to Orange upgrade (on a 3-rail PH SR7 supplying NUC server, M-Scaler and ISORegen), plus the comments of others whose opinions I value, then best to go straight to the Orange. It is better than Blue across the board for only an incremental extra cost. I was particularly impressed that the extra detail/clarity came with a more natural/organic presentation. Great when both these characteristics happen simultaneously. For me. a fuse upgrade is much like a power cord or power supply upgrade. If you know how those can sound, then you'll know what to expect.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. As it happens, I still haven't got it completely right, even after a thousand times 🙂
  9. 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).
  10. 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.
  11. 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
  12. 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.
  13. 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
  14. 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)
  15. 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.
  16. 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.
  17. The Summus may well have some extra tweaks (I don't know), but I wouldn't class the Porcoolpine route as "DIY". My 7i7DN Porcoolpine arrived complete and fully working, including an Optane boot drive pre-installed with free ubuntu o/s. The only action required was to load Euphony s/w to overwrite ubuntu. I also still use its included wifi card for all network access, which can probably be improved upon for SQ, but not for convenience. So the only optional DIY aspect to this purchase was to replace the stock RAM with the better sounding Apacer, and that was trivial to replace.
  18. I suggest you try JSSG360cubed (WYR WYR, all colours connected together other than black) for more bass and warmth. However, a single cable can only do so much if there are weak links in the rest of the system... I see you have a PC or laptop directly connected to your DAC/AMP. In the past, I've also had a W10 laptop with JRiver and Roon and Fidelizer Pro (and more recently a NUC) directly connected by USB to a DAC. And IMO you can't completely get rid of that "digital glare" without doing more significant signal cleaning - by an endpoint like microRendu and/or a USB cleaner/regenerator like ISORegen. Or get a fundamentally better source to start with. The downside to these recommendations is a never ending spiral into madness, but such is life for an audiophile 🙂. So try the above Lush config first, and hopefully that will be enough to stop you going mad.
  19. I've found a link (not the original one I had in mind) to a thread about silver/gold resistivity: here It's on the audiotruth site, which is enough said for many if us. But it does claim that resistivity is not linear to the % gold added. But apart from that, this Mundorf wire is likely to be top of my list for the next time I decide to make another DC cable 🙂
  20. I'm a fan of "silver with a bit of gold" cables, based on past experience of Siltech phono cable and Toxic headphone cables. But one thing puzzles me regarding use as a DC cable: Adding say 1% gold to a silver cable is known to increase its resistance by a proportionally much larger amount. I can't track down the exact values at the moment, but I remember that it increases resistance to significantly higher than copper. A while back, some "sound scientists" were giving the Toxic designer a hard time on this topic. And for DC power supplies it's understood that lower resistance is better (all else being equal). So if this silver gold DC cable sounds so good, then there must be something else going on that trumps the negative aspects of increased resistance?
  21. For the last 2 or 3 updates, I've not come out of ramroot in order to do the update, and I've not noticed any issues in updating this way: I can see new updates when they're available, I can do the updates, and everything still works after any subsequent reboot, all without ever leaving ramroot. As a precaution, I do a "Save FS to Disc" after each update. I'm not sure if even that is necessary, but it's easy to do, so I may as well do it. EDIT: It's not necessary to "check for software updates" because an update tab automatically appears in Settings screen when an update is available. If you don't get this then something is wrong, but I don't think it's necessarily to do with ramroot.
  22. I recently tried both the above and 0 gstp 1-2 stylus 3 with my standalone, no DSP, Stylus on my 4 core NUC7i7DN, but I still went back to my long term 0-1 stylus 2 gstp 3, which sounded more natural and focused (one man's "airy" is another man's "bright"). However, the differences were quite subtle to my ears. The original reason for choosing my long term setting was because, when looking at the CPU load/temp display, Stylus took up the least CPU load, then gstp, with "everything else" taking up the most. Therefore it made sense to allocate more cores to the thing that took the biggest load. But with so many variables, it's no surprise that others get different results.
  23. When in queue buffer mode, I have no issues with clicking on a different track - it plays immediately. But I do have the much smaller redbook FLAC files. I also don't hear much sonic advantages in queue buffering vs single track buffering. For those that do hear a difference, please elaborate what that is and does it only apply to the first few seconds of each track? There appears to have been an improvement to the single track buffering as well: Previously, the next track only loaded at the point I skipped to it, and very occasionally I would not hear the first split-second of that track. Now it looks as if the next rack is always pre-loaded and it's the track-after-next that is buffered when the next track starts. So it's always one step ahead and that seems to work well - so far I've never missed the first split-second of the next track.
  24. 20200124 - Clarified use of HQPlayer Ccontrol API by StylusEP both in Euphony app and in Signal path display in Roon client - Fixed StylusEP playback of DSD files converted to PCM by Roon via HQPlayer Control API - Fixed UI hangup when clicking albumartist in Album info dialog - Fixed NAA endpoint device selection in HQPlayer settings - Fixed initial volume when using StylusEP through HQPlayer Control API - Fixed Artist view list display (sometimes, when songs without artist tag were found in library, nothing was displayed in the list) - Fixed Summus playback mode when using StylusEP through HQPlayer Control API - Fixed Summus playback mode indication when used as endpoint (refresh page if necessary to see current status of Summus playback mode) Looks like a new bug has been introduced with this latest release: "Now Playing" screen doesn't appear when I hit bottom left album icon - there's just a background displayed. This is on both Edge and Firefox browsers.
  25. Question: How many audiophiles does it take to change a light bulb? Answer: 3 (1 to change the bulb, and 2 to argue about how much better the old one was)
×
×
  • Create New...