To start with the ‘bad’ news: the reason your DAC is not supporting native DSD is because it does not provide a so-called altset. Which is rather strange, as indeed your DAC is equipped with the Amanero chipset that does actually do this.
The only thing I can imagine is that your DAC is not equipped with the latest firmware from Amanero; their earlier firmware was indeed not capable of doing native DSD on Linux. So it might be good to contact them.
I’ve updated the image on the website. Most important issue is that I changed the way that RoonBridge is being installed to satisfy the requirements from Roon. This means that RoonBridge is being installed during first boot stage. In between I managed to trim of some baby fat of the image
I was just thinking, what if Ropieee could also serve as a central place to manage Roon extensions?
At the moment extension installation requires quite a bit of tinkering, making it not suitable for every Roon user. If the web interface of your Ropieee system provides an easy way to install extensions it can be of great value to fill the gap till Roon has an easy way to do it.
Roon extensions require node.js, it should be possible to run this on a RPi. ARM binaries are available here.
What do you think? A good opportunity for a community project?
The web interface of RoPieee is already node.js, so from a tech perspective that should work.
I’m not sure that I understand you correctly though. I have to admit I did not look that much in the extensions. So… why does these extensions require tinkering?
And yeah, I’ve created RoPieee to make it a community effort. I’ve been preparing stuff on github, so that’s gonna happen soon.
Although the sun is shining over here, I’ve created another update with some small changes:
native DSD support for the Amanero Combo384 USB interface
show the kernel version in the web interface
For the tech kids: the kernel has been updated to 4.9.25.
As usual these changes are being pulled in automatically somewhere the coming 24 hours. The image on the website has been updated and reflects these changes as well. And on top of that I’ve shaved a few bytes off.
Have been reading through the thread you pointed out. Clear indeed now. Running a Roon Extension is not that trivial.
Adding this to RoPieee is rather simple I guess. What would be nice if we can come up with a kind of convention on how to provide them (on github). RoPieee would then have a ‘register’ of ‘certified’ Roon extensions. With a simple click on the RoPieee interface you can install it then.
Just thinking out loud, with a glass of good Macallan. So maybe this doesn’t make that much sense
Whilst enyoying my glass of Westmalle triple, i wondered if building extensions into RoPieee does make sense.
Extension should run on the server/core, not on the endpoint, right?
Crossed my mind as well. But the RoPieee is meant for people that want a simple Raspberry Pi based endpoint, without the need to being a system administrator.
If you looking from it as “the RoPieee is a Roon capable appliance” then the idea of providing plugins in a very easy way could be interesting.
The server would be the best option but since there is no community project for this I think that RoPieee is the best alternative at the moment. And as Rene said extensions can run on both, you just have to make sure that your endpoint is active.
Tha depends on the extension. If you’d like to use an extension that requires access to a certain hardware (that could be a connected USB PowerMate or a serial connection to a Hifi component), it won’t work to have that extension running on the core. The only solution to this would be, if every Roon (Server/Bridge/remoteI) instance has it’s own nodejs runtime…