A novel way to massively improve the SQ of computer audio streaming

[lmitche]

7 minutes ago, agillis said:

 

This is a DIY thread. and yes I am a vendor. All of my products started as DIY ideas. We improve them productize them and bring them to the masses in the form of easy to use products.

 

But it all starts with people working together to try new possibles.

 

Turning over new rocks is how all great products start.

Right, so you can make money from our ideas. I'm outta here!

[the_doc735]

59 minutes ago, agillis said:

 

You could PXE boot Linux over the network and run a computer completely from RAM with no hard drive, SSD, or boot drive of any kind. This is not that hard to do and there are instruction on the internet to set up something like this.

 

But from my experience you would still be subject to all the other electrical noise in a computer. The best option is always to separate the server from the network player The configuration would be to use a network player with a small Linear supply powering each component on the board, not SSD drive and a small low power low noise ARM CPU.

 

This way you would eliminate all the noise from SSDs etc, all the noise from switching power supplies, and all the noise from large fast CPUs. This design is already available commercially. It's an ultraRendu.

got a chance of a microrendu 1.4, the precursor to the 'ultra', for a very reasonable price.

[agillis]

2 minutes ago, lmitche said:

Right, so you can make money from our ideas. I'm outta here!

 

You are posing your ideas in an open forum for the free use of all. I sure there are many industry people reading this thread.

 

It's important that the ideas of the DIY community are turned into products so that non DIY people can benefit from them.

[the_doc735]

43 minutes ago, romaz said:

 

Your jumping into this without a full understanding of the context of what has already been discussed.

 

I wasn't going to name names but this cheap NUC we are talking about is completely diskless while the ultraRendu is not.  Even a microSD card creates some noise to the extent that people are reporting differences when they swap out the standard microSD card with an SLC card.  Furthermore, a microSD card is not a low latency drive.  Lastly, as I've stated, I'm not so sure a low noise ARM CPU sounds better than an x86-based CPU when it comes to Roon.  Having heard both the ultraRendu and even the Signature Rendu SE on several occasions, while these are very good sounding devices, to my ears, I would say they are roughly on par with a similarly well powered SOtM sMS-200ultra.  This cheap NUC with its noisy switching regulators is performing at a higher level.  

completely diskless! ~ how so?

[romaz]

If anyone deserves to monetize what has been learned here, it is Larry.  His contributions ranging from JSSG360 to the tricky implementation of AudioLinux in some of these NUCs with quirky BIOSes are much appreciated.  True to his giving nature, Larry has refused to thus far accept any compensation from me for his time and even for shipping.  

[seeteeyou]

17 minutes ago, romaz said:

Having said that, everything is working smoothly and so there would also be the option of using something like a 64GB USB stick as nonvolatile storage for the Roon database.  For those with a giant library, it will impact the browsing experience as it will be slow and so that would be the downside.

 

Could an eMMC drive (with USB adapter) provide decent performance as well as relatively low noise?

 

https://www.pine64.org/?product=usb-adapter-for-emmc-module

https://www.pine64.org/?product=64gb-emmc

http://www.foresee.cc/en/Business/index.asp?itemid=93

[agillis]

2 minutes ago, romaz said:

If anyone deserves to monetize what has been learned here, it is Larry. 

 

That for sure. Building a Linux Distro is a huge amount of work! Nice job Larry.

 

I see that AudioLinux charges for support. That's a great business model.

[BigAlMc]

9 minutes ago, lmitche said:

Right, so you can make money from our ideas. I'm outta here!

 

Hi Larry,

 

Sorry but I think this is a bit harsh.

 

We greatly appreciate your contributions here and you without doubt have a right to be very proud of your pioneering efforts.

 

But personally I lack the skills to tackle a lot of this myself and as such I'm very glad to see Andrew and other vendors trying to understand what is being discovered and learned here.

 

Unless a vendor makes it simple the likes of myself and a few others simply won't get to the dizzy heights you're achieving.

 

Cheers,

Alan

[austinpop]

17 minutes ago, romaz said:

 

