Sonos smart speaker controller API and CLI written in Rust
github.com
github.com
They keeping cutting features and making their older speakers obsolete. I'm furious as an early adopter of Sonos that they are essentially bricking my older speakers or making them useless for no reason. I can't Airplay to them either because they are older. I can see in the next year or so them completely rendering my speakers useless, which is unethical. I'm done with them.
https://github.com/philippe44/AirConnect
on a raspberry pi, works great
Maybe it’s because I’m no longer in the business of amassing a horde of mp3s and instead use Spotify and amazon music.
Maybe it’s because I haven’t opened the Sonos app in months, and instead use Alexa’s integration or Spotify’s integration to play my music.
Except for Airplay my several years old speakers work fine. I’m happy with the support so far.
https://github.com/badaix/snapcast#Snapcast
https://www.home-assistant.io/blog/2016/02/18/multi-room-aud...
I use shairplay[0] to stream from an iOS/macOS device, and Mopidy[1] with the Iris UI[2] to play server-side from your music collection, Spotify, or other internet radio.
[0] https://github.com/juhovh/shairplay
[2] https://github.com/jaedb/Iris#readme
My "speakers" are cheapo Bluetooth speakers with a raspberry pi attached to the back. Works beautifully and reliably. If the old Sonos devices have line in, maybe this is a way to continue using them?
But they brick their older hardware or render them purposefully useless so as far as I'm concerned they are evil as fuck now.
Fully realizing the hit on privacy, I understand the thing enough and, more importantly, trust my particular manufacturer enough that it simply outweighs that concern for me.
Then I saw that they were Sonos-based, and immediately noped out of buying any. I'm not keen on buying something if the vendor can yank features (or worse, brick the gear they sold like Logitech did) at their whim.
Did they ever support this? They don't have built in Bluetooth, and I think they only talk NFS and Samba(?) for audio servers.
The other integrations over UPnP/SOAP (IIRC) are for sending it audio URLs or instructions to play Spotify, Google Play, etc.
Some of these pieces might have been pulled out with recent API updates?
I don't have firm details, only forum hearsay, and I'd love to find out what's actually going on with Sonos' APIs.
I explained why I wouldn’t take it and my main argument is that any “smart” device isn’t exactly reliable in the long term, be it missing updates for old hardware, cutting out features, servers that stop working etc.
He got a simple Amp with a single volume knob now and some decent passives. Phone connects via line cable.
This is quite nice, because it allows me to stand up and walk around while the PC continues its audio playback.
I use something exactly like this product (an old one from monoprice actually I believe). Simply plugs into the back of a 2.1 speaker set I have. Guests at my place love it, they can easily just connect to the Bluetooth and play through speakers. Pretty seamless. Not sure of any quality drop, my speakers aren't the best.
Let’s see how the future of smartphones pans out, when it comes to audio jacks tho : )
The hardware is great, but their constant software updates are TERRIBLE!
I would never a product from them again and I tell everybody who comments / asks on our home set-up the same thing.
Want to play music but they want you to update? Guess what? No option but to update right away.
The app consistently changes UX and REMOVES functionality making it extremely frustrating.
Feels like a company that is in harvest mode and driving towards irrelevance.
For me, the biggest gripe is that its a pain in the arse to get networking to work when your configuration gets more complex than an "average person" living in a small house/apartment. Especially when there are multiple ways to make a wireless network connection across your property, and/or you have multiple subnets. At this point, I can bring down half my home network by connecting a new Sonos box, before I've changed some of its default configurations (which you can't do until you have it fully setup and connected).
My second biggest gripe is that they don't make rack-able multi-channel units. I'd love to rack one or two of these in my wiring closet instead of having a stack of Connect:AMPs on shelves.
Denon apparently now has a Sonos competitor that at least partially solves the second issue. I'm curious to see how it compares, but I've got enough Sonos gear that I'm not really ready to seriously consider replacing it. (And once all my stuff is setup, it does work rather painlessly.)
This is flat out false.
Far too often, I open the app and just want to play something. It prohibits me from doing so until I update software.
It is an incredibly user hostile and annoying behavior in an otherwise good product.
From here on it'll be a Pi connected to an amplifier and speakers that won't try to subvert my will simply to listen to music.
I also liked Roon Bridge on the Pi (and felt the audio output was slightly improved, although made no effort to counter the placebo effect) but couldn't quite justify the cost.
I used to share my DAC between my laptop and my desktop this way. Whenever I plugged my headphones in, it'd default to them on the local device, and the remote would default to the network device. I could walk away from my desktop while playing something, and it'd continue playing on whichever I had my headphones plugged into.
i like the ikea symfonisk speakers but won't buy them for the same reason.
I do wish our Play One could proxy Airplay to the others.
I wish AirPlay behaved more like Line In does (on speakers that support that), where the Line In devices become available to any speakers on the network.
Are you talking about some other way to stream it?
I know Apple is all mDNS (for AirPlay), I don’t know anything about Sonos though.
I messed around with their stack and internals for a while about ten years ago... some remnants remain
https://github.com/NathanHowell/Sonority/tree/master/
Are they starting to lock it down through API updates? If so, that's terribly unfortunate and I'll have to rethink my audio setup and future purchases.
[1] http://hecgeek.blogspot.com/2017/10/wall-o-matic-interface-1...
Is this interesting simply because a device with a well-documented API is now accessible from Rust? If not... what new information is being presented?
15 minutes work for him, would save every user 30 or more minutes.
Not going to try it because of this. A shame. Did find another interesting cli though: https://pypi.org/project/sonos-cli/
Maybe you could contribute instead of complaining?
I find it quite frustrating that open source/current company projects have no or little documentation. Even for a 12 days project it is frustrating. It is just good habit that documentation is as important as code. I like to say that if it has no documentation, it does not exist (to the user/contributor). I also think that code is a way of communicating with your future self or future developers. So clear code and clear documentation is important. Code is not important to the computer, the computer does not care about naming things.
In the case of this particular developer, it isn't just for themselves, but also in a different language, and they've done their best just to reflect an existing API. They've asked for pull requests.
I can understand not wanting to do the enormous amount of work of translating an API that is already pretty-much documented when I won't really see any return at all.
Rust is trying to get to the threshold where it's applicable in the workplace. (All but a few major companies use it.) Unlike Golang, it needs all the cheerleading it can get to push it over that hurdle.
I want to use Rust at work instead of Java.
I'll assume not everything is covered.
It should be a good place to start if anybody wants to extend it (:
If I create a group of speakers, how do I play something on them? If I have 2 speakers that are airplay-capable, Do I just pick one?
Where are these pulled from? Is this the same game as with other dependency managers in that you blindly trust a tree of code written by random people?
In this specific case, most dependencies are authored by people well-known and trusted in the community. The Rust standard library is pretty well-rounded (not compared to Python sense, but it's not like JavaScript either), so they're not something like left-pad or is-odd.
You have there an error handling crate by the second most prolific Rust compiler contributor (if the counts are correct), an OAuth client, an HTTP one, a interactive line editor (like readline), _the_ serialization library in the ecosystem with its JSON support crate, a TOML config parser, the URL parser used by Servo and a crate for determining user paths on Unix.
For instance, you can target a repository and even a specific commit like this in gour cargo.toml file:
[dependencies]
package = { git = "https://github.com/...../something.git", rev = "commit_hash_like_9876541_for_instance" }Don't specify the git repo directly in dependencies unless it's an unpublished crate.
I wish Rust made it easier to know who the author of a package is (i.e. namespace packages so it's clear in the Cargo.toml), but I do think they've done a better job at designing crates.io than some other package repositories (i.e. npm).
[1] https://boats.gitlab.io/blog/post/2017-10-28-alternative-reg...
[2] https://www.reddit.com/r/rust/comments/9gl8p3/host_local_rep...
says "Google Assistant" and "Alexa Built-in".
Maybe your threat model doesn't allow any hardware with a speaker that has updates, but that's not a reason to say it's an invalid setup for everyone's threat model nor to claim that, even without evidence, it's definitely going to be abused.
You could have taken a look round the site rather than just looked at one product...