Sell some hardware

[traverseda]

The place I'm working at just bought some "bose home speaker 300" speakers, which are pretty terrible. I have purchasing authority and could have pushed us towards getting something better, if there was something better on the market.

Snapcast is looking pretty mature, maybe it's time to sell some actual hardware? That's ~$600 dollars worth of speaker we bought that everyone in the cafe agrees are just terrible. Since snapcast supports airplay it would be a more than good enough replacement for our use cases. If you include some basic openwrt-based packages I think it could be a pretty great choice.

The only problem is that it would need bluetooth and 3.5mm audio-in.

Anyway, this is a great piece of software, much better than what's available on the market, and if I could buy some pre-configured hardware that "just worked" I would have by now.

[uSpike]

Check out https://github.com/balenalabs/balena-sound

[traverseda]

I appreciate that, and I'm definitely capable of building my own unit, but I do think there's potentially a big market for someone selling that as a complete product. I might take a crack at it if the people involved in actually writing this software aren't interested, but I think it could be a potential revenue source and I've got a lot on my plate as it is.

If they needed some laser-cut prototype cases or anything like that, I could contribute a few of those for free.

[daanpape]

I'm doing some tests on the DPT-Board (https://www.dptechnics.com/en/products/dpt-board-v1.html) right now and it is working very good. I'm now thinking on creating a design based on the DPT-Module (The linux module on the DPT-Board). I'm currently thinking of using an USB or I2S audio codec and also include:

• Relay to switch on/off an external amp
• Digital potmeter to control the volume knob of the external amp instead of ALSA volume. This would reduce noise and standby power consumption as the amplifier would not always need to be on full volume.

The hardware is in prototype stage now and I'm very open to suggestions.

[traverseda]

Well here are my back of the envelope thoughts on how I'd like to do it, if I had time.

What I'm imagine is less "here's an open source smart speaker" and more "here's a great smart speaker, it happens to be open source". It's tricky to identify the target audience but I think in general it's people who want multi-room wifi audio but don't want to be locked into some weird half-cocked app platform. Being able to do multi-room wifi audio with just a 3.5mm line in would actually be a pretty big feature.

I think balena-sound it a pretty good set of features, but if I was marketing this I'd have a set of features like this:

• Bluetooth input
• Line-in input
• Airplay input
• UPnP
• Unofficial Spotify Connect?
• An app store to extend functionality (actually just a package manger interface)
• {N} 3.5mm output channels to extend your speaker with your own sound system

Personally I'd probably build the firmware images with buildroot, as a consumer product I think having a firmware image makes more sense than running a full linux distro. I'd make the cases out of laser cut wood like this except I'd add a strip of individually addressable RGB leds and some tactile buttons (probably cherry MX blues). The goal would be to compete in a similar space as products like the "Bose smart home" or the Sonos product line, probably with similar price points of $200-$500, but for people who care about being actually able to pipe their own audio into the ecosystem. That's not a big market but I think it's definitely one that exists.

[uSpike]

@traverseda that's pretty awesome, I've had some similar ideas.

I don't think hardware is the difficult part in the short-term. A RPi with an audio HAT covers just about everything for prototyping all functionality.

As far as features, I'd also add:

• Bluetooth output so that you can re-use bluetooth speakers in your house. This would require some tuning of latency for syncing outputs.
• Personally, I don't want a system that relies on the internet. I'm OK using spotify to get some music, but I don't want my speakers to stop working at all if the internet goes down.
• Control other devices such as receivers to turn them on, select the correct input, and adjust volume.

I think the tricky part is software.

There needs to be a "base" server that runs snapserver, and maybe a number of other things.
It needs a configuration manager. If you're getting hardware in a box and want to "plug-and-play", it needs to be easy to setup on WiFi and configure.

• Balena is pretty nice for coordinating configuration and updates, but it's pretty expensive. It'd mean that this product would need to be a subscription service.
• This may be its own project for discovery, configuration, and updating. I've explored options with bluetooth discovery and sending WiFi configuration over that channel. The thought being that it'd be easy to configure via a phone app or otherwise.
• Updates are hard. Buildroot does not naturally lend itself to updating. A device could run docker on top of buildroot and use that for updating, similar to Balena.

