A linux controller is needed.

n my view the best approach would be for Sonos to use a cross-platform development environment such as Qt for future controller development. This would allow the app to be portable across all major desktop environments, and Qt is pretty lightweight compared to .NET +1 Majik This would be an excellent way to "give back" to the open source community and perhaps reduce maintenance across different OSes. I have read that subtle GUI differences across platforms are difficult to address with Qt but that may have changed. I also expect those subtle differences would be difficult to address with any software. Since Qt can be implemented as open source it would eliminate concerns about possible proprietary changes made to .NET by Microsoft. One can argue that many of the frustrating changes we have seen lately, e.g. the UEFI replacement to BIOS, have been implemented to favor a particular vendor's OS in this case Microsoft and are anti competitive in nature. I am eager to learn what the Sonos Technical Review Board decides to do with this. Sonos only response to this thread has been that the request has been submitted.

EnnaN, A large part of the Sonos control protocol uses standard UPnP AV which is documented at upnp.org. I will note that UPnP itself is complex as a protocol (actually a suite of protocols) and it's not something you would want to program without a support library, which there are several around. It is also an asynchronous, event driven system which can be mind-boggling for people used to simple linear programming or scripting. Sonos has added a lot of additional functions over and above UPnP AV, and some functions (like the queue) are handled differently, but the nature of UPnP means it is easy to see how these work and, whilst they aren't doucmented in the form of an "idiot's guide", there is technical documentation as part of the UPnP specification which describes each call and what parameters it takes. You can use a tool like UPnP Device Spy to pull these device descriptions directly from the device itself. Note there are some ignorant people around who refer to this as "sniffing" or "reverse engineering". This is entirely wrong. These are developer tools designed for programmers to use and UPnP is designed to expose the interface in this way. The vast majority of functions on Sonos are straightforward and require no further explanation (to a programmer) than these exposed interfaces. In other words, exploring this documentation will pretty much explain how to do most functions if you are an experienced developer who understands UPnP development. On the other hand, if you are an end-user with a bit of scripting experience who wants to know "how do I do X quickly and easily?", it won't help you at all. Unfortunately, some people equate their own lack of skill/knowledge as being Sonos's fault. There are some functions relating to external music services that are proprietary, but this is largely because the APIs belong to the individual music services, not to Sonos. In some cases these APIs will require sniffing and reverse engineering in order to use them. In other cases the music service may provide API documentation. In general, Sonos doesn't tend to break many things between releases. In my view the fear that they might has been emphasised out of all proportion, usually by people who have never tried to write a UPnP control application in their life. Getting stuff working like the original PERL controller (written in 2005) can be hard, but that's mostly because it's abandonware and has not been properly maintained for a few years. Problems getting it running are as much to do with changes in PERL and the support libraries it uses as it is with changes in the Sonos control protocol.

blue_bullet, Whilst I'm not against Sonos open sourcing the DTC at all, the use of Qt also allows a commercial licence to be used. Open Source would be best for obvious reasons, but I think most people would be very happy with a closed-source native Linux DTC. And the nature of some of the third party APIs they hook into for music services may prevent them from Open Sourcing it.

Majik, Got it. Sonos can purchase a license then give away the DTC as closed source. I like the way Digia markets their product. Give your Qt software app away as open source and no license required. Ask for money or close the source then a license is required. That all seems right and fair to me. Additionally the KDE folks have insured Qt software will remain available if something happens at Digia that makes Qt unavailable or no longer free. To me that makes Qt a good choice for future development and one of the reasons KDE chose Qt.

I just upgraded to sonos 4.0 and its a pity to see that it does not work with wine under ubuntu. And I will not start using windows just to have a working controller.. This is basically really annoying.

Not Good, this is a must to have a "Linux Controller" and be able to access the Music libraries from every single computer in our home. Got few Sonos and currently not able to enjoy the music the way we want it....

Would it be possible to embed a web server to control the sonos equipment in the Bridge device, or create a Bridge 2.0 that has that functionality? I currently do not use the bridge device, but if it would allow me to control the sonos devices via a nice ajax interface, then I would install one just for that. Also, this would allow any device that contains a browser to control the sonos environment. Linux, FreeBSD, Mac, Windows, Win RT, etc. all using just a browser... no more dedicated client app. except maybe on phones / tablets. I do not need the ultra responsiveness of a dedicated app on my PC, 99% of the time I am just adjusting volume / pausing / playing.

Would it be possible to embed a web server to control the sonos equipment in the Bridge device, or create a Bridge 2.0 that has that functionality? I currently do not use the bridge device, but if it would allow me to control the sonos devices via a nice ajax interface, then I would install one just for that. Also, this would allow any device that contains a browser to control the sonos environment. Linux, FreeBSD, Mac, Windows, Win RT, etc. all using just a browser... no more dedicated client app. except maybe on phones / tablets. I do not need the ultra responsiveness of a dedicated app on my PC, 99% of the time I am just adjusting volume / pausing / playing.
I think this is a good idea, but maybe something for its own topic? Because while it is a valid wish, it doesn't really remove the need for a full fledged client on linux 😃

Would it be possible to embed a web server to control the sonos equipment in the Bridge device, or create a Bridge 2.0 that has that functionality? I currently do not use the bridge device, but if it would allow me to control the sonos devices via a nice ajax interface, then I would install one just for that. Also, this would allow any device that contains a browser to control the sonos environment. Linux, FreeBSD, Mac, Windows, Win RT, etc. all using just a browser... no more dedicated client app. except maybe on phones / tablets. I do not need the ultra responsiveness of a dedicated app on my PC, 99% of the time I am just adjusting volume / pausing / playing.
There are 2 issues here, having a Linux Controller is one and the other is being able to access your Music Libraries is another. For now I use Android Controller on my smart phone to get around Sonos. The main problem is accessing my collections of old Jazz and Blues which can NOT be done at present time...

I just upgraded to sonos 4.0 and its a pity to see that it does not work with wine under ubuntu. And I will not start using windows just to have a working controller.. This is basically really annoying.
Just the fact that sonos4.0 work not fully, but work with last version of wine, wine 1.5.25 on ubuntu : sudo add-apt-repository ppa:ubuntu-wine/ppa sudo apt-get update sudo apt-get install wine1.5 winetricks dotnet40 reboot system and install last controller I sucessfully use it since yesterday, some tools aren't working, but main function are OK