This thread has run its course. Perhaps the prudent thing is just to let it, but I feel a summary might be useful, since a number of points were raised, and relevant posts were made in 2 different threads. The moderator nobly attempted to merge, but the flow is now confused, and my original summary is now in the middle of the thread. Here’s a coherent (ok, you be the judge)… summary:
I’m pretty new to roon, but I’m pretty experienced with many digital music management/playback systems. My initial look at roon, as already described, was on a simple intel laptop, which as it turns out did not meet clearly stated roon minimum system requirements due to its lack of a SSD. I did not expect this system to perform well. Part of this thread focuses on the shortfalls of this system, and fixing these shortfalls by migrating to a much more capable system. This misses the point. If roon had simply performed poorly on this system, I would not have posted. My point was the way roon failed: by completing database population and allowing connection and control, but then failing during playback.
The fact that the system had glitches is somewhat moot, given that it was under-resourced by roon standards. The fact that it failed during a mission critical operation (playback), which itself should require minimal resources, was the point. As a experience system architect, I know this can be improved using known techniques. I had hoped that highlighting this would be helpful. From the comments a number of forum members understood this. My observation is that roon had not isolated playback from other systems issues, could do so, and this would provide many benefits for both current satisfaction, future growth, and ability to use systems with less resources. Here are the key takeaways as I see them:
@henry stated that 80% of playback problems are user issues that are easily diagnosed and fixable by a knowledgeable person. I completely agree. But that leaves playback problems that may point to areas of improvement for the system.
@Bob_Lindstrom reported that he resolved playback issues by increasing his system RAM. I suspect there are more cases where people had issues and resolved them by using more capable hardware. System architects have long had a name for this: throwing hardware at the problem. you can mask many architecture issues by simply over-resourcing the system. Sometimes its even the right answer. However, as your system features grow, or user collections grow, this may come back to bite you.
somewhere in the now-somewhat confused thread merger it was pointed out that problems with playback have affected only a small percentage of users. I have no way of evaluating this. This does not mean that insulating playback from background system activities is not beneficial.
finally, since obviously I know little about roon architecture and software, how do I know playback is not well sandboxed currently? Well, it only takes a couple of test cases. I feel I inadvertently performed one. My windows system repeatedly (several times in a listening session) would stop playback, usually about 10-20 seconds into a track. sometime it would recover, most often I would hit play and it would resume (from the proper location), and occasionally the problem was likely more serious since my controller lost connection to the core (@danny suggested the core crashed in this case) and I had to restart the track after reconnection. I was playing a mixture of flac 16/44 flac 24/96, and DSD 64 and the problem occurred for all of these. To the @henry point that most problems are user configuration,
a. I was doing no DSP (verified by roon), and no WAN streaming
b. my fileserver had been used on multiple systems pre-roon and I had hardly heard a dropout in 2 years. The cat 6 switched 100/1000 ethernet delivering the bits has been solid for years. The ROPIeee bridge could be questioned, but this seems very unlikely.
c. The roon system was not being used for other applications at the time of playback.
put the above together with what is required for glitch free playback in this case: the core’s only job (e.g. for 16/44 flac) is to deliver, in “near real-time”, a bit stream of a few hundred kbits/sec across a switched ethernet to the bridge. a raspberry pi model 1 could do this. I was doing this in 1980 on corporate networks. Many of the tens of playback systems I have used over the years did this (although they mostly failed in database performance, unrelated to playback, and become unusable)
I apologize for the lengthy message belaboring the point. Roon is a magnificent achievement. On the right hardware (NUCi7model10, the highest performing server listed in the knowledge base recommendations) it has handled my 17,000 album database with ease, provides snappy control, and, using direct USB to my benchmark DAC, gives me the clearest DSD playback I have achieved to date. Sandboxing playback (or at least providing more guaranteed resources if the system is busy) has many benefits. Its not trivial, but the techniques to isolate critical functions are well known. @danny says roon already does this. then why did my playback fail? clearly, in this case an under-resourced core failed to transfer bits. pity.