As far as a package manager, I think home-assistant and the integrated https://www.home-assistant.io/hassio/ supervisor is pretty close to what is needed for this. Using home-assistant would also allow integration with other devices such as receivers and controll. This would enable automation of a number of other integrations, such as spotify. It'd also provide a front-end for audio control.

I have a home-assistant custom component that I've been working on to tie this stuff together: https://github.com/uSpike/wha-component
And I also have a hassio addon to run snapserver and multiple instances of librespot: https://github.com/uSpike/hassio-addons/tree/master/snapserver

Here's an example of my home-assistant interface (with names of family blanked):

Note that the livingroom "speaker" is a combination RPi and Yamaha receiver.

Anyways, that's enough brain dump for now. I'd be willing to collaborate with anyone interested in such a project.

[traverseda]

Bluetooth output so that you can re-use bluetooth speakers in your house. This would require some tuning of latency for syncing outputs.

That would be a pretty tricky bit of code to write, I think you'd need to include a microphone so that the device can automatically tune latency settings...

Updates are hard. Buildroot does not naturally lend itself to updating.

It would need a custom updater, probably something like what openwrt uses. Honestly I feel like openwrt is the model we'd want to follow as much as possible. Openwrt devices are rock-solid and support installing packages. Configuration by having the device broadcast a wifi network would be good, and after having watched my mother set up a bunch of smart devices I think it's a flow that's good enough for the general population.

Once it's actually connected to the network people still need to be able to discover what actual IP addresses the devices have, that's the only place where I'd have an external service come into play. You can of course look at your router to find the IP addresses, but I'd also have each device ping some kind of endpoint (sending its local IP) when it connects, and when a browser visits that endpoint it can display a list of all the devices on your LAN.

Using home-assistant would also allow integration with other devices such as receivers and controll.

Honestly I feel like running a full home-assistant node would be waaay too much for the average user, way too complicated and requiring actual sys-admin work instead of just setting up an OS image and being able to forget it for a few decades. I'd much rather have something that was a simple peripheral that some other home-assistant node could talk to. Dead-simple router-style firmware that can go decades without needing a real update. I think that in order to be a successful consumer product it's important to limit things as much as possible, to really make a proper embedded device. Ideally updates would happen every few years. Also SD cards have a very limited lifetime and are expensive, so it would likely need some kind of on-board flash, which really limits the amount of space available.

[daanpape]

Thank you for all input already. I would indeed use OpenWRT as I have lot's of experience with it. I also have the platform in place for secure OTA updates on OpenWRT an I now have snapcast 0.20.0 running on it.

I was now mainly thinking of a client unit. But based on your inputs It would be nice to optionally enable the server on it too.

Autodiscovery of all clients and the server could be done throug mDNS. This works fast and reliably.

I do feel that Bluetooth would make things complicated. The latency would need to be manually determined which is very hard.

The hardware that I'm using now consumes 0.3W of power with WiFi enabled so 24/7 operation is not a problem.

After thinking a bit more I actually think it's better to create 3 different hardware platforms:

• A snapcast server device: This should be a more powerful device, maybe based on the Rpi compute module (I don't want to be dependant on SD-cards for the OS). And this should, in my opinion, not have any audio interface. It could be designed to be installed in a DIN-rail housing so that it fits nicely next to DIN-rail home automation modules. This device can than run the snapcast server but also the player servers (MPD, Mopidy, ...).

• Two snapcast client devices:

  • A device to build into existing speakers: a small DPT-Module based device with line-out and built-in 2x45W amplifier. This can be delivered in PCB form to build into existing speaker sets. (For ex. I have some old first version Bose Sounddock which I converted to Bluetooth, With this device I could convert them to be a very easy to make snapcast client).

  • A bridge device: this should be a DPT-Module with a good DAC good DAC,line out and SPDIF out. The device should also have multiple line and SPDIF inputs to enable passthrough. It should also have an IR transmitter and serial output to control receivers/HiFi amps. This kind of device could be used in the living room where you have your main surround system. When watching Blu-Ray/TV you enable the SPDIF passthrough to have no-latency and lip synced sound. It could be interesting to also use the passthrough as an input so you can listen to this tv-set audio in the rest of the house (news or tv radio for ex.).

[badaix]

After quickly rushing through this thread, a first reply: Selling hardware is quite complex: Even if it is just assembled from existing hardware (e.g. a RPi zero, some audio DAC, and some case), it must be assembled, tested, EMC tested, exported, shipped, declared, exchanged, a warranty must be given, customer support, ... and at the end of the day it must be financially rewarding. Also it should run out-of the box, with some WiFi access point mode for setup and a bunch of build-in services (as mentioned here: Line-in, BT receiver, BT sender, DLNA receiver, Spotify, USB storage, ...)
There are actually two guys selling the Octavio player based on Snapcast. Recently they announced that they drop the support for line-in (don't know why, maybe they got a ground loop).

[daanpape]

@badaix thanks for the input. I'm the founder of DPTechnics and we know what it takes to make and sell hardware. The points you mention are valid and make sense and thus we should first build a prototype to validate and investigate the potential. As this is a personal project it will probably be open source and available for any maker.

Nevertheless the Octavio you mention is very interesting and I hadn't heard about them. For me personally it's lacking ethernet connection, it is a must-have in my opinion.

[traverseda]

I think sustainable free software is really important, so I get excited when I see something like this that I think could be financially rewarding, something that can pay for itself. I hope that something like the Octavio player can eventually end up kicking money back into the open source stuff it's built on.

My time is pretty limited or I'd offer to help out more. I do have time for some stuff though. Like I say I've got access to a laser cutter for some hardware prototyping. Also some good cameras and a pretty gorgeous cafe for promo shots. I might even be able to get some free marketing copy written, and some help putting together a marketing campaign. That offer is open for anyone working in this space that would be producing something largely open-source and who would expect to end up being able to kick money back into the open source stuff it's built on.

I think in general laser-cutting is good for both prototyping and manufacturing, if you were shipping a million units it might need to change things up but it should scale to pretty reasonably sized markets.

@daanpape I like your approach. Would the bridge device also act as a snapcast server, accepting line-in and bluetooth in? I think it's important to have a product that can do that without the need for sysadmin, like I suspect an MPD/Mopidy/Etc device would need.

[daanpape]

I would like to create different devices as described in my previous comment. I think this is required to allow users to create an affordable system. It would become expensive to use the server hardware with all it's inputs when the only thing you want to do is create an extra room with one output.

[daanpape]

I've started working on the client hardware and created the following block schematic:

[geekuillaume]

This is a question I'm also asking myself at the moment. I'm working on Soundsync which is similar to Snapcast with some differences like being multi-server / multi-client and being able to broadcast to different sources like Airplay and Bluetooth speakers.

In the end (and I think it's the same for @badaix), I don't think the hardware/software is the most difficult thing for us to do. The main pain points are the business parts of selling this product: marketing, legal and things like this. The goal would be to find a business partner to handle all these things but this is very hard to do.
If you know someone that could match this, invite them here to talk :D

[dmckminard]

Hello,

I am the co-founder of Octavio mentioned a little above and I wanted to share my experience with you (be careful, however, for the legal questions I am going to talk about, they concerning French laws).
As said above, at the time we were developing our product on Snapcast, but for legal reasons (mainly due to restrictions on the use of AirPlay and Spotify) as well as budgetary, we switched to another technical solution ( which partly explains the removal of the aux-in @badaix ).
If some people wish to get started, do not hesitate to contact me, it is with pleasure that I will share my experience with you!

[spalfs]

Hi guys,

I've actually been working on something like this for the past two months or so, eventually planning on releasing all the boards and stuff as open sorta like:

https://www.olimex.com/Products/OLinuXino/open-source-hardware

If anyones interested in bouncing off ideas of one another and checking out my progress feel free to contact me.

Tom