Larry brought up these issues and his solution is to maintain the Roon database on an Optane drive.  I have not tested this but it makes sense.  In theory, this drive probably won't be accessed too often and hopefully, will contribute more positives than negatives.  Right now, the Roon database is completely on the USB stick and so with the RoonServer machine, I am unable to unplug the USB stick.  Having said that, everything is working smoothly and so there would also be the option of using something like a 64GB USB stick as nonvolatile storage for the Roon database.  For those with a giant library, it will impact the browsing experience as it will be slow and so that would be the downside.

 

If, as we suspect, the audio benefit comes from reducing latency, then it would seem beneficial to load the Roon DB into RAM as well, as part of the ramroot configuration.

 

I did a quick check on my W10 Roon Core, to see how big the Roon DB really is. My Roon library has ~1500 albums for a total of ~14000 tracks. I estimated DB size by looking at the size of the following directory: %localappdata%\Roon\Database, and it is 1.27GB. Indeed the whole %localappdata%\Roon directory is 1.75GB.

 

Assuming a machine with a generous amount of RAM (16GB?), is there any reason why it wouldn't make sense to just load this into RAM at boot? Obviously, it does take discipline to make non-volatile changes, like booting in non-ramroot mode before making any changes.

[seeteeyou]

It would be quite interesting if we're running an ARM-based Roon Bridge / Roon Ready devices with an OS like this, especially when there's an OCXO or two

 

https://forums.slimdevices.com/showthread.php?106833-Store-files-permanently-on-piCorePlayer

Quote

One of the "selling" points of Pcp is that it runs entirely from ram (with exceptions) making it pretty much immune from disk corruption from unsafe shutdown (pulling the plug)

 

http://tinycorelinux.net/concepts.html

Quote

Tiny Core boots entirely into RAM.

 

For instance, this one came with 2/4GB Dual Channel LPDDR4 plus full-sized PCIe x4 slot

 

https://www.pine64.org/?page_id=61454

 

[romaz]

13 minutes ago, seeteeyou said:

 

Could an eMMC drive (with USB adapter) provide decent performance as well as relatively low noise?

 

https://www.pine64.org/?product=usb-adapter-for-emmc-module

https://www.pine64.org/?product=64gb-emmc

http://www.foresee.cc/en/Business/index.asp?itemid=93

 

Yes, Larry is currently using the eMMC drive in his dirty NUC for Roon storage and he indicated to me that he is pleased with this solution, however, eMMCs are generally not an option with the higher powered (non-Celeron) NUCs.  eMMCs are by definition "embedded" and so I am not aware of a USB eMMC drive.

[Dev]

On the RoonBridge vs RoonReady and .NET, see the reply from Brian.

 

"As for the concerns about .NET…the RAAT endpoint running inside of Roon Bridge is not running in .NET–it is the same C code used on Roon Ready devices. Actually, we are very careful to prevent the .NET runtime from ever binding to any threads related to RAAT because otherwise the .NET garbage collector can pause those threads and cause audio performance issues."

 

https://community.roonlabs.com/t/roonready-vs-roonbridge-on-linux/52150/8?u=debjit_ghosh

[romaz]

6 minutes ago, austinpop said:

 

If, as we suspect, the audio benefit comes from reducing latency, then it would seem beneficial to load the Roon DB into RAM as well, as part of the ramroot configuration.

 

I did a quick check on my W10 Roon Core, to see how big the Roon DB really is. My Roon library has ~1500 albums for a total of ~14000 tracks. I estimated DB size by looking at the size of the following directory: %localappdata%\Roon\Database, and it is 1.27GB. Indeed the whole %localappdata%\Roon directory is 1.75GB.

 

Assuming a machine with a generous amount of RAM (16GB?), is there any reason why it wouldn't make sense to just load this into RAM at boot? Obviously, it does take discipline to make non-volatile changes, like booting in non-ramroot mode before making any changes.

 

