ASR Open Source Streamer Project

[voodooless]

Not necessarily. Roopie does it as a post-install script: builds a FlatPack out of the binary that is downloaded on-the-fly and then installs it.

It’s even questionable if that admissible according to the terms and conditions without consent. It seems to do exactly that what I quoted above.

 

[somebodyelse]

It's not about Moode owners, but RoonBridge licensing conditions (chapter 2.1 to be precise). Also see https://github.com/moode-player/mosbuild/issues/8

Is that the correct license? It says it requires Windows or MacOS etc. which matches the server requirements but not the roon-bridge requirements.

Then this would mean that step 1 is to ask Roon for permission.

Not necessarily. Roopie does it as a post-install script: builds a FlatPack out of the binary that is downloaded on-the-fly and then installs it.

Roon are clearly aware of Ropieee since they created a section in their forum for it, so apparently not against that type of use in principle. Ropieee may have asked though, and it wouldn't hurt to check.

 

[voodooless]

Roon are clearly aware of Ropieee since they created a section in their forum for it, so apparently not against that type of use in principle. Ropieee may have asked though, and it wouldn't hurt to check.

Ropieee is mostly a single feature thing, delivering Roon Bridge. I can imagine that Roon does not mind. In contrast, the other streamer OS'es deliver similar functionality. I think that matters quite a bit.

 

[Skeptischism]

I'm still around guys, no time to reply properly right now . 2 jobs and a commute is frying my brain a bit. with low availability of parts at the moment, at least right now, at the last minute I decided to socket the IV stage blocks as separate PCBs, so I can try 2-3 options and only build up 2 dacs, mostly options around DC biasing and optionally DC coupling.

 

[Skeptischism]

will update at the weekend

 

[notabenem]

Hi guys, short status:

• thanks to the wider community and especially @phofman we have the SW stack identified
• @Skeptischism is actively working on the DAC
• we have no one on the roster who offered to do the overall system image, regardless of the distribution
• we have also identified some legal challenges

Some valid points have been raised regarding to the nature of the possible contribution, however. If anyone has any ideas how to attract and motivate people to join and start working on the packaged SW distribution, please fire away.

 

[notabenem]

Given the complications with Roon, how about changing the SW objective to something as simple as "Enhance Moode by integrating PeppyMeter into the resulting image"? Can it be done so that it's not a resource hog for all the people that are already using Moode and have no displays?

 

[voodooless]

Here is some info already: http://moodeaudio.org/forum/showthread.php?tid=3484 and https://github.com/FdeAlexa/PeppyMeter_and_moOde

 

[somebodyelse]

Given the complications with Roon, how about changing the SW objective to something as simple as "Enhance Moode by integrating PeppyMeter into the resulting image"? Can it be done so that it's not a resource hog for all the people that are already using Moode and have no displays?

That sounds like one of the easier things in the task - it needs a config gui to meet the 'no ssh' requirement, so include a toggle to enable it. The bigger question is how it's supposed to integrate - is it supposed to take over the display entirely (no on-display controls), be something you navigate to or toggle with a button, or act as a screensaver? Or a config choice of some subset of those? All should be possible, but some will be easier than others. Then there's the question of whether the Moode devs would consider it for upstream inclusion in Moode at all, and if so what the minimal viable version would look like.

 

[notabenem]

Here is some info already: http://moodeaudio.org/forum/showthread.php?tid=3484 and https://github.com/FdeAlexa/PeppyMeter_and_moOde

Thanks for the hint. Found a complete guide towards the end of that discussion: https://github.com/FdeAlexa/PeppyMeter_and_moOde

... The bigger question is how it's supposed to integrate - is it supposed to take over the display entirely (no on-display controls), be something you navigate to or toggle with a button, or act as a screensaver ...

Up for the actual volunteer to decide. As simple as it gets for starters. Best to get in touch with Moode maintainers before work is started to ensure acceptance.

 

[voodooless]

One other thing that might be considered if we don't want to fork, and still want to add functionality without adding SSH. One could devise a cross-platform desktop app that lets you install new functionalities. The app does all the SSH'ing for you. This way you can keep the stock Moode and still be able to extend functionality easily.

 

[notabenem]

One other thing that might be considered if we don't want to fork, and still want to add functionality without adding SSH. One could devise a cross-platform desktop app that lets you install new functionalities. The app does all the SSH'ing for you. This way you can keep the stock Moode and still be able to extend functionality easily.

Or rather a mobile app... Interesting idea. Basically putting the scripts outside the image - or even better, onto the cloud, downloading it based on the image's version and HW in question.

 

[voodooless]

