ASR Open Source Streamer Project

[phofman]

Lots of managers, one (?) developer. I am afraid that is not how open source projects work.


BTW https://github.com/project-owner/PeppyMeter.doc/wiki
https://www.diyaudio.com/forums/pc-based/291010-peppymeter.html

https://github.com/project-owner/Peppy.doc/wiki
https://www.diyaudio.com/forums/pc-based/288412-peppy-player.html

 

[notabenem]

You just invalidated the VU meter one at least, which is listed under “don’t”.

When we said we don't do a VU meter, we decided so in the context of a stand-alone DAC, which is (mostly) planned to be a separate box, connected through USB.
VU meter/spectrum analyzer on the streamer-box (even without any DAC), is a different thing. The use case is already described in my previous post.

CamillaDSP exposes peak and rms levels for input and output channels on a network socket. Moode already supports at least the Pi 7" touchscreen for the interface, which is the web interface running inside a local browser. Is the meter expected to be part of the main page, or something you would navigate to if you wanted to check things?

Not sure if an implementation that relies on a browser and web-server is going to give us the necessary latency, but if it does, I guess we'll be all fine with it. I have, however, thought about it on a more direct route: read from Camilla's socket -> update the (local/dedicated) display. Anyway. We also need to keep in mind something like a 'pure direct' mode, where all sound-processing would be turned off, yet we'd want the display work. Achievable using an identity filter, but that is already a processing.

 

[phofman]

I do not know what the goal of this project is (whether commercial product is aimed at, or a shared-community one). If the latter is the case, perhaps the community approach towards software development may be considered.

The community does not need another "audiophile" distro, there are already many to choose from. Long-term maintenance is a huge ungrateful chore. If some "free" skills are available here, they may be used effectively by helping one of the existing distributions. E.g. addressing Moode authors with offer of gradual cleaning their scripts to make moode not dependent on RPi only. That would give Moode a huge kick to other platforms.

Moode already has a project for TFT vu-meter/analyzer http://moodeaudio.org/forum/showthread.php?tid=3484 https://github.com/FdeAlexa/PeppyMeter_and_moOde#readme , IMO no need to develop a new one. The Peppy author has spent lots of effort on this already, many bugs fixed (including bugs in the alsa meter plugin designed by alsa devels for this purpose). I doubt anyone will do it better from the ground up.

Just my opinion from aside.

 

[notabenem]

Well, first of, finding the things “agreed upon” (who actually agreed, was it validated that these are indeed the most relevant points?) in some random post is not very helpful. Updating the first post with the most current Information would be very helpful. Possibly Amir could somehow make you the topic starter so you can edit the post?

Agreed. Right now it takes ages to figure out what this project is about, what's its status, and how can anyone contribute. Good news is I do have (finally) a clear idea what this is about and will try to formulate (below). We also need to figure a more efficient and structured way how to use these forums as a collaboration and pm tool. Not that much of a fan of altering history (updating first post), but I agree the first post is the 'banner' of the project.

I also still think it’s a major flaw not to define a budget.

Agreed, partly. We don't know the budget for some of the HW pieces. Those, however, should be optional in terms of 'a streamer'. Not everybody needs multichannel DAC, or wants to buy a new one. Which takes me to the project objectives:

• Deliverable 1 - SW: A Complete image that one can deploy to his RPi and start listening to music (incl. Tidal/AirPlay/UPnP/RoonBridge/etc. as described in the first post) without any tinkering with SSH and terminal. Good for ppl already having a RPi and some audio-dac/amp combo. Most people do. Low entry barrier. Defining a budget is not really needed.
• Deliverable 2 - HW: A case +adapter tailored for streaming purposes holding a RPi using the image from #1, with a display showing VU meter/spectrum. This is PLUG-WIRE-AND-PLAY. A budget target is definitely needed, but I don't expect some huge surprises here. In any case it's easy to tune the budget here.
• Deliverable 3 - Premium All-In-Box: #2 from above, but including a HQ DAC and possibly also an integrated AMP for stereo listening. This should be pure 'plug and play' with the exception of the speakers (or sell bundled with Directiva). Budget and marketing is critical and should be defined.

Good thing is these tasks are mostly independent or we have a reasonable fallback (e.g. use MoodeOS until our image is finished), so nothing's on the critical paths. @Skeptischism is already working on one part for deliverable #3, more is needed. But most importantly we need #1 and #2 put on track and for that more volunteers are needed. Once we have them, we can go into the details of those assignments or 'work packages' ( in PM jargon)

 

[notabenem]

If some "free" skills are available here, they may be used effectively by helping one of the existing distributions. E.g. addressing Moode authors with offer of gradual cleaning their scripts to make moode not dependent on RPi only. That would give Moode a huge kick to other platforms.

It would give a kick, definitely. I'd like to see that as a user, but not so sure as the maintainer: increased support requirements and complications, lots of devices with possibly half-baked implementations, kernels, etc. The RPi is a well controlled and reliable ecosystem with only a few variations.

 

[Rick Sykora]

