austinpop

Hi folks, I haven't been active in this thread for a couple of years, but have watched with admiration as some of you have really taken this topic forward - both in terms of discovering players that can rip SACDs and in terms of software, like the new SACDExtractGUI. One area that is still a problem for me is the issue of pops/crackles on track boundaries. Usually this is not much of an issue, but it seems to really become problematic when track boundaries are in the middle of a piece. Right now, I'm grappling with this album: This symphony has 5 movements, but is sliced into 42 tracks. Indeed - movement 1 alone has 14 tracks. When I first ripped this album back when @ted_b started this topic, I struggled with pops/crackles, and eventually found the only solution was to rip each entire ISO as a single track, which is how I've been listening. I have 2 questions to pose to the group experts: has there been any progress on this pop/crackle issue in later releases of sacd_extract? I know there was a bug before v0.3.8 that put a non-zero offset at a track boundary, which was fixed. However, that didn't completely solve the issue. I suspect there hasn't been, as I just reripped the DSF files from the ISOs with the latest version of the tools, and the pops are still there. Can anyone give me a brief primer on how to set my own track boundaries? Currently, the 2nd ISO contains movements 2-5, and I have it ripped as a single large DSF file. I'd like to create a custom file (CUE?) where I can tell sacd_extract to create a separate DSF file for each movement. As I understand it, the pop/crackle happens when the track boundary occurs at a point where the audio signal is not silent. I'm thinking if I can hand-pick points track boundaries during a silence, I may be able to eliminate (or greatly minimize) the pops. Thanks in advance for any advice.

A new Mahler release by MTT/SFS is very exciting. This is excellent!

Expanding my listening to another composer with whose music I'm not familiar...

I’m just starting to get to know the Bruckner symphonies, but this album is just incredible.

I have an i7-8700T, so 6 cores/12 threads. I settled on this a while back: 0-3 RoonServer 4-7 stylus 4-7 gstp 8-11 RoonServer and gstp are used when using Roon+StylusEP. Stylus and gstp are used when using Stylus. I will try giving gstp even more resources and see if that helps.

You might be surprised. Exactly. Listen for yourself, and see which you prefer. This is why measuring the power of your particular use case is so useful.

As I’ve reported before, a lower-capacity PSU may “work,” but a higher-capacity PSU can sound much better.

While your meter cannot give you microbursts as @Nenon says, you can still get useful info. Since I don’t know what AC voltage your location has, these current values are hard to interpret. Try setting the meter to display watts, rather than current. Look at watts during - power on - system idle - music playback Assuming you’re in a 220v country, your data already shows something interesting: - EPS and ATX draw about equal amounts of power: 220x0.14 = 31W approx, and 220x0.17 = 37W approx. Validate this by remeasuring watts on your meter. Assuming these power measures are correct, I bet you would benefit from a much heftier PSU - of equal or better quality - to power both ATX and EPS: 6a, 10a or even higher. Remember - amps on your meter are AC amps at 220v, while the PSU current we’re talking about are DC at 19v or 12v.

This stems from an optimization that has been around for some time now, where powering EPS via a separate 12V PSU, or at least a separate 12V rail, yielded dramatic SQ improvement.

Good point, Alex. Low output impedance is a prerequisite for a PSU's ability to deliver instantaneous current bursts. Indeed, I wonder if a PSU's inability to respond instantly to current demand can introduce another flavor of induced jitter in the signal. Maybe @JohnSwenson's white paper addresses this aspect as well?

Yes, please publish your findings here when you get them, along with build details and the exact workload (OS, music player, if HQP - what settings) you used. One useful piece of info that will be useful to others will be the relative consumption between ATX and EPS (CPU). Yes, again - this is not meant to be an exact science. Typically, your PSU should have a capacity several multiples of your observed consumption. But it will tell you, for example the relative weight of ATX and EPS, so you can decide how/where to allocate your resources into the capacity of each rail. Also be sure to observe other infrequent, but intensive workloads, like: library scanning, OS and software updates, for example. And finally, of course, a reminder to look at both peak and steady state.

