Well, since my focus has been on RPi HAT DAC/DIGI outputs, which need changes in “/boot/config.txt”, that is what has been implemented. See example of the HAT I use on the github wiki (hifiberry clone). This so that even a novice can perform the install without using vim/nano. For USB soundcards/DAC, the configuration differs between them, and is usually done in “alsa.conf”. So, at this point, there are no plans to implement it. This especially since it is fairly easy to do in the Web-GUI as you pointed out already.
If lots of people request it for a specific USB-DAC, I might consider doing it.
Well if what you want is to drive adoption, maybe integrating with a well-documented, simple to get running, and pretty widely regarded as gold standard Raspberry audio distro and giving @spockfish’s request serious consideration is something you’d like to do.
Would you rather have your end users have to go through this, or burn a card and click on a checkbox ?
1 Like
That is basically a “burn a card and click on a checbox” walkthrough! You will never get around application specific configuration, which is the only addition to that walkthrough.
The only way to get what you seem to want is an image based of a custom built distribution closed for the end-user (severely limits what other things you can do on the hardware) and/or limited support for the hardware. A lot of people will be turned off by that approach.
Your tutorial (and scripts) are great, but there’s still “scary” stuff like ssh’ing into the box that you don’t have to deal with when it comes to Ropieee. Then there’s maintenance of said box. Here again, not a big deal, but they are all things that the Ropieee approach make easier. What end-users prefer is, well, up to them, and having more options isn’t going to hurt… Much in the same way that I’d personally rather use Plex than Kodi, I’d indeed rather have the choice of having a single, easily-maintainable device that does Roon, Airplay, Spotify and Plexamp rather than waste time manually setting that up and maintaining it all, or (since my DAC is single USB input) getting an extra device with a HAT just for Plexamp, at the expense of the flexibility to use any HAT on it or under-utilising a Pi.
You can run the RPi Plexamp headless with a USB-DAC, or any DAC you can connect to the RPi, like I said, it is a flexible solution.
The part about under-utilization is exactly my point, with an appliance-like solution, that is exactly what you will get in most cases! With the current solution, one is free to install/run whatever next to the plexamp. I have Hyperion running on mine as an example. A closed image would not allow me to do this.
Me, personally, I use both. My main media-streamer is a Kodi-box built on an Odroid N2+ with CoreELEC. Basically works like an appliance, and I can do 4K HDR and VP9 on Youtube!
Also, all systems needs updates/maintenance, and maybe this is where an improvement could be made, to have an internal update-system once the main build is installed. Guessing it will come at some point, there are hints at it already.
Also, calling ssh scary stuff!? This just tells you the educational system in schools have failed! I was taught telnet/ssh back in the day in school on HP-UX and IRIX-machines. Later when I started working/making money off my college-degree, on Solaris (and these days Linux, mostly RHEL).
1 Like
@mattbr The above quote proves my point. RoPiee is too locked down, ergo not flexible! Resources are wasted on such a solution since nothing else can be run on it!
If you want to lock down images like that, the only solution I see is to containerize the application in docker or other container-format. This way, you can at least run other containers to not have the HW sit idle!
Also, as noted in the installation-guide, the HW-support for DAC etc is limited on RoPieee to supported types! For Plexamp, whatever you can get working on RaspbianOS will work with Plexamp.
1 Like
The developer’s response also illustrates this closed mindset.
There’s no desire to open the platform for use with other applications. I’m not sure why this is being laid at Plex’s feet to be honest. There’s nothing particularly special about it as an app; it only requires a modern ARM or x86-64 platform, Linux, and Node v16.
1 Like
You misread it. The list you see is about native DSD, not about DAC’s in general. All DAC’s that follow the USB UAC(2) standard are supported by RoPieee (as with any other Linux based distro). This list merely states those DAC’s that are capable of doing native DSD (mostly by me patching the Linux kernel).
My point is that it’s not a 0-sum game, i.e, also providing the binaries @spockfish requested doesn’t stop those who, like you, want to roll their own and max out their hardware from doing so.
In fact, an appliance approach is rather coherent with what @elan said right here, don’t you think ?
Wow. Not entirely sure how I deserved such a remark. I just explained the goal of RoPieee: it should not be considered a generic distro (like Raspbian or DietPi), but an appliance. That’s not because I think RoPieee is better than or some sorts. It is a choice to build something that is meant for those (originally Roon) users that want to play around with a Raspberry Pi but don’t have the Linux skills.
The only thing I just asked (I don’t get the rather hostile responds) if it’s possible to provide a mechanism that does not require a specific version of Node.js. That’s it.
But it’s clear that won’t happen. Let’s move on.
Thanks
1 Like
Not necessarily! In my case I would not need to use Plexamp when watching TV, that is what Hyperion is used for, and the opposite is also true, I do not watch TV if I a listening to Plexamp-music.
So, both apps are installed but only one is used at a time, so elans comment is not valid for my use-case. But I do not need to have 2 RPIs in my media room, I can do both tasks with one! So, I have an RPi available for something else to play with!
Sorry, I stand corrected! But it is still a closed “appliance” with no ssh or other access for a tinkerer. If this was my solution, I would need a second RPi in my mediaroom, since there is no hyperion on RoPieee.
Still, a containerized version of both would be preferred, and then use of NodeJS etc would not matter.
That’s the whole point 
That does not make RoPieee a ‘bad solution’ or made by someone with a ‘closed mindset’: it is build for a specific purpose.
If I get questions from people like yourself that want to tinker and want control (which is totally understandable) I explain them that RoPieee is not for them and that they should use something like DietPi or Raspbian, which are great solutions btw.
Thanks
1 Like
Never called your solution bad or said you had a closed mindset, I just pointed out that your solution is limited. Too limited for my taste, this is why I chose Plexamp. If Plexamp is now morphed into a RoPiee-clone, I will have to move elsewhere. That would not be good!
Why not just containerize the solution? That way 3rd party SW like NodeJS does not stop one from deploying, and one can have more than one “app” (container really) on an RPi to not waste resources.
Valid question. And also a serious option for me. But the ‘easiest’ question was to ask the Plex guys to open up Plexamp a little bit for usage outside Raspbian environments. That’s it.
The difference is that now I need to do most of the work
…or maybe ask them to also containerize!
1 Like
Please don’t be so defensive. It was not meant as an attack, just a statement of fact. You stated clearly that your intent is to not open your platform in a manner which would be conducive to the installation of Plexamp. I was merely pointing that out in the face of new comments that suggested that Plex is somehow responsible for the lack of integration.
The fact is that Plexamp’s requirements are fairly minimal. It runs on many modern ARM/ARM64 platforms, plus x84-64. Likely anywhere where your appliance runs. If folks had access to the system on which RoPieee ran via console/SSH, they could likely install it themselves with little effort. The closed nature of the platform precludes that. Plex is being castigated in this thread for somehow being the limiting factor.
I only want folks to understand that there are two possible participants in this collaboration. You’ve created an appliance, Plex an application. If you’d like their application on your appliance, there are ways to allow for that.
1 Like
Not everyone wants to tinker or use a pi as a multi use device. If I do I use dietpi but for audio I use dedicated device like distros that have been built do one job and stream audio, do it well and without hassle that comes with api environment and multiple choice of players. I use Roon as my primary source so Ropieee is the first choice but it gives me several other options such as UPnP, AirPlay , NAA and Squeezebox emulation. Plex would be nice on it to t finish the set.
Don’t get the hostility here at all to having something built for a certain purpose and do it well which Ropieee does, takes the pain out of the pi world. It doesn’t lock down Plex to anything it just allows it on another platform that’s well supported by its developer for its primary purpose play audio. If they don’t want ito play ball that’s up to them, I’ll just use LmS as my reserve again and not bother with PlexAmp I guess. @spockfish is just trying to help his user base and in turn help Plex as it opens it to more users.
4 Likes
I’m not sure I understand how Plex is the blocker here. Plexamp is in no way closed to being installed on any platform which it supports (modern ARM/ARM64 or x86-64). Please tell me what I’m missing.
While I agree with your statement in general, the issue for integration onto RoPiee and other multi-app images lies in the reliance Plexamp has on NodeJS, and usually an old and often obsolete version. This can interfere with the function on other apps that always run on the latest version.