If not already obvious, am pleased to announce that @notabenem has accepted the role as streamer project lead. I thoroughly appreciate what he has done to date and the magnitude of effort it will take to complete. As mentioned, we need a few more volunteers, so please consider helping if you can!

In this regard, I took an action item to set some price targets on what we are aiming to deliver. As a volunteer effort, am not including labor. We are still discussing with Amir, but here is the current thinking:

1. Software is pure labor, so no charge. From what I have seen, the major functionality is readily available, so is more of a administrative task with some dev support.
2. Our thinking is that the basic streamer be around $100. If designing it to be more extensible adds some cost, we consider this to be a worthwhile consideration. Not sure what we think the dollar value is just yet, so still working on it.
3. We will punt on the more premium streamer for now. There are too many variables that need better definition and want to focus on getting the basic one done first. Am hoping that the fine effort to date by @Skeptischism and others can be adopted, but have some unresolved questions over expandability and cost. In any case, am personally very interested in what has been done to date. At the very least, may just be we start a ASR multi-channel DAC project.

Please note my use of the word price vs cost. Notably, my price target is based on value. The cost is another matter, but suffice to say, the goal is not exceed the price target (and hopefully be less!). It is meant to help bound the design and allow some comparison to those considering alternative offerings. Until we are further along with knowing more design specifics and manufacturing costs, it is just educated estimate.

Thanks,

Rick

 

[mdsimon2]

Not to be too negative but if the multichannel aspect is eliminated from scope what does the ASR streamer provide that is not already available from DIY and commercial products? A VU meter?

@Skeptischism if you continue with the 9028pro 8 channel DAC outside of this project I for one am definitely still interested, especially if price is sub-$1K.

Michael

 

[notabenem]

Not to be too negative but if the multichannel aspect is eliminated from scope what does the ASR streamer provide that is not already available from DIY and commercial products? A VU meter?

@Skeptischism if you continue with the 9028pro 8 channel DAC outside of this project I for one am definitely still interested, especially if price is sub-$1K.

Michael

Where did you read something like that?

 

[mdsimon2]

We will punt on the more premium streamer for now. There are too many variables that need better definition and want to focus on getting the basic one done first. Am hoping that the fine effort to date by @Skeptischism and others can be adopted, but have some unresolved questions over expandability and cost. In any case, am personally very interested in what has been done to date. At the very least, may just be we start a ASR multi-channel DAC project.

Maybe I misinterpreted this statement?

Michael

 

[Rick Sykora]

Maybe I misinterpreted this statement?

Michael

Yes, but here are some of the specifics. For example, current Directiva needs 4 channels, but future one could use more and then there is question over subwoofer support. More channels adds costs all along the way - more circuits, connectors and bigger case. This is just one example, As stated, this and other premium features are still being determined and then will see about staffing, etc.

I know @Skepticism is busy and we still need a huddle with Amir on design scalability and manufacturing alternatives, but as stated, am still looking forward to one or many solutions.

 

[drfous]

Too many cooks in the kitchen.

 

[phofman]

It would give a kick, definitely. I'd like to see that as a user, but not so sure as the maintainer: increased support requirements and complications, lots of devices with possibly half-baked implementations, kernels, etc. The RPi is a well controlled and reliable ecosystem with only a few variations.

The point is not in making the current moode authors maintain multiple platforms, but in modifying moode to support configurations for multiple platforms.

Moode github repos show the project has two parts. The moode builder https://github.com/moode-player/mosbuild, and the actual Moode layer over raspbian https://github.com/moode-player/moode . Raspbian is (currently) 32bit debian 10 with rpi kernel (patched mainline kernel). Moode may contain some closed-source arm32 binaries but the authors would certainly know. All other binaries can be recompiled for aarch64 plus moode itself will likely convert to aarch64 anyway as the 64bit raspbian is already being tested and works very good (at least on my rpi4).

RPi is not any special arm board, the rpi kernel just contains a few extra drivers for RPi-specific DAC boards, provided by their vendors. These drivers are listed in moode/build but that could be part of the customization for RPi. On the other hand, new multichannel DAC boards would be in the other platform customizations.

Most RPi-specific issues are not tied to the HW platform itself, but to the specific version of raspbian. https://github.com/moode-player/mosbuild/blob/master/mosbuild.properties https://github.com/moode-player/mosbuild/blob/master/mosbuild_worker.sh . IMO in many cases the scripts do not need to read exact package versions, in other cases the version can be moved to a platform-specific mosbuild-XXX.properties file. E.g. mosbuild-common.properties (with most values as armbian and raspbian based on the same debian version will contain mostly same packages) + mosbuild-rpi.properties maintained by the current authors and mosbuild-XXX.properties maintained by maintainers responsible for the respective ports. No rocket science, it's just a few bash scripts.

Once the mosbuild script modifies the stock debian installation, the actual moode will run identically on any arm device.

IMO such a project would be quite useful for the community, if Moode authors agreed to this direction. Maintaining the platform customizations may not be so laborious, once hooks to the common underlaying project were implemented. On the other hand forking moode as is will not work without huge maintenance effort. Every merge from the upstream moode branch upgraded for new raspbian will likely cause lots of git conflicts.