It's a good question, and one that needs a deep technical analysis. I suspect with the right instrumentation, it would be possible to observe the instantaneous current (and power) demand of a server over EPS and ATX. I just don't know if anyone - perhaps a server vendor - would be willing to publish their findings. I certainly have my suspicions, which I'll list below. Again, note: these are conjectures, not assertions: Current demand of the CPU is extremely peaky, driven both by the workload (software's) utilization of the CPU, the OS and BIOS CPU settings, and by the processor's own management of frequencies, C-States, P-States, and other energy management. A similar profile is likely for ATX as well, driven by the profile of memory accesses, disk, network, and audio (USB) I/O. This could be a contributing factor to why powering network, storage, and USB cards with independent PSUs can be so beneficial. We have been told by designers like Emile of SGM, that reducing latency of OS operations - more specifically, the variance of that latency - positively affects SQ. Well, this same reduction in variance could also be reducing variance in current demand on the PSU. Finally, we have observed the benefits of running the entire OS in memory (ramroot) and buffering tracks in memory before playback (Stylus). Here again, the effect is to reduce the variation in demand during playback, which in turn could be reducing the peaky demand on the PSU. So there is much we don't understand about the causal relationship between PSU size and quality with SQ. But all in all, the above conjectures make me unsurprised that PSUs that can handle extremely peaky current demand, and over-specification in general, have a positive impact on server SQ.

Hi Mario, I don't use HQPlayer, as my DAC prefers native sample rates.

Loving this thread, Brilliant stuff!

First of all, as @bobfa rightly points out, these numbers are AC watts drawn by the PSU, not the DC watts being delivered to the server. I neglected to mention this measurement is only meant to serve as a rough guide. My point about difficulty was addressed at people who are trying to size a PSU for a system that they haven't built yet. Even if you assemble the system, you still need to find temporary PSUs to run ATX and EPS. I don't know - that seems pretty inconvenient to me.

I have been away on vacation travel and having too much fun to stay on top of the forum. I see there have been some questions addressed to me, and a lot of discussion about sizing PSUs. I also see @Nenon (love the EYE!) posted a very helpful guide a few posts up. In my view, we are very far from having a cookbook for specifying the optimal PSU(s) for a server. What we have are some good examples reported here, as well as sensitivity studies - i.e. "I changed this, and observed that" reported by our intrepid experimenters like @romaz, @Nenon, and several others more adventurous than I. My own experiments with server PSUs have been modest at best, and I have to admit every time I muck with switching PSUs, ATX and EPS connectors etc. on my server, it raises my stress level. One thing I cannot stress enough is that all these findings are workload-dependent - i.e. what software you're running. Specifically, my experiments closely follow Roy's, and are based on the fact we are running Stylus and/or Roon+StylusEP, which put almost no load (<1%) on the CPU. All bets are off when it comes to running HQPlayer (not NAA, which is a different workload) on the DAC-attached machine. HQPlayer can be much more CPU intensive, which likely dramatically raises the demands on the PSU over the Stylus/Roon native sample rate applications. Nenon already described the tension between PSU quality and capacity. Ideally, you want a PSU that is of extremely high quality AND extremely high capacity, but we all understand the challenges that brings. The other design principle I would add is "massive over-specification." Just because it "works" at a certain capacity - e.g. 12V/5A - does not mean it won't benefit from 12V/7A or 12V/10A. I suspect the ideal approach - which may be difficult, but is possible if you're motivated - is to get yourself a Kill-a-watt meter, and actually measure AC power consumption (both peak and steady state) for both ATX and EPS. To do this, run your desired system (mobo, CPU, memory, storage of your choice) with the software of your choice, and power the ATX and EPS inputs from separate PSUs (these can be standard SMPS computer supplies) so you can measure power consumption of both PSUs. Once you've determined this, the peak power for ATX and EPS will represent the minimum capacity you need for each. However, this is where over-specification comes in. The higher VA (volt x amps) you can supply over and above this minimum, the better it seems to sound - for a given PSU quality. Sounds complicated? It is - and this is the nature of DIY. The alternative is to spend megabucks on SGM, Pink Faun, or Innuos servers!

