Steve, we are committed to the Sonore Sonicorbiter SE long term as an affordable solution. I can’t control availability of some parts, but we will do our best to keep the unit’s available. The follow up product is called the Sonore microRendu and it’s based on the Sonicorbiter operating system. That project is going to be our flagship offering with both software and hardware tweaks. No ETA on that, but we are working very hard on it. Also, it will USB output only and have all the outputs modes the operating system supports available. However, I want to point out that only one output mode is active at anytime to keep the unit sonically pure.
Jesus - thanks for the amended position on the SonicOrbiter SE’s long term availability. Though that’s different than what had been previously been posted online, it’s welcome news. Thank you.
For myself, I’m DYING to be able to purchase the microRendu. But in truth, my own experiences with a Cubox-I based streamer have been so overwhelmingly positive, that I’m sure anyone buying a SonicOrbiter SE now will be delighted with the SQ.
I see this thread is ancient, but hopefully nobody will bite my head off for replying. I managed to get Roon running on an ancient single core Intel NUC. Initial processing will take a long time (at least a week). But playback is fairly responsive, comparing to local use on fast hardware.
I have the same hardware running as a ROCK powered endpoint and it does run ROCK erfectly well. But I don’t use any of its functionality other than the fact my core sees it as a networked endpoint. I have run Roon on a quad core Atom and that can do what is needed better but it is still poor in terms of speed scanning a library and occasional hiccups when multitasking. But overall my i5 is better all round. From speed scanning through snappy response to the comfort of supported hardware it is preferable.
The point of minimum hardware is that our software updates will work fine on minimum hardware, but we make no guarantees of whether a software update will break on your lower-than-spec hardware. We only test on our minimum gear, so if we exceed the spec of some lower hardware, the notice will not be in the release notes, and note that going back to old software is not always possible due to database format changes.
If you are starting from scratch, go for the recommended specs.
If you have gear lying around and are willing to deal with a software update that silently will no longer function on your lower-than-spec hardware, understand the risk.
Agreed, it makes more sense to overshoot a little when buying new things.
Having an updater not work due to lack of CPU cycles strikes me as odd. I suppose if one of your frameworks stop supporting an architecture or start requiring certain CPU extensions it would be understandable.
Having the core and signal pipeline work on a low-power system is a testament to good programming on your end. I was happy the NUC could be used for something productive.
For example, if our search algorithm was improved to reach deeper into the connections in some way to give way better results, but it resulted in an 8 times longer time to do the search. Let’s say a common search took 25ms on the i3 but 500ms on a much slower CPU.
We may be ok w/ these new searches taking 200ms on the i3, but 4000ms would be unacceptably slow. We would never do something that caused this type of result on our minimum hardware.