Larry and I discussed this and it is possible to do it, however, we both question whether the Roon database (and it's access) has any impact on SQ.  As far as we know, the database is there for administrative reasons.  The challenge of placing it in RAM and going completely diskless with the RoonServer is that you won't have knowledge of available Roon updates unless you reboot the machine and given the stability of this setup, I may never have a reason to reboot the machine.  Furthermore, a 64GB Optane drive only costs about $50 and you'd never have to worry about data loss in the event of a power outage.  

 

With that said, if it turns out the Optane drive results in SQ detriment, perhaps it would be worth doing.

[Dev]

12 minutes ago, austinpop said:

 

If, as we suspect, the audio benefit comes from reducing latency, then it would seem beneficial to load the Roon DB into RAM as well, as part of the ramroot configuration.

 

I did a quick check on my W10 Roon Core, to see how big the Roon DB really is. My Roon library has ~1500 albums for a total of ~14000 tracks. I estimated DB size by looking at the size of the following directory: %localappdata%\Roon\Database, and it is 1.27GB. Indeed the whole %localappdata%\Roon directory is 1.75GB.

 

Assuming a machine with a generous amount of RAM (16GB?), is there any reason why it wouldn't make sense to just load this into RAM at boot? Obviously, it does take discipline to make non-volatile changes, like booting in non-ramroot mode before making any changes.

 

I run the Roonserver on a separate i7 server with 16Gb in Audiolinux ramroot mode as well. I have a systemd timers configured that syncs the ram filesystem to the USB root every 3 hrs. If I need to reboot the server, I would manually sync it.

[romaz]

7 minutes ago, Dev said:

On the RoonBridge vs RoonReady and .NET, see the reply from Brian.

 

"As for the concerns about .NET…the RAAT endpoint running inside of Roon Bridge is not running in .NET–it is the same C code used on Roon Ready devices. Actually, we are very careful to prevent the .NET runtime from ever binding to any threads related to RAAT because otherwise the .NET garbage collector can pause those threads and cause audio performance issues."

 

https://community.roonlabs.com/t/roonready-vs-roonbridge-on-linux/52150/8?u=debjit_ghosh

 

Very helpful, thanks Dev.

[lmitche]

24 minutes ago, agillis said:

 

That for sure. Building a Linux Distro is a huge amount of work! Nice job Larry.

 

I see that AudioLinux charges for support. That's a great business model.

For the record, Piero Olmeida is the author of Audiolinux as he built the Audiolinux Distro. I had nothing to do with this. And yes, he has done a great job. His support is terrific as is the SQ of his low latency OS.

 

All  I have done is to configure Audiolinux for various hardware platforms including the NUC.  Many thanks to Roy for the NUC recommendation.

[rickca]

11 hours ago, vortecjr said:

You might want to get away from RoonBridge. Unfortunately, it requires Windows .NET in order to work on Linux.

So this turned out to be wrong. See https://www.computeraudiophile.com/forums/topic/30376-a-novel-way-to-massively-improve-the-sq-of-computer-audio-streaming/?do=findComment&comment=890999

 

[rickca]

I'm surprised that Roon Server can run completely diskless.  Usually a database needs to do some I/O operations to maintain integrity (checkpoints, logging, etc) but I guess if you aren't adding any music or updating metadata then it doesn't have any transactions to commit.  

 

Doesn't Roon Server ever try to do some automatic maintenance?

[lmitche]

20 minutes ago, rickca said:

So this turned out to be wrong. See https://www.computeraudiophile.com/forums/topic/30376-a-novel-way-to-massively-improve-the-sq-of-computer-audio-streaming/?do=findComment&comment=890999

 

Jesus R and his collegue AGillis came here to throw shade on the NUC solution, which as Johnseye observes is seen as competition.

 

Thanks to Dev for finding the facts and sharing them here. Well done!

 

I tried to buy a NUC7CJYH today. They are sold out in all outlets nationwide in the US. Could this thread be the reason?

 

Larry

[LTG2010]

6 minutes ago, rickca said:

I'm surprised that Roon Server can run completely diskless.  Usually a database needs to do some I/O operations to maintain integrity (checkpoints, logging, etc) but I guess if you aren't adding any music or updating metadata then it doesn't have any transactions to commit.  

 

Doesn't Roon Server ever try to do some automatic maintenance?

When running from RAM, Roon can update etc, but its all saved to RAM. If you have your USB stick installed there is a ramsave command which will save the changes to your USB drive. Regarding databases when using ramboot I just load a few files in Roons storage options, I don't mind not having the full database the sound quality is worth it. Audiolinux/ Roon needs to be configured to save the database to non volatile storage and not be part of the boot files.

Roon is not entirely necessary, you can use HQplayer desktop on a high powered pc and HQplayer's network audio adapter on your NAA/ NUC in RAM alternatively HQ Player embeded controled remotely. Jriver also sounds fantastic. There are many possibilities.

Also great work Larry.

[rickca]

Just now, lmitche said:

I tried to buy a NUC7CJYH today. They are sold out in all outlets nationwide in the US. Could this thread be the reason?

It's possible it's being discontinued, although B&H says more stock is expected in 2-4 weeks.  I think NUC8 is currently limited to just i3/i5/i7 models so it isn't clear what would be the successor of NUC7CJYH.

[sig8]

1 hour ago, austinpop said:

 

If, as we suspect, the audio benefit comes from reducing latency, then it would seem beneficial to load the Roon DB into RAM as well, as part of the ramroot configuration.

 

I did a quick check on my W10 Roon Core, to see how big the Roon DB really is. My Roon library has ~1500 albums for a total of ~14000 tracks. I estimated DB size by looking at the size of the following directory: %localappdata%\Roon\Database, and it is 1.27GB. Indeed the whole %localappdata%\Roon directory is 1.75GB.

 

Assuming a machine with a generous amount of RAM (16GB?), is there any reason why it wouldn't make sense to just load this into RAM at boot? Obviously, it does take discipline to make non-volatile changes, like booting in non-ramroot mode before making any changes.

Rajiv: It might be little bit of apples and oranges, but FWIW; I am  running a 46,000+ tracks worth of Jriver DB on 8GB of RAM in RamBoot mode, I thought you needed 16GB min., as Piero recommends, but I looked at the size of root files and they were under 6GB, so 8GB worked.

[Dev]

18 minutes ago, rickca said:

I'm surprised that Roon Server can run completely diskless.  Usually a database needs to do some I/O operations to maintain integrity (checkpoints, logging, etc) but I guess if you aren't adding any music or updating metadata then it doesn't have any transactions to commit.  

 

Doesn't Roon Server ever try to do some automatic maintenance?

 

Everything is saved to the current root which resides in the ram.

 

This is what I do on the server to make them persistent across reboots

 

[Dev]

12 minutes ago, lmitche said:

Jesus R and his collegue AGillis came here to throw shade on the NUC solution, which as Johnseye observes is seen as competition.

 

Thanks to Dev for finding the facts and sharing them here. Well done!

 

I tried to buy a NUC7CJYH today. They are sold out in all outlets nationwide in the US. Could this thread be the reason?

 

Larry

 

You are welcome Larry. Thanks for all your NUC efforts Its been worthwhile, at least in my system. I knew something was wrong when they bought the .NET twist in the middle and so I had to hear the truth from the horse's mouth :-)

[austinpop]

1 hour ago, romaz said:

 

Larry and I discussed this and it is possible to do it, however, we both question whether the Roon database (and it's access) has any impact on SQ.  As far as we know, the database is there for administrative reasons.  The challenge of placing it in RAM and going completely diskless with the RoonServer is that you won't have knowledge of available Roon updates unless you reboot the machine and given the stability of this setup, I may never have a reason to reboot the machine.  Furthermore, a 64GB Optane drive only costs about $50 and you'd never have to worry about data loss in the event of a power outage.  

 

With that said, if it turns out the Optane drive results in SQ detriment, perhaps it would be worth doing.

 

Roy, Larry, et al,

 

Understood - this is still being explored. 

 

The only reason I brought this up was that I thought Roy's OMG moment...

13 hours ago, romaz said:

it was one of those OMG moments!

 

...happened with Roon DB in memory, so I was concerned that you/we would have to give some of that SQ back to maintain proper Roon operation. However, what it sounds like is that you had the OMG with the Roon DB on nonvolatile storage - the USB stick. 

 

What this means is that if there is a more creative option, there may be further SQ to be gained. I like @Dev's idea of running ramsave on a timer. Kind of like a syncd, except not every 30 seconds! But this still puts responsibility on the (super)user to ramsave before a reboot. And of course, you're always vulnerable to a data loss due to a crash.

 

When I talked to Adrian at RMAF, it sounded like he had given this problem some thought, and felt he had a good solution.