Jump to content

austinpop

Premium
  • Content Count

    4246
  • Joined

  • Last visited

About austinpop

  • Rank
    Credo In Aures

Personal Information

  • Location
    Austin, TX

Recent Profile Visitors

19645 profile views
  1. Thank you. These are outstanding findings. Not only do you confirm the claims about the superior SQ of ECC RAM that Emile, Marcin, et al have been making, the fact that it works in the better sounding ASUS mobo is very exciting. The only shame is that X470D4U looked perfect from a PCIe perspective, since it has 3 PCIe slots without risers, which would be perfect to house a JCAT Net Femto for Ethernet, and JCAT USB Femto for USB. As far as I can see the ASUS only has 1 PCIe slot, which seems more typical of mini-ITX mobos.
  2. Not that I know. Since my library's folder structure is reasonably well organized, I'll look at the file info of the song or album I want in Roon to determine the file path, and then in Stylus, I'll actually use the My Music > Files view to navigate to the album. That said, Stylus' search function, using keywords isn't too bad. it's not as slick as Roon, but usually gets the job done.
  3. Really? You don't think that it's possible to shoot yourself in the foot if you're not careful? A lot of Euphony users aren't OS experts, and even on this thread, it looks like many have already hit issues. I think the KB article spells out the gotchas quite clearly, and was a very welcome addition.
  4. Hi Kin, If you do not eject the USB stick, then you're safe, and you can actually uncheck the "Copy app data to RAM' flag. If you do plan to eject the stick, then do check the flag. When you do, another flag appears, giving you the option to not copy the Roon database. This is because the Roon DB can be rather large for some libraries, and may not fit in available RAM. If you check this flag, then your Roon database will not be available, so your Roon experience will be poor. If your Roon DB can fit comfortably in RAM, then you should leave the second flag unchecked This second Roon flag has no relevance to Stylus. Thus, as long as your Roon DB will fit in RAM, you can in fact run Stylus and Roon+StylusEP in ramroot, booted from a USB stick that you eject after boot, for best SQ. The main caveat of course is that no changes to system state, your library, playlists, etc will get persisted back to the USB stick. But if you're just trying to evaluate SQ, it's very possible. I just don't recommend this as a long term solution for those running audio servers. For endpoints, you can adopt the USB stick boot approach just fine, and in many ways, may be the option with the best SQ. If there's one downside, it's that ramroot boot is quite slow, as copying the root filesystem to RAM disk can take a few minutes. It's much faster with Optane.
  5. I'm not sure what you're asking, so I'll give you my perspective. If you have a more specific question, please clarify. As the KB article clarifies, the Euphony OS resides on 2 disk partitions - one contains the root (aka /) filesystem, while another contains the /data filesystem (config, caches, app data). There are other partitions, but this separation is the key. Note that this is different from AL, where everything is on one partition. I've done extensive experiments on ramroot, both in AL, and now in Euphony, to determine what affected SQ. Out of many, here are a few relevant findings: When booted from a USB stick, there was a definite uptick in SQ when one could remove the stick after boot. In AL this was trivial, due to the OS being on a single partition. In Euphony, it takes some extra prep, which is what the Copy app data to RAM flag is for. While ramroot booting of the OS definitely improves SQ, I didn't notice a further uptick in SQ by having Roon data in RAM disk. Given that the downsides are numerous, this is only worthwhile if booting from an ejectable stick. Booting off an internal Optane SSD, which stays attached, sounded just as good as boot from, and then ejecting a USB stick. This led me to conclude that, with Optane SSD at least, the noise penalty was very low. In any case, the benefit (and burden) of copying app data to RAM only accrues when you can remove the boot drive. If it's fixed anyway in the system, there's no reason to do this copying. One could argue that even with the drive still attached, loading data into RAM reduces I/O and hence noise. However, I didn't find this to be the case - see point 2. Finally, on AL, I had found that playing a music file in RAM disk sounded slightly better than the same file on the Optane SSD, and much better than the file on my NAS. However, this is all moot on Stylus on Euphony. With the benefit of "Use Cache" and "Buffer before play=100%" file playback sounds the same from my NAS, or indeed from Qobuz. The bottom line from all the above experiments - and I must stress, to my ears specifically - is that if you are booting from a USB stick or other ejectable medium, then use the copy flag with ramroot to allow you to safely eject the disk after boot. Just remember not to make any changes to the system, as without the media present, there is no way to save these changes. And if you're booting up Euphony with a USB stick to run server apps like Stylus or Roon Server ... stop! Get yourself an Optane SSD so you can run ramroot with full function, and without risk of data loss.
  6. Well, if you haven’t made any changes, or if you haven’t saved changes, just disable ramroot, and reboot to normal mode. That should be fine, unless there are some gotcha corner cases I’m not aware of. Mainly this is a reminder to not use expert settings casually, without taking appropriate care to understand what the risks and side effects are.
  7. Here's a corrected link to the knowledge base article that should be visible to everyone: https://euphony-audio.com/hesk/knowledgebase.php?article=14
  8. Indeed. To reiterate - only use the "Copy app data to RAM" flag for the specific case where: you're booting off ejectable media like USB stick, AND you're running endpoint services like Roon Bridge, StylusEP, Squeezelite, or NAA. Using this flag for running Roon Server or Stylus is not something I'd recommend, due to the crippled functionality. Avoid the "Copy app data to RAM" option like the plague if you're booting off an internal drive, like Optane or other SSD. These devices can't be ejected anyway, so the whole point of this option is moot.
  9. If and only if you're a geek, here's a couple of "Easter Eggs" that are in this latest release of Euphony. Actually they're not Easter Eggs, since they're mentioned in the release notes: - Added iostat, ifstat display (click on release-number/reg.-status text) This refers to the visual elements in UI here: Clicking on these brings up a dense and decidedly Linux table for each that refreshes every second or so. Like this: Since I'm the one who requested this, I thought I'd at least give a little overview on how and why to use them. These are basically conveniences to observe the system - something you can also do by ssh'ing to the Euphony OS. This comes in partcularly handy if you're using Stylus, as you can confirm caching and buffering. Assuming you're OCD enough to think that the SQ is best when the system has minimal network and disk I/O, you can use these tables to achieve that. Don't pay too much attention to the exact numbers - you're looking for bursts of activity. Some examples - in my case, music is on a NAS: When I enqueue an album using "Add and Replace" I see a burst of network activity (files being read from the NAS) under RX_Data I see write activity on the nvme0n1p1 partition (happens to be /data) under kB_wrtn/s and kB_wrtn After caching is complete, both tables will show minimal activity Don't worry about a small amount of network activity as shown above. That's trivial you can also confirm files are in cache by clicking the little info button on the right edge of each track name Next - when you hit play, there is an intense burst of disk read activity as each track is buffered - i.e. read into a memory buffer. If the above sounds like gobbledygook, please ignore. I did say this was for geeky types.
  10. I hear ya. Rib fractures aren't what they're cracked up to be. And they're certainly nothing to sneeze at. I hope I didn't make you chuckle too hard. Feel better soon. And great to hear about the EtherRegen progress.
  11. Come on @Superdad As OP, I don't want manufacturers coming on this thread and bad-mouthing their competitors. Let's wait until people have had a chance to try this product out and report back with their listening impressions. Customers - not you - will decide things like price/performance and value for money.
×
×
  • Create New...