Hi, Roon is doing great, there are two features I would liked to add.
For Rock, the 2nd internal SSD becoming a cache that automatically manages to hold frequently used songs while the library is located on NAS or another device e on network. This will much enhance the ease of use. Currently I have a small subset located I. the NUC internal SSD and the large library in NAS. This created 3 issues, a) the manual handling of selecting which subset to be stored in NUC b) duplication of the album in the library, if I inadvertently choose to play the NAS copy, the inherent advantage of speed, lower network bandwidth etc is loss making it moot to put it inside the NUC in the first place. c) All my previously saved playlist become messed up if I disable the NAS on Roon core. The songs would show unavailable instead of substituting the copy on the NUC SSD.
If the roon software can work outside of home network such as on mobile, it will enable much better experience for users. Probably we dont need the RAAT on the.go, but at least we can replay the songs and search the library while on the go. Even just browsing the library when outside of the home network is is nice. As it’s often the case, I wanted to see if I have a song while in a CD store or discussing with friends some of the music collection. It would have been nice to.be able to do so.
#2. They’re working on a Roon to Go for portable use. They’ve been discussing it for around three years. Roon 2.0 per se. Not sure when that gets rolled out, but it would be a game charger for sure
As for your #1, this is not necessary.
The speed of storage is not a factor for the music files, any networked storage is fast enough, reading the music files is not performance demanding. Do you notice a difference? If so, your NAS or your network is broken.
(An SSD is important for the database only.)
And a philosophical note: even if it was important, are you willing to spend your own time to baby the equipment? My computer is there to serve me, I’m not there to serve the computer. I don’t even want the computer to ask me to do an update, I’m not the servant. At minimum, if it needs to know if this is a good time for an update, don’t say “please update the software”, say “I would like to update, is this a good time?” Better yet, you figure it out, your supposed to be so smart.
It does have impact on network traffic which can impact SQ. Especially when the network is not for music only. Also music replay is time sensitive. Decreasing it reduce the chain of uncertainty.
It is exactly what you said, I don’t babysit the computer philosophy that has driven me to request this automatic handling of internal cache features.
In fact if a Roon on the Go is being developed, this same internal cache is a prerequisite as I dont believe it is a good idea for the to go mobile client to connect to roon core for streaming everytime?
Why do you think network traffic has effect on SQ?
If your network is dramatically underpowered, it might not have the capacity to play and then you get hiccups, interruptions. But short of that, it is not SQ critical.
The network traffic is asynchronous, it is not part of the time sensitive chain. The IP protocol does not even guarantee that packets (small buffers) are delivered in the right order, and if a packet is lost or corrupted the system requests that it is retransmitted, and all of this is invisible to the music layers.
No, that’s the wrong conclusion. That is how the network works, it is not a flaw in the network, and therefore every system that uses the network is designed to operate correctly under those circumstances. Including Roon. Roon does not require that the network is time critical, because if it did require that, Roon would never work. If you look at the programming interface for networking, there is nothing in the API that provides time critical stuff.
Why not eliminate it? Because there is nothing in computer systems that is time critical. If you put a hard drive or and SSD inside the computer, the programming interface to that local storage is not time critical or time accurate either. That’s not how computer systems work.
As for the connection to the audio systems, the recommended technologies are networking or USB, precisely because they are asynchronous. The old SPDIF interface, which was designed around 1980, is synchronous which is why it is bad, why it is prone to jitter.
So timing precision is not an issue. There cannot be timing accuracy errors when timing accuracy is not a feature of the system.
Capacity problems can be an issue. But if you have a Gigabit network, do the math: if you play 24/192k, the bandwidth requirement is 2 x 192000 x 24 or 9,216,000 bits per second. I.e. high res uses 1% of the Gigabit network. If you have other traffic that uses 100 X as much capacity, then yeah, networking would be a problem.
Why not eliminate it? Sure, I don’t use my NAS for music playback (just for backup). But not with caching. I put a 2 TB SSD in the Nucleus.
In fact, everyone’s audio system is not time critical.
Of course the processing inside the DAC is time critical. But we are discussing the transport over the wire. And the Core communicates by IP networking or USB, and those are asynchronous. It seems you don’t accept asynchronous. Wikipedia says Asynchronous systems do not depend on strict arrival times of signals or messages for reliable operation.
In fact, regardless of where the data is stored, there is nothing Roon Core can do to affect the timing of the samples getting into the DAC, because IP and audio USB are standardized as asynchronous.
So it is not a question of what is important for me, or whether Roon would prioritize your request. It is not possible to synchronize the signal over IP or USB.
Both of those statements you quoted are correct, but neither imply what you seem to think they imply. The point at which timing matters is in the DAC. Everywhere else it is just a case of best effort to keep the audio pipeline fed.
Think of reading a book, but all the pages were thrown across a room randomly in batches roughly in order of it being read. The only thing you care about is you get the next page in top of the pile on your desk in time for you to start reading it as you the finish the previous page. You really don’t care of they were scattered all over the floor and out of order while in transit, just that they in order in good condition and in time when you need the next page. You are the clock in this case. Your reading informs the speed of delivery and a little stack on your desk serves to deal with variance in the speed of delivery. This is case 1.
Now image two people who have to read their own loose copy of the same book in sync. So long as both get the pages when they need them, someone just has to tell the other when they are turning to page so that the other knows if they are reading ahead or a bit behind and thus to change their reading speed. This is like case 2.
In nether case did the order and timing of moving the pages around, nor the route they took to get to your desk actually matter so long as the constraint of the next page being available on top of the pile when it is needed is met.
Yes, it is the asynchronous nature of the wire protocols that make device synchronization difficult. If it were possible to control wire timing down to the nanosecond, sync would jot be difficult, right?
Again, this is not about what is important to me. It is about what is possible with the technology.
IF they arrive. Again, what is wrong with minimize traffic ?
Keep the file locally cache eliminates the extra traffic which may/may not congest the network right at the time your DAC wants a piece.
Your whole story hasn’t any single point saying why it is wrong to be cached.
If I can put the bookshelf right next to me, why should I have it across the hall so.everytime I need to read I have to walk across. Maybe 95% of time it is.fine but maybe 5% of the time my maid is wiping the floor and blocks my way right at the moment I want the book. I prefer it can be cached.
You don’t need that, you just need to be close enough to by audibly in phase if the zones where driving speakers in the same room at the same distance from the listener (in practice it should ideally be within 10us for ideal sound localization).
Between zones in a home, you don’t need this. If two zones are 5m apart, the speed of sound through air means that is roughly 15ms time delay between them if they were feed with the same analog cable. Roon aims for 1ms, during which sound will only travels about 30cm or so. Arguably even 1ms is way more than good enough for different rooms and is ok even in the same room for a party mode for eg.
I have no objection to most of the thing you say, except the term “you don’t need that”.
Need is a thing that is determined by individual circumstances. A lot of people could just argue you don’t need Roon as there are lots of players with their own app, or you can do it with any other software.
When someone say they need something, they need it…
This does not make a lot of sense from a technical perspective. You are asking Roon to develop and maintain code that is completely unnecessary in virtually all cases. How do we know this? Roon works great now and the feature does not exist. You are trying to solve a problem that does not exist. Trying to solve this “problem” adds complexity and more points of failure to the Roon system.
Hardly. You think you need it but really you just want it.
Having a large cache resides in SSD is not recommended coz it will cause data corruption in event of power failure and system not responding. The cache data will need to be deleted when the next power recycled is done. The best is to cache in memory playback and this has the lowest latency; in event of unexpected failures, power recycled will automatically flush the old cache data from the memory.
Memory playback cache was brought up a few years back in one of the threads here but it was not implemented despite of its advantages
P.S: I know streaming services like Tidal and Qobuz use large cache in Roon streaming but not in the case of NAS (local streaming). May be @danny can comment on this. Thanks
I spend a lot of time away from home, and run Roon Core on a MacBook Pro. I was thinking of getting a NUC or similar for home, but I might just keep it on the Mac, as I can then use it when I’m not at home. Obviously that won’t work for a commute on the train, but for me it’s ideal.
Also, most of the DSP code are not necessary to ME too, I wont say they are unnecessary.
If they can’t implement a Cache, ar least make the playlist smart enough to use the copy in my 2nd SSD instead of streaming over the network if it is present.
