Popular Post austinpop Posted December 31, 2018 Popular Post Share Posted December 31, 2018 Hi Larry, Thanks for starting this thread! While I have not experimented as extensively as you and @romaz, I have done enough to convince myself that the server plays an important role in the overall SQ of the chain. Whether the SQ contribution % due to endpoint/server is 80/20 or 70/30 or 60/40 is determined by many factors, but it is certainly not 100/0 - i.e. that the server does not matter. Funny you should start this thread today, as I just did some experiments this afternoon to study the server contribution. Since I currently have the TLS DS-1 in the house, my i7DNBE NUC was available to try as a server. I wanted to compare it to my current server which is a vanilla Dell XPS 8700 box with a Core i7-4770 Haswell CPU. This box has been "optimized" to the extent that I've removed the PCIe graphics card, and disconnected all the SATA drives. Additionally, I've tuned the BIOS to turn off Speed Step, Turbo, and unneeded devices. The only active storage device is an NVMe Optane 32GB SSD that stores the Roon database and cache. Other than that, it has the stock PSU, and is nothing special. I boot AL from a USB stick and run it in ramroot. Compared to this baseline server, I introduced the i7 NUC, powered by an sPS-500 @ 19V as an alternative Roon Server. In terms of relative capability here is a quick comparison: Here is the layout: Dell Server (stock PSU) | | Router (HDPlex 100W) ---------- NAS (SMPS) ------ | | | ______________________ | | | | |------------------------------- i7 NUC (sPS-500 @ 19V) | | | |-------------------------------- DS-1 (SR-4) > tX-U (LPS-1.2) > QX-5 > amp | | | |_____ JSGT ground ------ TLS OCXO Switch (LPS-1.2) So how did these 2 servers compare? For this experiment, I ran RoonServer on both server boxes, and RoonBridge on the DS-1 endpoint. The Dell and the i7 NUC were very close. Any differences I heard were small, and I'm not convinced I'd be able to distinguish blind. The Dell was a tad more dynamic, but also a tad harsher. This harshness manifests in things like piano sounding thinner and brighter, for example. I think overall, I slightly prefered the Dell. But then I thought - what if I rearranged the deck chairs - I mean, the PSUs? What if I give the i7 NUC the best PSU I have on hand, my SR-4? So I then tried this configuration: Dell Server (stock PSU) | | Router (HDPlex) ---------- NAS (SMPS) ------ | | | ______________________ | | | | |------------------------------- i7 NUC (SR-4) | | | |-------------------------------- DS-1 (LPS-1.2) > tX-U (LPS-1.2) > QX-5 > amp | | | |_____ JSGT ground ------ TLS OCXO Switch (sPS-500) So now I took a new baseline with the Dell as Roon Server, and compared it to the i7 NUC as Roon Server. This time it was no contest. The i7 NUC was sooo much better. The improvement going from the sPS-500 to the SR-4 on the server was quite revelatory. What does it all mean? Other than server quality matters? For me, it means that at some point, I will want to invest in a better server configuration than my stopgap Dell. A good PSU is a must, but the considerations are different. Perhaps something like the HDPlex 200W with the DC-ATX converter or the 400W with built-in ATX rails would suit here. As for the server box itself, I'm note yet sure whether this needs to be a NUC, or something with a higher TDP budget. This remains to be seen. I am hoping to glean more from Larry and Roy's experiments! spotforscott, LTG2010, Dutch and 5 others 3 5 My Audio Setup Link to comment
austinpop Posted December 31, 2018 Share Posted December 31, 2018 Bringing over from the troubleshooting thread... 11 hours ago, ray-dude said: Rajiv, my critical listening stamina is (way) at an end for the day, but I ended up with LMS on both my server NUC (all music files local and in RAM) and LMS on my MacBook Pro (WiFi, accessing files from my Mac Mini file server) These are basically my best/worst case configs, without having to worry about Roon authorization switching. To make swapping back and forth easier on the end point, I'm specifying the server IP in the command line for squeezelite: /usr/bin/squeezelite -s 192.168.4.126 -o front:CARD=SCALER,DEV=0 -b 4097152:97152 -d all=debug -a 50000000:4 -c pcm -x -p 93 Lets me swap back and forth in the start up time for squeezelite (<10 seconds). There is enough network chatter going back and forth between server and endpoint (status stuff) that I'm also experimenting with kill LMS on the NUC and LMS on the MacBook Pro to see if I can detect any delta in SQ. My ears are cooked, so I'm going to revisit things tomorrow with a fresh set of ears. Looking forward to hearing about what you're hearing! I did some comparisons last night, and I think you are on to something. However, I want to do some more listening (with fresh ears) before describing any findings. That won't be until tomorrow. If you do any listening comparisons in the meanwhile, please post your impressions on this thread. Folks - would anyone else like to try this listening test? The hypothesis is that if you are running squeezelite with large buffers on the endpoint, then the difference in SQ between server configs essentially disappears, i.e. the contribution of the server to overall SQ is small to 0. You can do this experiment either by running LMS on the server - reliable, consistent - or Roon Server - buggy, glitchy. Either way, the question is - if you compare 2 servers that you previously thought sounded different (with Roon Server/Roon Bridge for example), does this difference still manifest itself in the squeezelite case? My Audio Setup Link to comment
austinpop Posted December 31, 2018 Share Posted December 31, 2018 34 minutes ago, LTG2010 said: There is a theory that memory is capable of storing the characteristics of the music signal, therefore once buffered it will play back what's stored, therefore if you disconnect the source there should be no big impact, unless you change something on the output side. The problem is when we make a change to the source, in this case the server, reconnect and start up again can we remember clearly enough what the sound was like prior to that change? I don't think I'm skilled enough to do that unless the change and output are simultaneous. For example I'm easily able to ascertain the subtle difference between, switching USB outputs from my PCIE card, Motherboard USB, re - clocking board, etc, which are pretty instantaneous. But when changing server to endpoint which requires re - organizing and a reboot, I'm struggling a bit to remember - my buffers are not so good The experiment I am proposing, which I did last night, and plan to do again tomorrow, does not require a reboot, and can be accomplished within seconds on A and B. This does not require your (human) memory buffer to wait multiple minutes between comparisons! The experiment is to compare 2 servers A and B driving an identical endpoint, E. In my case: A = my Dell XPS 8700 i7-4770 box B = NUC7i7DNBE E = TLS DS-1 with all of these running AL in RAM. For me, the baseline comparison was Roon Core on A and B, and RoonBridge on E. Switching cores is easy: go into settings, and click on the Core to bring up a list of Cores on the network, then select the other Core, and listen. Switch back and forth. Here, I can clearly tell that A driving E sounds different than B driver E. Make sense so far? So the new experiment is to run squeezelite (with large buffers - either my settings ,or Ray's settings) on E. You don't need more RAM. My settings ( -b 2097152:2097152 -a 52428800:4::) require 4GB of memory consumption, and fits comfortably on my 8GB endpoint. You can drive E running squeezelite with either LMS or Roon Core on A and B. If you do LMS, then it is again very easy. Use the web UI to control LMS (not iPeng or another mobile app). Squeezelite by default always attaches to one LMS instance. Say it's connected to LMS A. Play your test track on LMS A and listen. Now go to the web UI of LMS B. On the top right, pull down to select the squeezelite instance. It will prompt to ask if you want to connect LMS B to it. Say yes. Now play back your test track on B. Listen. Rinse and repeat. The situation is messier with Roon Core as server. There is no easy way to detach squeezelite from Core A and attach it to Core B. Probably the best way to do this would be (type menu, then select Configuration): Start and Enable RoonServer on A, then Start and Enable Squeezelite on Endpoint Verify the Endpoint is visible Run test Stop and disable all running Audio Services on A, then on Endpoint Start and Enable RoonServer on B, then Start and Enable Squeezelite on Endpoint Verify the Endpoint is visible Run test Repeat until done. LTG2010 1 My Audio Setup Link to comment
Popular Post austinpop Posted January 2, 2019 Popular Post Share Posted January 2, 2019 On 12/31/2018 at 3:04 PM, austinpop said: The experiment I am proposing, which I did last night, and plan to do again tomorrow, does not require a reboot, and can be accomplished within seconds on A and B. This does not require your (human) memory buffer to wait multiple minutes between comparisons! The experiment is to compare 2 servers A and B driving an identical endpoint, E. In my case: A = my Dell XPS 8700 i7-4770 box B = NUC7i7DNBE E = TLS DS-1 with all of these running AL in RAM. For me, the baseline comparison was Roon Core on A and B, and RoonBridge on E. Switching cores is easy: go into settings, and click on the Core to bring up a list of Cores on the network, then select the other Core, and listen. Switch back and forth. Here, I can clearly tell that A driving E sounds different than B driver E. Make sense so far? So the new experiment is to run squeezelite (with large buffers - either my settings ,or Ray's settings) on E. You don't need more RAM. My settings ( -b 2097152:2097152 -a 52428800:4::) require 4GB of memory consumption, and fits comfortably on my 8GB endpoint. You can drive E running squeezelite with either LMS or Roon Core on A and B. If you do LMS, then it is again very easy. Use the web UI to control LMS (not iPeng or another mobile app). Squeezelite by default always attaches to one LMS instance. Say it's connected to LMS A. Play your test track on LMS A and listen. Now go to the web UI of LMS B. On the top right, pull down to select the squeezelite instance. It will prompt to ask if you want to connect LMS B to it. Say yes. Now play back your test track on B. Listen. Rinse and repeat. The situation is messier with Roon Core as server. There is no easy way to detach squeezelite from Core A and attach it to Core B. Probably the best way to do this would be (type menu, then select Configuration): Start and Enable RoonServer on A, then Start and Enable Squeezelite on Endpoint Verify the Endpoint is visible Run test Stop and disable all running Audio Services on A, then on Endpoint Start and Enable RoonServer on B, then Start and Enable Squeezelite on Endpoint Verify the Endpoint is visible Run test Repeat until done. Just an update - I haven't had time to do this experiment, and will not be able to, due to upcoming travel. I will post when I have any results to share. Bricki and ray-dude 2 My Audio Setup Link to comment
austinpop Posted January 9, 2019 Share Posted January 9, 2019 On 1/7/2019 at 8:21 PM, bobfa said: Help with configuration of AL on a NUC to run Roon Server. I have an i7NUC in the intel supplied case. I have 16GB of RAM and a spare M.2 SSD. I have a NAS that I will keep the music on as there is about 4TB of it to manage! I have an HDPLEX 200 Linear supply on the way to run both the NAS and the Server. I want to compare this to my Sonic Transporter i7 DSP running the stock OS and then build AL for the ST to compare against. I know that Roon wants the boot and database on a fast drive. E.G. SSD. I do not know how big the database and caches get. I have 60K tracks in my main music store. Where do you folks think I should start? Bob Hi Bob, First of all, if you want to know the size of your Roon DB, just look at he size of the Database folder on your current Roon Core. The location of this folder is dictated by OS - see https://kb.roonlabs.com/Database_Location Assuming the database is a reasonable size of under 4GB, say, the simplest option is to use the default Audiolinux Roon locations, which will put the database in the root partition (specifically in /var/roon), which will get loaded into RAM in ramroot mode. This is fine, and should fit easily on a 16GB machine. Make sure you do what @ray-dude suggested, and expand your root partition. On the other hand, keep in mind that any changes you make to your library will vanish on next boot, unless you: either diligently remember to do ramsave every time you change anything, or put the database on a persistent storage. For 2, one option would be to put a 32GB Intel Optane NVMe SSD into the M2 slot. This does require a bit of script editing, as you have to edit fstab to mount the SSD automatically on boot, and tell the "start Roon Server" script to use a different location (on the Optane SSD) as the Roon database location. This isn't for Linux novices. Hope this helps. lmitche 1 My Audio Setup Link to comment
austinpop Posted January 9, 2019 Share Posted January 9, 2019 7 hours ago, Miska said: Why would you have entire Optane just for the database and not running the OS from there? Yes, that is the second part of the recommendation, but I didn't mention it as it does take a little bit of effort to set up, and a lot of people like the USB boot option for its simplicity. Why Optane, and not just a regular NVMe SSD? Well, this whole AL/RAM/NUC experiment was driven by many people observing that diskless units sounded better, when divested of SATA and NVMe storage devices (HDD and SSD). Larry, Roy, myself and others thought that Optane might be a good option to experiment with because: Optane has extremely low latency, and to the extent that the SQ benefits we hear with AL in RAM is due to latency, this would be beneficial Optane is electrically lower power than a standard NVMe SSD. 32GB of Optane consumes 2.5w when active and only 0.8w at idle. Based on these, it was worth trying out. To my ears, the Optane drive adds no noise penalty to the server, while adding a very functionally useful persistence capability: both as a boot alternative to USB stick, and for Roon DB, LMS cache, etc. My Audio Setup Link to comment
austinpop Posted January 9, 2019 Share Posted January 9, 2019 6 minutes ago, bobfa said: So do you put two Optane m.2 drives in the system Roon Server system? No need, Bob. One 32GB Optane m.2 SSD is plenty to store your AL OS, and your Roon DB. It does take some steps to boot from Optane. You have to create / and /boot partitions and dd over the contents from the USB disk. Maybe @hifi25nl would publish a procedure to do so? motberg 1 My Audio Setup Link to comment
Popular Post austinpop Posted January 13, 2019 Popular Post Share Posted January 13, 2019 On 12/31/2018 at 3:04 PM, austinpop said: The experiment I am proposing, which I did last night, and plan to do again tomorrow, does not require a reboot, and can be accomplished within seconds on A and B. This does not require your (human) memory buffer to wait multiple minutes between comparisons! The experiment is to compare 2 servers A and B driving an identical endpoint, E. In my case: A = my Dell XPS 8700 i7-4770 box B = NUC7i7DNBE E = TLS DS-1 with all of these running AL in RAM. For me, the baseline comparison was Roon Core on A and B, and RoonBridge on E. Switching cores is easy: go into settings, and click on the Core to bring up a list of Cores on the network, then select the other Core, and listen. Switch back and forth. Here, I can clearly tell that A driving E sounds different than B driver E. Make sense so far? So the new experiment is to run squeezelite (with large buffers - either my settings ,or Ray's settings) on E. You don't need more RAM. My settings ( -b 2097152:2097152 -a 52428800:4::) require 4GB of memory consumption, and fits comfortably on my 8GB endpoint. You can drive E running squeezelite with either LMS or Roon Core on A and B. If you do LMS, then it is again very easy. Use the web UI to control LMS (not iPeng or another mobile app). Squeezelite by default always attaches to one LMS instance. Say it's connected to LMS A. Play your test track on LMS A and listen. Now go to the web UI of LMS B. On the top right, pull down to select the squeezelite instance. It will prompt to ask if you want to connect LMS B to it. Say yes. Now play back your test track on B. Listen. Rinse and repeat. The situation is messier with Roon Core as server. There is no easy way to detach squeezelite from Core A and attach it to Core B. Probably the best way to do this would be (type menu, then select Configuration): Start and Enable RoonServer on A, then Start and Enable Squeezelite on Endpoint Verify the Endpoint is visible Run test Stop and disable all running Audio Services on A, then on Endpoint Start and Enable RoonServer on B, then Start and Enable Squeezelite on Endpoint Verify the Endpoint is visible Run test Repeat until done. Due to travel, and other projects, it took a while, but I finally completed this study to my satisfaction. The procedure I followed was more or less as enumerated in my quoted post. To reiterate - the key question was this: does the (Roon) server make a difference in SQ, when running: a) Roon Bridge on the endpoint? b) Squeezelite with large buffers on the endpoint? I had already found the answer to a) to be yes, definitely. With regard to b), I found the answer was also yes, with the following specifics: endpoint was TLS DS-1 Servers compared were my Dell and NUC7i7DNBE/Plato X7D. However, there was a wrinkle. Looking at iftop on the endpoint, I noticed that while Roon Bridge maintains a throughput of about 4.5 Mbps, even with Squeezelite (SL), the throughput was only at about 9.2 Mbps. This was puzzling, as I had previously seen the initial throughput with SL to be up to 200Mbps with the i7DNBE as the endpoint. What was going on? It turns out that the DXD streaming limitation I referred to in my DS-1 review was due to the DS-1's ethernet port auto negotiating a speed of 10 Mbps (yes 10, not 100) with the switch. This is the issue Adrian is working with Intel, but as of now, this is the case. What does this mean? It means that even with SL, the initial network traffic is not a firehose, but just a fatter hose. On a 10 minute 24/96 track, it took 3:45 before the network throughput dropped down to 0, once the file was in the SL buffer. Could this be the reason I still answered yes to question b) above? Time for a different test. I now used: i7DNBE as the endpoint Server 1 was my Dell But what to use as server 2? I had run out of options, until I decided to just use my Dell M3800 laptop. Surely, the Dell laptop (running Roon Server on Windows 10) would sound significantly worse than my more powerful Dell desktop running AL in RAM? Don't call me Shirley. First, I verified the network throughput behavior. As expected, Roon Bridge still drives a nice, flow controlled throughput of 4.5Mbps. But with SL, as expected, the firehose is observed for a few seconds, and then throughput drops to 0. Much better! So with this new configuration, back to the question: does the (Roon) server make a difference in SQ, when running: a) Roon Bridge on the endpoint? heck yes. b) Squeezelite with large buffers on the endpoint? yes, but... the delta is much smaller. As @ray-dude analyzed - at some level, there should be no difference at all, since the server is essentially idle for the bulk of the playback. Yet, I do hear a (small, but repeatable) difference. I have no explanation, other than to report what I observed. Certainly, one actionable conclusion is that when using SL, the server contribution to SQ is much smaller, so perhaps it isn't necessary to take heroic (or expensive) measures to optimize the server. I welcome other reports comparing servers between Roon Bridge and SL. Bricki and tapatrick 2 My Audio Setup Link to comment
austinpop Posted January 13, 2019 Share Posted January 13, 2019 31 minutes ago, lmitche said: Rajiv, Nice report and lots to think about here. Off hand, it would be interesting to have you set the NIC on the NUCI7DNXX to 10 mbps and compare that to the TLS-DS1 box both running Roonbridge. Yeah, that might be worth a try... but not sure when/if I'll get to it. I've been playing around with AL so much the past month that I've promised myself to buckle down and finish a couple of reviews that are pending. One thing I did notice before I set it aside is that even in the SL case, the size of the "firehose" was different between my Dell server running AL/RAM, and my Dell laptop running W10. Whereas the desktop firehose was 200+ Mbps, the W10 laptop seemed to top out at about 50 Mbps between Roon server and the i7 endpoint. So yes, perhaps this explains why I still hear a difference between the 2 servers on SL. But this is of course just a theory that the network throughput between Roon Server and SL endpoint IS the cause of the SQ difference. I really can't devote time to this experiment for a few weeks. If anyone else wants to experiment, I would be very interested. 31 minutes ago, lmitche said: I recently terminated my own Cat 6a Ethernet cables. OMG, they sounded great. Later I realized I'd screwed up, and crossed wires meant the cable was running at 10 mbps. They have been left that way, but now I'm running wireless so don't use them. More to come. Intriguing! Keep us posted. My Audio Setup Link to comment
austinpop Posted January 13, 2019 Share Posted January 13, 2019 3 minutes ago, BigAlMc said: Interesting stuff Rajiv and looking forward to those reviews. Meantime any commentary on the difference in SQ of using Roon Bridge vs Squeezelite with large buffers on the same Roon server? Put simply is it worthwhile for me to open my Endpoint, add another 4gb of RAM (which I have anyway) and try the large buffer size in the Squeezelite endpoint? Thanks, Alan Very worthwhile! I’ve described the improvement on the novel thread. i assume you’ve tried the new “experimental” feature on your SE? This is the same thing. My Audio Setup Link to comment
austinpop Posted January 13, 2019 Share Posted January 13, 2019 7 minutes ago, BigAlMc said: Thanks Rajiv, Yup, I tried that on the SE. Knew it used an SL endpoint but didn't realise it was also large buffers. Didn't think the SE had a lot of RAM. I played around last weekend, made progress but ultimately unsuccessfully, at trying Ray-Dudes instructions. Guess I'll reach for the screwdriver and some Putty later this morning 🙂 Cheers, Alan Nuno’s the one who I credit for the idea of running with large buffers. We just replicated their results in the NUC endpoint. Yes, the SE has 8GB RAM. BigAlMc 1 My Audio Setup Link to comment
austinpop Posted January 13, 2019 Share Posted January 13, 2019 1 hour ago, BigAlMc said: Fell at the first hurdle. The Endpoint won't boot on the LPS-1.2 with both 4GB ram sticks in it. Considering buying an 8GB stick on the assumption that one 8GB stick uses less power than 2 x 4GB sticks. Its 1.2v per stick, right? Cheers, Alan 6 minutes ago, seatrope said: I had no luck booting with 1x 8GB stick, Alan. You might have luck with the appropriate 8GB stick selected for low current but it’s borderline even with 4GB on a LPS1.2 for me. Guys, I just checked the DS-1. it does indeed have 2 x 4GB SODIMMs. Quick aside: I installed the dmidecode utility (pacman -S dmidecode) to get detailed info about the HW on the box. Try it - for those inclined to. I am able to run with an LPS-1.2. I can think of 2 reasons: have you done all the low power tunings in the BIOS? As well as turning off all the unused things? What is downstream of the endpoint? The current draw of the USB device can be the biggest factor in whether the LPS-1.2 can handle the load. Alan, are you using your tX-USBultra? That is what I have. This should effectively shield you from whatever the current draw is from the downstream DAC. For the moment, my downstream DAC is the Ayre QX-5 Twenty, which is not bus powered, so its current draw is very low. My Audio Setup Link to comment
austinpop Posted January 13, 2019 Share Posted January 13, 2019 5 minutes ago, seatrope said: Hi guys, @austinpop , I think Alan and I are running i7DNBE boards whereas the ds-1 and celeron are lower power. I personally have activated every low power option in BIOS. Oh OK - I have not tried to run the i7DNBE on the LPS-1.2. My Audio Setup Link to comment
austinpop Posted January 13, 2019 Share Posted January 13, 2019 31 minutes ago, BigAlMc said: Hi Rajiv, Nope, not using the tx-usbultra at the moment so I guess that's an option. But brings other questions into play as I'd need to power it with the spare LPS-1 I kept 'just in case' 🙂if i want to keep the LPS-1.2 on the NUC. Putting a lesser able PSU closest to the DAC seems counter intuitive. Its also a backwards step in terms of the old spaghetti conundrum. Not ruling it out but needs some thought. If your tX-U and LPS-1 are gathering dust, then why not just try it? It'll at least tell you if 8GB will work. That will confirm the theory that whatever is downstream of your NUC was drawing more current than a tX-U does. Then first listen without changing to SL (i.e. with Roon Bridge). Did it degrade the sound? Then fire up SL, and see what you think. No one has the answers. You just have to try it and decide for yourself. My Audio Setup Link to comment
austinpop Posted January 14, 2019 Share Posted January 14, 2019 13 minutes ago, LTG2010 said: The database is at: /var/roon/RoonServer/Database Just copy it over to the new disk that would be the easiest method, or even copy over /var/roon/RoonServer Excellent advice. Just copy over everything under /var/roon and you'll have retrieved all your Roon data. Then trash the old stick and get on with life. Life's too short to nurse an ailing USB stick, trust me. 😛 My Audio Setup Link to comment
austinpop Posted January 21, 2019 Share Posted January 21, 2019 2 hours ago, bobfa said: @hifi25nl Any ideas? 😕I am back working on bridging. I have the 7i7 NUC in the Akasa case and I have the NUC network interface and a Microsoft USB network interface. When setup without bridging the two interfaces seem ok: NOTE that this is with both network cables connected to the router. audiolinux@FairRoon ~]$ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp0s31f6 ether routable configured 3 enp0s20f0u4 ether routable configured But when I run the bridge script in the AudioLinux menu the bridge never comes up all the way. SOOO I build a new USB stick with 0.9. updated the menu to 091 and tried again. I get the following after I run the menu item to bridge the networks networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp0s31f6 ether routable configured 3 enp0s20f0u4 ether routable configured 4 bridge0 bridge no-carrier configuring Now If I move the second network cable to only connect to my endpoint things look like this networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp0s31f6 ether routable configured 3 enp0s20f0u4 ether degraded configuring 4 bridge0 bridge no-carrier configuring When I reboot I get this: networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 bridge0 bridge no-carrier configuring 3 enp0s31f6 ether routable configured The second adapter disappears. I am stuck. I am going to reboot one more time and then try the older Apple USB to ethernet adapter. Bob 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 My Audio Setup Link to comment
austinpop Posted January 21, 2019 Share Posted January 21, 2019 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 My Audio Setup Link to comment
austinpop Posted January 21, 2019 Share Posted January 21, 2019 14 minutes ago, bobfa said: Piero creates something different. ?? Not in my experience. My Audio Setup Link to comment
austinpop Posted January 21, 2019 Share Posted January 21, 2019 What files are in /etc/systemd/network? My Audio Setup Link to comment
austinpop Posted January 21, 2019 Share Posted January 21, 2019 15 minutes ago, lmitche said: BORING - either get a room or exchange email addresses. Debug your network bridge somewhere else! Outcomes only please. Yeah, sorry! My Audio Setup Link to comment
austinpop Posted January 21, 2019 Share Posted January 21, 2019 57 minutes ago, lmitche said: Hi Paul, I have no problem with Piero creating optional capabilities to enhance SQ as long as these capabilities don't interfere with existing SQ. Audiolinux has many "tweak-able" settings that I never use. That's cool, as long as they don't get in the way. FYI, I don't plan to test the CPU task pinning functions offered in the new release. If someone else finds it makes a big impact, I may change my mind. In the meantime I'll ignore it unless it impacts SQ with my preferred configuration. Piero has delivered six to eight releases since August and from my perspective has done a great job testing each release. I can't think of a single release where his testing has been a show stopper in any way. As a software company professional, I can say that maintaining multiple releases in the field gets exponentially complicated and is a major burden over time. I'd hate to place that burden on Piero. 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. My Audio Setup Link to comment
austinpop Posted February 3, 2019 Share Posted February 3, 2019 18 hours ago, lmitche said: A bit over a year ago most of us were firmly in the “one box” camp. Positive reviews of the Innuos Zenith MKII SE seemed to confirm the “one box” approach and raised my curiosity to learn how this was done. Later, looking at a pictures of the internals, the answer became obvious. Innuos was using two separate regulators to power the CPU (EPS) and the motherboard (24 pin ATX) of one motherboard. Using a 19 volt Hdplex 250 watt DC to DC power supply for the 24 pin ATX, and by jumping the pins on my EVGA 1600 watt Titanium ATX SMPS to enable the 12volt CPU (EPS) output, a similar dual power scheme was achieved here. This yielded an impressive increase in SQ. This past August the NUCs arrived. The early thinking was that this new two box solution meant that along with network isolation between the server and endpoint side, “bits would be bits”, and therefore server (dirty) side tweaks no longer mattered. The network isolation would shield the clean from dirty. With this idea in mind, a wifi network isolation scheme was configured here. Later the dual power scheme described above was dismantled with the big EVGA power supply used once again for both motherboard ATX and CPU power. In December of last year the big 200 watt Hdplex arrived. This is the first linear power supply here with the capacity to power a CPU at close to a 100 watts. The separate 12 volt 10 amp rail, and 19 volt 10 amp rail enables many possible dual rail/supply power schemes. Remember the server and endpoint are connected via wifi. Here is what I tested with observations. EVGA 1600 Watt ATX to 12 volt CPU(EPS), Hdplex 19 Volt rail to Hdplex 250 watt DC to DC for 24 pin ATX power Notes: So much for the dirty/clean side idea, this sounds much better then EVGA alone. Image density has increased in the mid-range. Hdplex 19 Volt rail to Hdplex 250 watt DC to DC for 24 pin ATX power and CPU(EPS) 12 volt Notes: Nice high end density, but the low mid image density and bass seem diminished. Hdplex 19 Volt rail to Hdplex 250 watt DC to DC for 24 pin ATX power, Hdplex 12 Volt rail to CPU(EPS) Notes: this is the one, improved image density almost 3d, big depth increase and improved ambience, just spine tingling! It is likely that another Hdplex will find it’s way here in the next few months. I am anxious to test again with two separate LPSUs. In the meantime, the last configuration is the most musical presentation heard here. It should be said that in the final configuration, the 12 volt Hdplex output is used for powering the CPU. This eliminated the possibility of powering my 12 volt network extender with the Hdplex so another 12 volt power supply was used for this purpose. Hence, two things were changed at once. It is possible that the second configuration was compromised with the wifi extender power connection. Thanks to @Rickca for inspiring this effort. Thanks for the findings, Larry. Please bear with me, as I'm not too adept at system building, and the whole ATX specification. So if I understood correctly: the 24-pin ATX connector carries essentially 3.3V, 5V, and 12V -- all derived from the 19V rail using the regulators in the HDPlex DC-DC ATX converter the 8-pin EPS connector to the CPU is from the independent 12V rail? In that case, I wonder if the HDPlex 400W LPS, for a couple hundred more than the 200+DC-ATX, might deliver even higher SQ? The reason I phrase this as a question is that I asked Larry @ HDPlex whether the ATX outputs on the back of the HDPlex 400 were from independent rails. His answer was: "400W ATX LPSU has four independent rails from transformers to support 19V 12V 5V and 3.3V. XLR shares those four rail with ATX output." So I would interpret that as being that: the 3.3V, 5V, and 12V in the 24-pin connector are from different rails - hopefully a good thing however, the 12V in the EPS connector and the 12V in the 24-pin connector share the same 12V rail. A bad thing? Who knows! So the question in my mind is if the HDPlex 200 with the split 12V rail config you used better, equal, or worse than using the big brother 400W Linear ATX PSU. Please correct me if I'm way off base here. My Audio Setup Link to comment
austinpop Posted February 3, 2019 Share Posted February 3, 2019 2 minutes ago, rickca said: t's not clear whether the better SQ Larry is reporting with his preferred configuration is due to using an independent 12V rail from the 200W LPS for the EPS12V or due to differences between the 12V supplied by the 200W LPS vs the 250W DC-DC. Thanks Rick - that's a very reasonable point. We won't know until someone tries both. Since this has been declared OT by the OP, I'll hold further comment. My Audio Setup Link to comment
austinpop Posted February 13, 2019 Share Posted February 13, 2019 1 minute ago, Bricki said: Also I have run out of LPS's Maybe @Superdad should have bulk pricing on his LPS-1.2s. Cheaper by the dozen? My Audio Setup Link to comment
austinpop Posted April 4, 2019 Share Posted April 4, 2019 1 hour ago, rickca said: Did you install the wpa_supplicant package? And did you grovel on bended knee with the humility required of a supplicant? Superdad 1 My Audio Setup Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now