Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by ray-dude

  1. Looking forward to hearing how it sounds @Dutch I went back and forth on whether the ethernet should have high priority. Between the the OG reports of improved SQ by network bridging (which I interpreted as basically isolating the ethernet segment) and using squeezelite to front load network traffic, it seems that ethernet traffic (or processing ethernet traffic) could be causing SQ to degrade. On the other hand, Roon continually streams data to Roon Bridge. Would a higher priority for ethernet make that interface more predictable/less variable as packets on the ethernet segment continually interrupt the system? The squeezelite buffer experiments and the OG bridged network findings do point to something happening on the ethernet processing side of the end point (which is wild).
  2. Alan, I have 8GB, so I've not tried to cram things into 4GB. With the SQ improvement we've heard with crazy large buffer sizes (still unclear why 2GB buffer is better than 20MB buffer for small audio files), I suspect you'll want to consider 8GB Couple hygiene items above the usual AudioLinux install stuff (make sure to do this will ramboot off so you have all the changes on your USB stick) I'm learning that one can't edit posts here, so if there are typos or incorrect information, my apologies in advance that I'm unable to correct. * Set IRQ priority for the DAC USB to the highest: https://www.audio-linux.com/html/realtime.html Run: rtstatus This will show you the real time priorities for various applications and IRQs (HW interfaces) Run: rtcards This will show you your audio cards. In my case, my DAC is card0, and sits on USB1 IRQ=123 IR-PCI-MSI 344064-edge xhci_hcd Edit: /etc/rtirq.conf Change RTIRQ_NAME_LIST="usb" <--- All the USBs have high priority RTIRQ_PRIO_HIGH=90 to RTIRQ_NAME_LIST="xhci_hcd" <---- Only the DAC interface has high priority RTIRQ_PRIO_HIGH=95 If you like, you can also make your ethernet a high priority by having it be: RTIRQ_NAME_LIST="xhci_hcd eno1" (order matters) This may be helpful if you run Roon Bridge (which streams data continuously). I am using SqueezeLite (more on that later), which buffers the data up front, so I do not have ethernet as a priority (I don't want random ethernet stuff impacting the system during playback) * Set app priority for squeezelite and RoonBridge to be second highest I have squeezelite as the highest priority application. The order in the list reflects priority order if you have multiple apps running. In practice, you'll only have one running, so not something I worried about. I set the max priority for applications to be a hair less than the max priority for the IRQ to the DAC. Edit: /etc/rtapp/rtapp.conf APPLICATIONS="squeezelite RoonBridge jackd mpd hqplayer hqplayerd RoonAppliance mediacenter24 networkaudiod deadbeef a2jmidid ardour-5.12.0 rosegarden audacity" MAX_PRIORITY="93" At this point, if you're running Roon Bridge, you should be able to reboot and confirm that everything is still working fine. Now to the buffer stuff. Alas, Roon seems to be a black box when it comes to buffers. Per Rajiv's findings, it streams data from core to the end point continuously, and I'm not aware of a way to impact that. Given how Roon works (multi-zone, responsive UI, etc.) that is unlikely to change. All that behavior is made better (from a user experience stand point) by having minimal buffers. If you want to play with buffers and try to isolate ethernet activity from streaming to the DAC, squeezelite is the end point of choice right now. Alas, that comes with some "endearing quirks" (skipping, issues when seeking within a track, latency, etc), Whether the delta between convenience and SQ is something you can try and see if it is worthwhile for you. For me, I'm leaving the system on Roon Bridge (for civilian use), except when I'm playing with maximizing SQ. Squeezelite is a bit too quirky right now to impose on people that don't care about SQ. First step is to install squeezelite (if you have AL headless...it is already installed on the full version). From the AL site: https://www.audio-linux.com/html/user_guide1.html (copy/pasted here) If you're tweaking squeezelite parameters to experiment in your system, I found it is easier to do it from the command line. You start squeezelite, test it, hit control c to kill it, modify the parameters, start it again, rinse and repeat. To do this, go to alconf and select "Stop and disable all running audio services" From the command line, after some more experimentation, here is my current squeezelite config of choice in my system: /usr/bin/squeezelite -o front:CARD=Blu2,DEV=0 -b 4097152:97152 -d all=info -a 1000000:4 -c pcm -x -p 93 For you, you may need to change some of the parameters. The -o parameter is the output device. You get this info for your DAC by running: squeezelite -l the -b parameter is the buffer memory that squeezelite preallocates for input from the network (first number) and output to the day (second number). The unexplained finding is that bigger buffers are better. I have it set so that the bulk of the buffer is allocated to the ethernet side. The thinking here is that since we're hearing bigger buffers are better, and having an asymmetric buffer allows us to allocate more buffer space to the ethernet side. Why 4GB vs 2GB matters for 20MB music files is a crazy making question, but I'm blaming Roon Core because they're not here to defend themselves The -d parameter just sets the debug output level so you can see what squeezelite is doing as you experiment. The -a parameter manages the buffer between squeezelite and the OS (and eventually to the DAC). This is still a mystery to me, but above are my current settings of choice (1MB allocated to the buffer, with a periodicity of 4). I'm still working on my Italian to suss out what all these mean, and there is more learning/experimentation to do here. -c says squeezelite only accepts PCM, and -x says no downsampling. Shouldn't effect SQ, I just have them for hygiene. -p sets the real time priority for the squeezelite output thread. Since I set this 93, and I have the IRQ real time priority set to 95. From rtstatus, everything else is 50 or below. Once you have a config that you're happy with, you need to edit and add it to the following file: /etc/conf.d/squeezelite parameters="-o front:CARD=Blu2,DEV=0 -b 4097152:97152 -a 1000000:4 -c pcm -x -p 93" If you go to alconf and select "START and enable Squeezelite" next time you reboot, squeezelite will be started with these parameters Aside from the tactics, here is my high level strategy/thinking for the recipe (all hypothesis driven, we haven't figured this stuff out yet). I would love to hear criticism/correction/redirection on this from others. Goal: Get an end point as focused as possible on moving data from ethernet to a USB DAC, with as little variability and as much predictability as possible (aka, as close to precision real time data streaming to DAC as possible) - Maximize processing/memory allocated to bridging bits from server to end point, to preload data as quickly as possible - Have an end point doing as little as possible when streaming data to DAC (everything turned off, front load network access, etc) - Highest priority given to end point talking to DAC (DAC USB IRQ, squeezelite thread, etc) - Use a stripped down semi-real time OS (AudioLinux) doing as little as possible - Minimize power use (RF, etc.) by shutting everything unneeded off, running in memory, etc. - Use the highest power silicon on a chip system with reasonable power use you can find, and manage the trade off between lower latency (good) and higher power (bad) (as an aside, I'm OK with absolute latency, I just don't want the latency to vary...my working theory is that low latency systems are a proxy for having less variability, because they have faster CPUs, more cache, better components, etc, and less contention and more headroom at any given time) Approach: * NUC with high quality DC inputs, so you have all the goodies combined into single Silicon on a Chip implementation (assertion: there is less variability with SoC) * AudioLinux running headless, tuned for real time, OS running in RAM (max speed, lowest latency) * End point software that allows tuning and optimization and buffering (squeezelite) * Maximum buffers between server and end point (-b parameter), to preload data to memory over the network as quickly as possible - Isolate data streaming to DAC streaming from rest of chain as much possible, for as much of the music playing time as possible * Maximum buffers and priority between end point and DAC (-a parameter) - Feed DAC the steadiest/most stable/least variable data stream as possible during music playback * Have as little as possible other things happening during music playback - minimal network access, no storage access, unused features disabled, lower priority for all other things running in OS, etc All the above is hypothesis, but a snap shot of my current thinking. Many here have been working and experimenting and thinking about this stuff much longer than I have, so I would give their experiences and gut intuition much more credence (I'm still working my way up the learning curve with this kit).
  3. I'm running SqueezeLite R2 1.8.4, but only because that was the first option on the AudioLinux install guide. I haven't compared sound quality, but from the docs it looks like the functionality is aligned between R2 and the community version, but with different flags to enable. squeezelite-R2 Lightweight headless squeezebox client emulator with 'native' DSD support (thanks to Daphile). This is a modified version of squeezelite by Adrian Smith (Triode). At the moment of writing (October 2015), original code is here: https://code.google.com/p/squeezelite/, master branch here is a clone. This version was originally meant to inspect pcm header to detect the real samplerate, depth and endianess, in order to override the wrong information coming from the server when transcoding or upsampling. October, 4 2015 R2 features has been incorporated in Daphile, March, 10 2016 in Audiolinux. Since March, 15 2016 it's included in the squeezebox community version of squeezelite, mantained by Ralph Irving. Download page: https://github.com/marcoc1712/squeezelite-R2/releases
  4. Thank you @mansr for the correction/redirect, and thank you @vortecjr (and Google translate) for the link to the blog post (wow, that clears up a lot of things!) Time to brush up on my Italian and revisit my notes from today. Thanks again!
  5. Fascinating to look at the network traffic while things are running! Really shines a light on what Roon core is doing (the most opaque part of our chains right now). When I recover a bit, I'll repeat my ALSA circular buffer experiments while watching network traffic. I am very hopeful that maximizing the buffer at the OS level (ALSA) and as far away as possible from Roon Core will give us the biggest lift, and the most direct immunity from any transient behaviors from the player, etc. (my spider sense is that the -b buffers are giving us an important but indirect benefit, but the proof will be in the pudding!)
  6. Looking forward to your report Rajiv! I was able to spend some time with the squeezelite ALSA parameters before fatigue set in. From the help page: It is frustratingly difficult to find out what these various parameters mean. From @bibo01 we've learned that the developer of squeezelite r2 uses "-a 499:3::0". The default is "-a 40:4". Others have posted experiences with "-a 499:3" From my hair pulling (aka reading) sessions, I suspect the second parameter is very DAC dependent, but that is a pure guess. In my experimentation with my BluDAVE stack, I found 4 to be the best, but it was very limited experimentation. I spent most of my morning trying different ALSA circular buffer time values. Note that when the buffer time value is 500 or greater, it is interpreted as bytes, and when it is below 500, it is interpreted as milliseconds. This controls the size of the circular ALSA buffer that sits between squeezelite and your DAC (ALSA is the OS-level sound drivers in linux). The period value reflects how the various channels are interleaved in the buffer, and the format value reflects how many bytes to reserve for each value. I got lost in the ALSA docs and source code any deeper than that, so please forgive me if I have any of this wrong. My strategy was to peg the period at 4, and leave the format and mmap values as default (in my case "any" and 1) For those that want to play at home. at the command line, I was running squeezelite manually to make it easier to toggle various parameters: /usr/bin/squeezelite -o front:CARD=Blu2,DEV=0 -b 4097152:97152 -d all=debug -a <various>:4 -c pcm -x Execute the command, give a listen, control-c to kill it, modify the parameters, rinse and repeat Breaking this down, -o points squeezelite at my DAC, the -b reflects stream and output buffer memory that gets reserved on start up (see my previous post above), -d sets out the log output level so I can follow the test in the terminal window (which is very informative!), -c restricts squeezebox to only use the PCM codec, and -x says "don't as the server to downsample anything". -x and -c should be no ops, since Roon Core is streaming PCM to the NUC, but I thought it wouldn't do any harm to disable features in squeezelite and keep things simple. For these experiments. -a parameter is the one of interest to me, as it manages the output circular buffer between squeezelite and the OS and the DAC. Using primarily Redbook content (my Blu2 does all my upsampling) that I am very familiar with, I tried <various> ALSA circular buffer sizes from 1000 bytes up to 1,000,000,000. Since I'm just trying to figure out what all these parameters do (and if they matter), I used a limited number of audition tracks. Fine tuning will come later. The bottom line is I heard a notable uptick in SQ as I increased the circular buffer size, but things got progressively more flakey with Roon Core and latency went way up as the buffer size got to the top end. I found my sweet spot to be between ~50-100MB (very sweet spot actually...delightful!): /usr/bin/squeezelite -o front:CARD=Blu2,DEV=0 -b 4097152:97152 -d all=debug -a 100000000:4 -c pcm -x To triangulate and spot check, a ~4:00 Redbook (44/16) ALAC file is ~27MB, ballooning to ~43MB when decoded to PCM. My hypothesis is that if you can fit the entire PCM content in the ALSA circular buffer, you're as buffered as you're going to get. Set the USB for your DAC to the highest IRQ RT priority and have squeezelite a close second in real time priority, and I'm not sure you can do any better (outside of continued OS tuning to get more and more real time) So how do high res files (24 bit and higher sampling rate, etc.) and DSD files impact this? Is this setting over optimized for Redbook content? My ears and brain are too tired to check today My next step is to experiment with high res content (does 24 vs 16 bit changes the sweet spot?), DSD content (does it work ok?), and longer content (do I need a bigger circular buffer?). The big next step is to see if an extra large ALSA circular buffer enables reallocating precious memory from the squeezelite buffer (the -b parameter above....currently heavily weighted on the streaming (ethernet) side) to the ALSA buffer between squeezelite and the DAC. In other words, if you're willing to live with the latency, does having a maximum ALSA circular buffer (large enough to fully buffer all your PCM content) make the upstream buffering (or running Roon core on the same NUC) less relevant to SQ? I'm hoping the answer is yes!
  7. A quick WIP update on some listening experiments this weekend. Background: I recently replaced a microRendu 1.4 with Sbooster LPS with a ram booted NUC7CJYH w/ single 8GB stick running AudioLinux (now) 0.6 (stock PS while I wait on a new LPS). I have Roon Core on a stock Mac Mini (OSX) connected by vanilla ethernet through vanilla switches to the NUC, and NUC is connected by vanilla USB to a Chord Blu2+Chord DAVE stack. I was surprised and intrigued by the finding that squeezelite (with large buffers) was a better end point than Roon Bridge, and I've been fiddling with squeezelite settings to try and suss out what's going on. Running squeezelite with "-b 2097152:2097152" (2GB application buffer on each of stream input and DAC output) I immediately heard a significant increase in detail and depth, confirming other's experiences in my setup (surprising lift over Roon Bridge and the squeezelite default). Per Rajeev's observations, the larger the buffer, the larger the lift (again intriguing...these music files are WELL below 2GB in size) Some baseline file transfer benchmarks: Using sftp, I moved some large files between my Mac (SSD) and NUC (ram boot) and saw transfer rate of 80-90 MB/sec (as expected). On the NUC itself, duplicating the same files I saw ~570 MB/sec (consistent with the ~600 MB/sec I see when running memorytest on the NUC). As expected, gigabit ethernet is slower than memory (you'd be surprised how often I have to remind my work colleagues about that Since memory is limited on the NUC, and more memory allocated to buffer is improving SQ, would allocating more to the upstream (ethernet) side of the bridge move the SQ needle? At first blush, answer seems to be "Yes", but (intriguingly) so does allocating more to the downstream (DAC) side, but to a lesser degree. Below is my /etc/conf.d/squeezelite file for the buffer settings I tested. # Default #parameters="-o front:CARD=Blu2,DEV=0" # Front parameters="-o front:CARD=Blu2,DEV=0 -b 4097152:97152" # Back #parameters="-o front:CARD=Blu2,DEV=0 -b 97152:4097152" # Balanced #parameters="-o front:CARD=Blu2,DEV=0 -b 2097152:2097152" # Original #parameters="-o iec958:CARD=Audio,DEV=0" Of these, both "Front" and "Back" were better than "Balanced" (detail, soundstage, depth, etc), but with a small edge going to the "Front" config. I have not yet done any systematic testing with less extreme mixes. It seems like larger buffer matters, no matter what side of the bridge it is (wild) My test files are on the order of 10's of MB (<<1 second to transfer complete file from the server to the NUC), so how the heck can 2GB vs 4GB buffer (regardless of side) make a meaningful difference? What is the extra buffer doing to improve the decoupling/isolation? My WAG is something wacky is happening on the Roon Core side and how it interacts with the squeezelite end point (which would be consistent with the weird behavior I have occasionally seen when using Roon to seek within tracks or skipping between tracks). It would be interesting to see if a different core server (eg, LMS) has the same behavior as buffer sizes increase. Next, time to play with the ALSA parameters in squeezelite (-a parameters). I suspect those results will be much more specific to my Chord BluDAVE DAC, but (alas) so far my intuition is batting pretty close to 0.000 when it comes to these NUCs. Brave new world indeed.
  8. Thank you Rajeev I just got my NUC7CJYH w/ 8GB up and running headless in RAM root (thank you and everyone here). Runs great as a Roon Bridge, connected via USB to my Chord Blu2 (then Chord DAVE DAC). Upstream I have a vanilla Mac Mini (OSX) running my Roon Core, not yet optimized. With this setup, I need the end point to just pass things bit perfect to the BluDAVE and let it do its (considerable) magic. The tunability of the Squeezelite end point (vs Roon Bridge) seems like a great opportunity to dig in and figure out what is driving the SQ boosts we're all hearing. My /etc/conf.d/squeezelite settings are: parameters="-o front:CARD=Blu2,DEV=0 -b 2097152:2097152" (piggybacking on your findings that maximizing buffers makes things better, although I'm wondering if weighting more towards the input or output would move the SQ needle...TBD) However, I was also looking at the real time priority, parameters for connecting to the DAC, and even codec settings as potential SQ levers (TBD how the stew of latency and compute and OS priorities all come together when you expand the test matrix) I hoping to dive in this weekend and start doing some investigations. If you (or others) have run into dead ends or opportunity areas with Squeezelite as the end point, it be great to build on that!
  9. I was playing with this last night. the alconf option 1 invokes a script to copy things back to the USB. If you are in RAM mode and the USB is removed, the script basically errors out. If the USB is inserted and you're in RAM mode, the changed files will be copied back to the USB while you continue to run out of RAM. If you're not in RAM mode, the changes you're making are direct to the USB and available for the next reboot
  10. @austinpop Thank you for the additional impressions. May I ask where you ended up with your end point SqueezeLite parameter settings? (your /etc/squeezelite.conf ) I've just stood up my NUC7CJYH as a Roon Bridge end point, and want to experiment with the Roon Server/SqueezeLite end point configuration that you developed (alas, I confess that the myriad of SqueezeLite parameters are all still pig latin to me)
  11. On the mother thread, @Narcissus asked about Ramboot: It does "auto yes" For convenience when running headless, I made the following change: Edit /usr/bin/ramroot and change LOAD_TIMEOUT_DEFAULT=15 to LOAD_TIMEOUT_DEFAULT=3 That changes the wait time at the "Y/N" prompt from 15 seconds to 3 seconds
  12. This is a very helpful description, thank you Larry. I am still trying to get my head around how the server side could be having such an impact (not questioning whether it is real, just commiserating with the happy question of "why?"). How can an ethernet-based transport be impacted by the upstream server, esp. with different transport protocols? (RAAT, etc) I was noodling on this on the drive in to work this morning. For those with multiple server NUC configurations, if you are running both at the same time on the same network and streaming to different end points, is there any cross feed in SQ? That is, if you are listening to A-level server talking to A-level end point, do you hear a SQ change if B-level server starts streaming content to a B-level end point on the same network? (bonus point if on same switches) Back to lurk mode while I wait for my NUC to arrive
  13. I thought this amp in bridged mode was something VERY special with my B&W 802d3's. Definite lift vs running in stereo mode, but I couldn't justify a 2nd amp (I ended up very happily running it in stereo mode with my 802d3's)
  14. Thanks @d_elm. My understanding (very loose, since we only have been able to speak briefly) is that he recommends a specific 6AWG cable. I suspect it is solid core (based on posts of others), and the typical 6 AWG (and 8AWG) power cable is stranded. Jim recommends the 10 AWG Romex, which is also solid core. I've been poking around, but I haven't (yet) found any solid core options in 6 AWG or 8 AWG. I defer to others who've been able to work with Jim more than I have to clarify one way or the other (I hope to chat again with him this week)
  15. When I (briefly) spoke with Jim this week, he had basically given up on getting more 6 gauge wire (something about a minimum order being in the 6 figures). At this point, it seems to be unobtanium, but I may have misunderstood him. You should give him a ping Bruce. I'm having some electrical work done this week for an electric wall charger, so I'm punting and having 2 dedicated lines put in with standard 10 gauge solid core Romex. If in the future Jim is able to source his 6 gauge wire (or Roy decides to have his house torn down and has some spare sitting around I'll just have those runs rerun. Once the lines are in place, I'm hoping to be able to audition some of Jim's power conditioners, and perhaps experiment with various combinations using the 2 dedicated lines (various permutations of analog/digital and high/low power draw, etc) I too have a Chord setup, so Rob's hypothesis that the Chord DAVE power supply is adversely impacting adjacent systems (detailed in the link to Roy's post on head fi) is worth testing in my setup.
  16. ...or Out of Your Head (https://fongaudio.com/out-of-your-head-software/) which is based on the Realiser I believe (free to try)
  17. Frans, do you have an ISO extract process/tool pipeline that is reversible? Having ripped 200+ SACDs, I'm really leary of tossing the ISOs without full confidence that I'm not irrecoverably tossing something that was missed or dropped or changed in the extract process
  18. Rob is elbow deep with his own efforts with his analog to digital converter (Davina) using the same mScaler, and 40 element pulse array (32bit + 8bit headroom) to get to same, but that will be a while until that is commercially available. Some high quality recordings mScale'ed to 768kHz (and even 384kHz to be playable by more people) would be quite revealing to folks I think. The Blu2 really is a revelation.
  19. Blu2 owner here, with symmetric gigabit fiber to the home and no data caps Happy to help however makes sense Me and my buds have been day dreaming similar schemes: they're addicted to mScaler, but at their budget ceiling with their Hugo2's. It would be worth the disk storage and bandwidth to save my wine cellar
  20. LOL, it is a bit embarrassing, isn't it? All ribbing for the ferrite shame is well deserved and well earned. FWIW, the context here is hearing the CD transport in the Blu2 be staggeringly better than the USB input. For a "bits are bits" guy, that was a massive slap upside the head, and I did apologize to everyone that obsesses over the digital chain in my review In the case of what I was doing with Chord Blu2 + DAVE specifically, my objective was to get the USB input to sound as good as the CD, with the hypothesis that degradations on the digital side were what was dragging it down. The ferrites and cheap digital cables got me there, which is awesome, so I didn't need to get to that next level with more exotic digital cables. I'm not averse to same (esp. on the analog side), but I tend to build up to diminishing returns rather than jumping in at the top (It's more fun and I learn more that way). Based on what I've heard though, I'm pretty sure with better transducers (likely the Voxativ's), I'll be in a position to hear even more upstream refinements and get even better than the CD transport direct, which is why I'm very grateful to lurk here and learn from everyone's experiences. Once I step up my transducer game and work on the analog side of the fence some more, I'm sure to swing back to power to the DAC, then head back upstream to the digital side.
  21. I should say (since I haven't been active here) that with the Chord BluDAVE driving Omega SAMs direct, I really key off timing detail and soundstage queues when looking for degradations. With solid well recorded content, in my experience the most ephemeral soundstage feature is height resolution, followed by depth resolution, then a collapsing of timing/attack detail and lateral resolution. At its best, the soundstage is absolutely holographic: seemingly infinite resolution, and a true surround image (with binaural recordings, it is like listening to at atmos mix in 2 channel, but with vivid spatial detail). With choral recordings, you can clearly perceive the height of the various singers as they stretch back and up on their risers. It is eerie, and the near continuous depth queues quickly collapse when RF noise come into the mix (apparently for reasons Rob cited in his post).
  22. I did not try those, but I did give these Canare cables a shot: https://smile.amazon.com/gp/product/B0010CIW98 I heard no difference at all vs the $2.50 Monoprice 2m BNC cables with ferrites, and maybe the very and very occasional slightest of expectation bias induced difference with no ferrites (even then it was maybe 1 out of 6 trials as I swapped back and forth? I marked it a equivalent) In my case, it is ultra specific to what works between the Chord Blu2 and Chord DAVE DAC, so very difficult to generalize from that.
  23. https://www.head-fi.org/threads/chord-electronics-dave.766517/page-627 Larry, this post from Rob Watts may be helpful to your process. Looking forward to hearing about your progress.
  24. Larry, I'm not at home right now for photos (all the cables are also back in my music cabinet now), but I ended up with the following: Tripp Lite 2m USB cable with 2 built in Ferrite Chokes (U023-006) ($2.68) https://smile.amazon.com/gp/product/B003MQ29B2 40 (!) Topnisus ferrites ($8.99 for 10 pack) https://smile.amazon.com/gp/product/B01E6PLXXC?th=1 I placed the ferrites as close to Chord Blu2 as I could. With USB going into the Chord Blu2, I could hear clear improvement as I clipped them on one by one up to about 20 ferrites. After that, changes became very marginal. I could hear no changes after 25-30. Since I had the ferrites anyway, I keep all 40 on the USB cable (it is as good a place to store them as any). When I tested the ferrite'ed USB cable vs a bare cable going into the DAVE USB, there was only a very small difference. The massive difference was when going through the Blu2. Since Blu2 is such a MASSIVE SQ lift for the DAVE (you have no idea), it had been hiding the USB degradation, until I listened to the Blu2 CD directly with USB disconnected. It was only then that I could hear what the Blu2 was really capable of. Separately, the Blu2 is digitally connected to the Chord DAVE DAC through dual BNC cables. I use 2m Monoprice 75 Ohm cables. While 2m vs 1m made a difference (I heard no difference going to a 4m BNC cable), I heard no difference with more expensive 2m Canare cables (I did not try anything more exotic). On the Monoprice BNC cables, I recommend 5x Wurth 2.5GHz ferrites on each cable, positioned to be as close to the DAVE inputs as possible. In my review I used the 1GHz Wurths. I later got the 2,5GHz Wurths, and noted a VERY small improvement over the 1GHz Wurths. In my case, I have 5x 2.5Ghz Wurths and 4x 1 GHz Wurths on each cable, because that is as good a place to store them as any (I could not hear any real difference past 5x 2.5GHz Wurths in my setup) I will say that physical cable management was *extremely* important before I had the ferrites on the cables. Even minor changes (what they were touching, proximity to other cables, etc) had a huge impact. It made my initial tests extremely challenging to unravel. I did not revisit sensivity to physical positioning after I loaded up on the ferrites (once bitten, twice shy). I'm still careful with physical management (no looping of BNC cables, don't touch power cables, etc), and I use the following neoprene cover to help keep the mess from going all over the place https://smile.amazon.com/Kootek-Management-Concealer-Organizer-Reversible/dp/B01GCS77TU (and it also serves to hide my ferrite shame) All these ferrites are basically RF hygiene, and keeping that RF (whether from the streamer or the Blu2) out of the DAVE. I have done nothing on jitter and clock management/optimization, and as I mentioned, have a very modest blue collar Sonicorbiter SE/iFi PSU ($360) as my Roon Bridge, connected by ethernet to a stock network switch and stock Mac Mini and MacBook Pro for my Roon Core. Ray
  • Create New...