austinpop

Hello, I don't have a problem with any posters that describe their own listening experiences. The nice thing about this thread is that no one is forcing anyone to do anything. If your findings are contrary to what the majority are finding, that does not make you wrong, per se. Different people hear differently, and value aspects of the experience differently. That's all cool. The problem arises when it comes to credibility and motives. Most readers are intelligent and discerning enough to weigh all factors when evaluating a poster's findings and recommendations. Is the person a newbie to the forum? Or do they have a history of posting findings that others have found helpful? Does the poster have a commercial affiliation in the audio trade? This last one is the stumbling block for dealers, distributors, resellers, and manufacturers. I accept that many, if not all, who fall into this category are also audiophiles. And many are used to giving customers (or potential customers) frank and honest advice. But what works in an in-person interaction does not translate well onto an internet forum. As @The Computer Audiophile mentioned, many, many trade insiders have tried to walk the fine line on this forum between their own vested interest and what they consider as unbiased advice. Most have failed. I think you should just accept that as a dealer, you cannot escape the reality that whenever you talk about a product you sell or promote, you will be viewed as biased. That's life. You may want to study the exceptions to the norm - people like @Superdad, @PeterSt - who manage to navigate the forums while declaring their industry affiliation. The trick is to provide expertise on the products with which you are affiliated, and avoid bad mouthing your competitors. Only then do you stand a chance of being heard. And btw - even then it's incredibly hard.

Hi Dev, Please search my NUC impressions from the index. I have compared the SR-4, LPS-1.2, and the sPS-500 powering the CJYH NUC. BTW - for those considering the SR-4... when I bought mine, the highest voltage available was 12V. I just learned that he is now offering these at higher voltages too. The SR4-12 has switch positions for 5v, 7v, 9v and 12v. The SR4-19 has switch positions for 9v, 12v, 15v and 19v. The available output current is 2A continuous and 20A transient. The SR4-05 is a fixed voltage output version with a 4A continuous 20A transient current rating. I don't want to divulge pricing and terms on the forum, but feel free to follow up with Paul directly.

I played around with it for a couple hours late last night. Here are some preliminary impressions: So far I like the new interface changes in Roon. To my eyes, the look and feel has been subtly improved and is quite elegant Qobuz integration is just as you would expect, and similar to Tidal Roon was able to integrate all my Qobuz favorites and playlist with no issues I'm not quite sure how, but some albums from my Qobuz Favorites are already marked as in my library. My expectation was that I would have to add albums to my library, so I am not sure what's going on. It's not a big deal. As @David Craff has indicated a while back, Qobuz is still working to distinguish between the download and streaming resolutions of an album. Just as with its own app, Roon is currently displaying the download resolution, so it can lead to confusion. For example: But this is not a Roon issue, and I'm very hopeful that Qobuz will sort this out soon. Similarly, some albums on Qobuz don't have streaming rights, like this one: On the Qobuz app, these play short 320kbps samples. On Roon, instead of samples I get a "transport error." Again, this will get fixed once Qobuz sorts out its streaming and download designations, so Roon can get the right info. SQ wise, I listened on both Roon and LMS (my up to now Qobuz player) and in my admittedly short listening, I couldn't hear a difference. Of course, this also begs the grand MQA vs. Hi Res Qobuz vs. Hi Res Local comparisons like this: Honestly, haven't we done enough of these already?! I've lost interest. I'd just rather have the hi res version. Period.

So far, it seems to be working exactly as expected with Qobuz. Loving it!

The update just went live for me at least. Updating as I write this...

At long last, the day is nigh... Can't wait!

I’m with you there, Larry. I’m not motivated to try this new feature, but am certainly interested to hear others’ experiences with it. I’m not sure what SQ considerations motivated @hifi25nl to deliver this capability, since it did not originate in this forum. Maybe if we knew more, it would increase our interest. I am very happy with AL as it is now. If anything, I would advise the focus shift to usability and maintainability, but that’s just my opinion.

Yeah, sorry!

What files are in /etc/systemd/network?

?? Not in my experience.

On my machine, after successful bridging, this is the output of networkctl: IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 bridge0 bridge routable configured 3 eno1 ether degraded configured 4 enp0s20f0u2 ether degraded configured

Bob, Not sure why the 0.91 script didn't work. There was a bug in the 0.9 version (missing file) that Piero fixed. Anyway, this is not that hard. You can just do it manually. You want to have the following files in /etc/systemd/network: bridge0.netdev bridge0.network enp0s31f6.network enp0s20f0u4.network Contents of the files are: bridge0.netdev [NetDev] Name=bridge0 Kind=bridge bridge0.network [Match] Name=bridge0 [Network] DHCP=yes enp0s31f6.network [Match] Name=enp0s31f6 [Network] Bridge=bridge0 enp0s20f0u4.network [Match] Name=enp0s20f0u4 [Network] Bridge=bridge0 As root, edit/create the above files as root, then run: systemctl restart systemd-networkd

Hi @Dutch I always encourage people - most of all, myself! - to revisit their optimizations from time to time, just to confirm that they are still beneficial in their current setup. Your question came at a fortunate time where I could easily switch alternate between the direct connection from NUC to endpoint vs. with the optimized switch in the path. I just did the experiment. Yes, the TLS OCXO switch still makes a noticeable improvement in the SQ.

Godspeed, my fine, feathered friend!

Yes, but this is true of both hardware switches and software switches - the bridge0 interface created in Linux, for example, is nothing more than a software (or virtual) switch. On the Ethernet (layer 2), they're not packets, but are instead called frames. Switches use Address Learning to learn which MAC addresses reside on which port of the switch, and then they use Traffic Filtering to only forward frames to a port if the destination MAC address is a match in its learned address table. See https://www.oreilly.com/library/view/ethernet-switches/9781449367299/ch01.html for details. Of course, things get more complicated when switches are connected to other switches, when other mechanisms like spanning trees come into play. Still, the bottom line is - whether connected to a software switch (what we on this thread call bridging) or to a regular switch, after some initial learning, the Ethernet adapter on the endpoint should only see frames directly addressed to it, multicast frames on a group to which it belongs, and broadcast frames. Finally, keep in mind that even if the occasional frame arrives at the Ethernet adapter of the endpoint that is not addressed to it, the adapter will not raise an interrupt with the CPU, but instead silently discard that frame. Let's be careful here. It's tempting to go down a rabbit hole speculating about causality. As per my own OP guidelines, I'm going to curtail that discussion in this thread. However, if you do try listening experiments as you suggest above, by all means, please report the results here!