Or rather a mobile app... Interesting idea. Basically putting the scripts outside the image - or even better, onto the cloud, downloading it based on the image's version and HW in question.

Well, yes, you can make it a cloud hybrid, where you load all scripts from the cloud. But in the end, you'll still need an app on your local network to actually make the SSH connection to make all of the needed changes.

 

[notabenem]

Well, yes, you can make it a cloud hybrid, where you load all scripts from the cloud. But in the end, you'll still need an app on your local network to actually make the SSH connection to make all of the needed changes.

That's exactly what the mobile or desktop app would be for. If built using https://flutter.dev/ it's one and the same.

 

[notabenem]

But it can be done probably easier with a one-liner too:

ssh [asr@streamer's-ip-here] "wget [script-url-here] && chmod +x ./runScript.sh && ./runScript.sh"

That would add the necessary ppa to the repos, update the repos, install packages, do builds (if a binary can't be used),etc.

Edit: this is the post-install script, just not started post-install, but manually. So nothing new.

 

[voodooless]

But it can be done probably easier with a one-liner too:

You're not thinking big enough. For one, one of the prerequisites was to need direct ssh access. Next, you might want more changes made or features added than you have on your scope right now. For instance kernel changes to support certain interfaces or changes needed for @Skeptischism's DAC, or other features on top of Moode that will be developed. All that could be as a nice UI app where you can mix and match functionality to your liking.

 

[Tatteredmidnight]

Building ssh into any 3rd party app is problematic. It will basically mean packaging pre-generated keys into both the distro image and the app, or baking in default credentials. It’s one thing to do this for an admin console scoped to an application, but it’s a bit scarier when you talk about doing for an ssh user who has permissions to modify the system and install software.

 

[voodooless]

Why would there a need to pre-generate keys? You either provide a username/password or authorized key or even be able to use the defaults that the distro already has. You can even have the app set up something for you in this regard.

 

[hochopeper]

Too many cooks in the kitchen.

Very conscious of this.

I'm very new here, so a quick introduction to give some background about why I'm blundering in to the thread . I'm friends with @Skeptischism and we've been talking for a good few years about the idea of an integrated DAC+DSP/playback computer project/product. Which overlaps a lot with this thread, he's been nudging me to get on here but life has been happening to me a lot lately, but I'm seeing the light at the end of the tunnel so I'm keen to get cracking so here I am!

I note and understand a lot of the focus of the thread has been on basing efforts around Moode. Personally I have some hesitation here simply because one person projects like Moode can be fickle.

A concern I have is that if the DSP is built in to this via camillaDSP or similar then I don't want my audio system to be constrained to just audio only media. So an area that I'd like to contribute is building an input board or a mechanism for having some sort of input selection between various input sources.

Personally I've been a long term user of kodi and libreElec and in my previous thinking on this I'd decided that I'd build camillaDSP in to libreElec as a first point on my journey while building some hardware to go with it. I think libreElec may be a more sustainable project to base around and contribute to with its suport for various addons. I've started work this weekend on building camillaDSP in to libreElec for this purpose.

To the extent that this is of interest to others here I'm happy to engage in this thread or start my own ...

In short what I'm looking to contribute at least initially:
- camillaDSP & config UI/WebUI in libreElec
- input hardware/software? (this may just be part of the controller for camillaDSP selecting input devices + hardware solution if there is any gaps in existing products)



Chris

 

[Skeptischism]

Hey mate, so sorry, between work and here I didn't have time to answer you here; although welcoming you by PM. I'm a fairly new member here too, but if course i'm glad youre here.

I'm fairly sure this forum will be accepting of the dual use high performance streamer digital crossover, DSP/media centre. I mean who wouldnt? I dont personally have the luck to have a dedicated music system and room that is separate from my music system and I dont personally see a good reason to separate them (although I understand others may have different priorities) At the very least this project will be a good way for me to answer that question 'Can you load a system with both these tasks transparently at the highest level?' and a secondary question, how much resources do you actually need these days, with 35 x 45mm RPI4 computers that can take on the DSP for just about any reasonable crossover you think to throw at it, without flinching.

Indeed, the MUX/input selection for this system will be very important, if we want to keep a tight handle on the time domain, although I suppose it must be stated that it would not be providing a mixer for the inputs, will it? I mean of course that's not impossible either and you could take on live DSP RACKs for PA application. mostly you would still pass it through a master bus from a hardware Mixer then anyway, (ADAT/PCIe etc) so the DAC would still only see one source at a time. You could just plug a commercial ADC/Mixer into a 'spare' USB if you had one already. depends how we are divvying up the BUS/bandwidth/cycles