This is the feature I posted about several weeks ago. I'm glad it's finally out in release form. Let me know what you think. I've only just returned from some extended travel, so have not yet had a chance to try the official version.

Wow thank you - that is high praise indeed! I am glad you enjoyed the article and found it useful.

Hi Jacques, While I can’t speak for the ER, as I have never heard it with the Bartok, my expectation, based on my experience with the SOtM switch with the Bartok, is that it should make a positive impact. The good thing is the ER comes with a 30 day guarantee, so you can try it for yourself. Ethernet enhancements seem to be very system-dependent.

No I didn’t. In my system at least, the tX-USBultra SE, powered by an SR7, and reference clocked by a REf-10, has always made a huge positive difference. That said, it’s always good to revisit conclusions, so I’ll put that test on my list. I’m traveling the next couple of weeks, so will report after.

Minor system updates SR-7 Molex cables: In my last update, I mentioned how I determined that my precious DR SR-7 rails gave the best SQ powering my switch and tX-USBultra rather than the server. Those findings were using Paul's "standard" DC6FSXL DC cables with pigtails from Ghent to adapt 5.5x2.5 barrel connectors to 6-pin and 8-pin Molex. I had explored suitable cables for servers with Paul Hynes some months ago, and I recently received a set he made me. Here are a couple of pictures: These are essentially a bundle of 3 (for 6-pin) or 4 (for 8-pin) of his standard DC3FS cables - Paul designates them as DC3-3FS and DC3-4FS - with Jaeger on one end and Molex on the other. These things look and feel as beautiful as they are substantial. Using these in place of the standard cables + adapters, the SQ of the server has risen substantially. I also have a Ghent JSSG360 OCC Jaeger-to-8pin EPS Molex cable on hand, and the Paul Hynes cable is notably better. Just more refined, with better transparency and bass slam. With this rise in SQ with these cables, my findings have reversed. I have gone back to powering the server with DR SR-7 rails and reverted to SR SR7 rails for my switch and tX-USBultra. I hope to try the DXP-1A5S boxes that @romaz and @seeteeyou have mentioned with these SR rails to see how much closer I can get to DR-level SQ. I am waiting for @[email protected] to get back to me after his holiday travels. These cables are expensive, but man the SQ is impressive. USB cables: Speaking of expensive cables - I've been using - and quite happy with - a pair Lush^2 cables from server -> tX-USBultra -> M-Scaler for some time now. Having read the glowing reports on the Intona cables, I got a chance to evaluate both the Reference ($729/1m) and Ultimate ($2279/1m). Intona's claims regarding what distinguishes their USB cables is here: https://intona.eu/en/stories/cable. I tried these in both the upstream leg (server -> tX-USBultra) and the downstream leg (tX-USBultra -> M-Scaler). The hype is real. These are outstanding cables. With USB cables, as they get better, I find the biggest attribute to improve is dimensionality - i.e. the extent to which instruments appear more "fleshed-out" and real, actually occupying 3-dimensions. The Reference is a big step up from the Lush^2. It is dead neutral, while sounding more open, spacious, and transparent. I was really hoping the difference between the Reference and the Ultimate would be modest, but no such luck. As good as the Reference is, the Ultimate just takes it to another level. It's the same attributes as the Reference, just more - a lot more open, spacious, and transparent, and dimensional. If price is not a concern, the Ultimate is a no-brainer, and I can see why Roy was so impressed with it. For those like me who struggle to justify the lofty expense, the Reference is a great option, and this is likely the one I'll keep. Finally - as regards which position benefited the most - in my system in its current state, the Intona cables improved SQ the most in the downstream position - tX_USBultra -> M-Scaler. This is what usually seems logical, but I (and many others here) have observed situations where upgrading the upstream leg led to a bigger gain. Not this time.

What a wonderful post! Thanks for your comments. This is exactly the approach I advocate: audition it in your own system, and apply your own judgement to whether performance gains are worth the cost. Enjoy the music!

Some great albums today, on the last day of the Christmas sale.