Tract looks neat, and I agree that making inference with rich signal support would be a killer app.

I'd love if they did this with pytorch. Tensorflow is quickly falling out of favor.

Deploying models in Rust makes a lot of sense. It's a little rough around the edges, though. (I use Rust bindings to libtorch for https://vo.codes )

Sonos has done some scummy things in the past (bricking units to prevent resale or refurbishment, deactivating old hardware, etc), but they operate in a very hard business sector against giants with monopolistic loss leaders, and this is a really cool open source release. I'm not aiming to buy more Sonos equipment, but I like them a little more now.

Tract supports ONNX models, which you can export from pytorch. See nnsplit[0] as an example for a project that trains with pytorch and serves the model via tract-onnx.

[0]: https://github.com/bminixhofer/nnsplit

You can also export them from LightGBM and XGBoost (see sklearn-onnx) for forests and tract will handle them! // well, almost... I need to finally find some time and finish my tract PR :)

We were unable to get Tract to work at $job but there's another project, I think called onnxruntime-rs that we did get working with our models.

Tract looks incredible, I am surprised that it can support Wavenet on the Raspberry Pi Zero.

I believe it also supports what it calls "pulse" models converted/imported from Kaldi for low-latency ASR/keyword spotting (though this may have changed, I haven't checked in a while).

If they were to give me access to the Linux system running on my Sonos devices, I'd be rather more inclined to buy the idea that Sonos is a supporter of open source. There are many things in need of fixing there, and their customers would be most inclined to help, but no such luck.

Counter point: The Linksys WRT54GL wireless router was incredibly popular, in part because 3rd party firmware could be loaded to it https://en.m.wikipedia.org/wiki/Linksys_WRT54G_series

Correlation is not causation. You have no data to back this assertion.

The first bullet point on the Amazon listing for the WRT54GL is “Linux-based, open-source firmware allows you to customize your device”.

The original WRT54G supported loading third party firmware, until Linksys removed that ability in V5 by switching from Linux to VxWorks. After the backlash, Linksys released the WRT54GL which was able to use third party firmware again. https://www.smallnetbuilder.com/wireless/wireless-reviews/26...

Anecdotally, the only reason I bought a WRT54GL was because I could run DR-WRT on it.

Linksys gave it as a reason for why they still made lots of money with it and thus continued production after they released cheaper and faster followup models.

Disagree. Code is leverage, and leveraging valuable property is a great passtime, and smart for people in tech.

If one percent of SONOS owners use the code, and a fraction of one percent contribute to code, the sky is the limit for all present and future SONOS owners.

> If one percent of SONOS owners use the code

I've worked at companies that added APIs for enthusiasts to use for home automation and other projects. I can tell you from experience that the number of customers who use those APIs is far less than 1%. The number of people who might actually compile code and run it on their device, if given the chance, is vanishingly small.

The real problem, though, is that no matter how hard you try to tell your customers that customizations and custom integrations won't be supported, your customer support channels will be flooded with obscure requests from these customers. As soon as something goes wrong, they want you to fix it. It doesn't take long before they start taking to Amazon reviews to vent their frustrations.

It doesn't matter how many warnings you add, how many times you insist that aftermarket modifications won't be supported, or how much you plead with the enthusiasts to take responsibility for their own modifications. A subset of the hackers will make things miserable for your support and RMA teams, and that's enough to sink these initiatives.

Finally: Once you advertise an API or support for customer modifications, you're on the hook for supporting it forever. Need to re-architect the software for some new features or upcoming products? If it breaks compatibility with customer hacks or integrations then prepare for some of the most vile, angry feedback you've ever received. The hacker community has zero tolerance for losing features or access, so once it's out there you'd better be prepared to support if forever. This might not sound bad at first, but it doesn't take long until you're making choices between advancing the product line and not upsetting the <0.1% of vocal customers who use the APIs/integrations.

I think numbers obscure the rational, what you have outlined is position that eventually puts us in a world where everything is glued shut and the only way in is via someone's walled garden.

Most systems could use an RS-232 port and simple text protocol to do everything the keypad and the display screen could do.

Many systems use SQLite for instance, at least expose a RO version of that database.

There are lots of ways to expose access w/o having to support v0.0.1 of the API forever.

But what you are advocating for is basically locking everyone out of your products so that the rest of the org is affected. Rather than view the wackos who file support requests on an API that only 1:50e3 customers use, find out why they need those extensions and cater to their needs. Often it is for a whole new market.

Breaking internal APIs is also what Linux does. Nvidia and other out-of-tree modules must have a rather hard time with adapting their code to an ever-changing kernel.

Sure there are people who argue for stable APIs. It works for Linux though, and I think that's due to two reasons:

1. There is real value in breaking changes allowing the kernel to move faster.

2. People are not forcibly upgraded to a new kernel. They can do it at their own leisure, when their distro (with manual updates) or personal testing deems it working well enough.

Sonos has recently had some bad publicity for trying to force breaking updates onto people, not in terms of APIs but in terms of actual basic functionality. Their recovery move was to allow people to keep their original functionality, but users accept as a trade-off that doing so will not be compatible with devices running the newer and better software. As far as I can see, this approach resonated much better with the public than the original forced one.

I believe that embedded hackers will have much less of an issue with breakages if the trade-offs are clearly communicated and control over updates remains in users' hands, including a way to revert to a previous version if things go wrong. It doesn't have to be company vs. users necessarily.

But yeah, whether it's worth in business terms to accommodate this exceedingly tiny and understandably demanding minority, that's a different question.

What's the point of a comment like this? Do you really think parent doesn't know that this is a niche interest? Custom integrations etc basically always are only done by a very small number of people, used by a lot larger (but typically still small number), that doesn't make them worthless. There's even an obvious example in the same niche, see the ecosystem around what was the Logitech squeezebox.

I mean, they mostly want to run code third parties wrote not themselves and not just what the manufacturer decided to write. As you see in the router example someone game. As you see in the giant example of android/ios ("There's an app for that"). Even when there isn't an appstore like with desktop operating systems. Even when it's a pain in the ass to install third party apps like remarkable tablets. Even when the "thing" isn't hardware but a base layer of software like minecraft.

In fact, I can't think of a single example of a device that was popular, made it legal and not overly difficult to write and distribute third party code, and didn't have a thriving ecosystem.

Missing the point completely. Yes, I agree, most people just want them to work. But there will be a much smaller number of super technical users who want to pitch in and fix issues or be allowed to develop their own solutions.

Giving those people access is only a benefit to everyone, it doesn't detriment the average users.

> Giving those people access is only a benefit to everyone

From past experience at hardware companies that tried engaging enthusiasts and open source communities, I can tell you that these features benefit <0.1% of the customer base but come at a huge expense to developer productivity.

Once you start down the path of releasing and supporting things publicly, it's a totally different ballgame than simply handling changes and releases internally.

Customers haven't been given the choice

I, for one, would probably-rage build hacky stream integration with my Linux desktop if source was available.

Intriguing that you’re inside it. Or that it exists at all.

If I need some boba fides, I was part of a company that wrote code for Sonos about 15 years ago, so somebody has to do it.

Hacker News users are customers.

Given their history of pissing off customers and their zero respect for privacy, my answer is thanks but no thanks.

https://www.zdnet.com/article/sonos-accept-new-privacy-polic...

https://www.vice.com/en/article/3a8dpn/sonos-makes-it-clear-...

I'm thrilled to see all the mentions of SONOS networking in the article. These devices form their own mesh network, right? Also SONOS devices phone home, a lot. I'd love to see all that mapped and, ultimately, open code committed by the community at large.

I'm still not sure what problem these open source devices really solve. The sorts of people that would be interested can probably already just ssh into their desktop/raspberry pi and don't need anything more interesting than that.

Let’s not forget these projects come from the same company that

1) had a so-called recycle mode in their devices that bricked them with no undo option,

2) lately requires you to create an account on their site just so your networked speakers may work at all.

You know how many internet accounts I need to take a raspberry pi, a USB DAC, hook those to a fine pair of Edifier speakers and run shairport-sync?

NONE AT ALL.

And they acquired and killed Snips.

Heh, the thoughts are similar but not that similar.

https://github.com/mikebrady/shairport-sync

It actually does implement multi-room synchronized audio. This was the one thing keeping me from running an OSS audio solution using RPis. I like that it runs AirPlay, so it can "just work" using existing devices, and not a crazy uncle solution.