I cannot imagine any skilled developer would volunteer to the dull effort of maintaining the fork and voluntarily submit himself to directions of the "steering committee" here. But I may be wrong, yet have not seen anyone like that here or elsewhere. Unless some money is on the table which goes back to my initial question of the project's purpose.

 

[notabenem]

@phofman I like and agree with most (if not all) what you wrote above.

I cannot imagine any skilled developer would volunteer to the dull effort of maintaining the fork

I don't think anyone favors a fork - exactly for the reasons you outlined. If any of my previous formulations or posts suggested otherwise, then I'd like to make it clear here: As long as upstream maintainers are OK with enhancements, I am strongly in favor of enhancements.

 

[phofman]

Well, there is also the second part of my sentence - "and voluntarily submit himself to directions of the "steering committee" here."

 

[notabenem]

The point is not in making the current moode authors maintain multiple platforms, but in modifying moode to support configurations for multiple platforms.

At the end of the day, it will be a Moode image. Ppl will figure that for any issue on any of their cheap(?) clone board running a 64bit arm debian having random cpu/wifi/bt/sbc/dac/etc inside, they will create an issue on Moode, just to realize that the board they're using it is untested/unsupported/etc. That is the predominant risk that upstream vendors may want to consider before accepting PRs for multiple boards. Lets address this once we have someone to do at least part of the work.

Well, there is also the second part of my sentence - "and voluntarily submit himself to directions of the "steering committee" here."

I see a bargaining position opened up here. Name your conditions!

But regardless, this probably also deserves some clarification. If by 'steering committee' you refer to @amirm and @Rick Sykora, then I don't think anyone needs to be afraid. My impression is that they are not draconian leaders, albeit I may be wrong - I am quite a newbie around here . They do have some desires (see post #514), and they are open how the community solves them. Time will show if there are volunteers sharing those objectives (and feeling to act) or not.

 

[voodooless]

Deliverable 1 - SW: A Complete image that one can deploy to his RPi and start listening to music (incl. Tidal/AirPlay/UPnP/RoonBridge/etc. as described in the first post) without any tinkering with SSH and terminal. Good for ppl already having a RPi and some audio-dac/amp combo. Most people do. Low entry barrier. Defining a budget is not really needed.

So what exactly needs to be done here? What things are lacking in the current Moode for this deliverable? I'm guessing it's only Roon Bridge? I think that should be challenge nr 1 then since the Moode owners are not willing to put the Roon Bridge in directly. What might be possible though, is to extend Moode with some installer script that automatically installs it with a press of a button? If that does not work out, a fork is just about unavoidable. Or another option would be to develop a plugin-system, which Moode owners have no interest in themselves. That would enable the installation of 3rd party components on top of a standard Moode without modifying the base.

I also think the Moode web interface might need some serious upgrade at some point, both in UX as well as in the technology stack. HifiBerry has done a much better job there and I think there is a lot to learn from them, especially on how to integrate the DSP options.

 

[somebodyelse]

My reading of that plugin thread is that they're not actively against a plugin system and may accept a pull request if someone else were to develop one, but anyone working on one should probably discuss it before diving in too deep. It certainly has the potential to make life a lot easier for people who aren't happy using ssh and following the instructions from the FAQ and Guides section of the forum. If done well it should make the changes more resilient to core system upgrades too. It's one of those thankless bits of core design that goes completely unnoticed if done well, and attracts all sorts of criticism if it isn't. I'd imagine they'll be wanting a commitment to maintenance not just a code drop.

The next two have active guide threads, so probably a case of working with the respective authors to try to get them into a release version, much as the CamillaDSP part has gone from a guide to release inclusion.

The roon bridge install guide is pretty simple. What needs adding to meet the requirement here is a button in the config gui to download and run the installer script instead of having to use ssh, and possibly a button to remove it cleanly if it's installed. I wouldn't expect it to be a controversial pull request but I may be wrong.

For the VU @phofman has already pointed to PeppyMeter which looks like it should meet the functional requirements. It's rather more involved than the roon one. It probably wants a config gui adding for enabling/disabling, meter selection etc. and may need some tuning options if there are significant tradeoffs to be made (cpu available to DSP vs. display updates and latency perhaps?) The i2c option for driving LED bars is an option for those wanting metering without a screen. I don't think it can use secondary i2c LCDs or OLEDs but it could probably be extended to cover them.

I'm not volunteering - no Roon here, and happily using piCorePlayer without a display. Pulling DSP presets from AutoEQ or a similar repository for speaker EQ settings might be more tempting.

 

[notabenem]

So what exactly needs to be done here? What things are lacking in the current Moode for this deliverable? I'm guessing it's only Roon Bridge? I think that should be challenge nr 1 then since the Moode owners are not willing to put the Roon Bridge in directly.

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

 

[voodooless]

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

From what I can see, that makes it even harder:

not to provide, or otherwise make available, the Roon Software in any form, in whole or in part (including, but not limited to, program listings, object and source program listings, object code and source code) to any person without our prior written consent;

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

 

[notabenem]

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.