UPnP devices do not see each other

If UPnP devices do not see each other, most likely there are two problems:

Multicasts are not forwarded

Simple Service Discovery Protocol (SSDP) uses multicast IPv4 address 239.255.255.250. The local switches must be able to forward such traffic. On a Cisco switch you run the following command to allow that:

no ip igmp snooping vlan 101

Firewall blocks UPnP traffic

Related ports: UDP-1900 and TCP-2869

Universality vs Simplicity or PSAudio and The Bridge woes

In my mind, universality and simplicity are mutually exclusive. I’m yet to find a system which is universal and simple to configure and use. Reliability and stability are assumed by default.

The simplicity of Apple devices is addictive. You add a new box, and it gets automatically recognized. Everything just works like prescribed and defined by Apple. Then it’s a question of if this Procrustean bed fits you or not and if you are flexible enough to assume the offered model.

The idea of service/device discovery appeared in the late 90s. For example, Sun’s Jini (1998) and UPnP (1999). It’s nice to have a standard to allow devices from different vendors to work together, right? Sure, but here comes the reality. The Cisco interpretation of the Spanning Tree Protocol is different from the Foundry (now Brocade) one. If you place Cisco and Foundry switches/load balancers in one LAN, you may end up with a funny STP loop.

So what do you expect from UPnP? Consumer boxes from dozens of manufacturers, software from the whole open and proprietary world – something must definitely go wrong here. It’s a bit more complex than an Apple printer and an Apple laptop.

The Bridge from PS Audio is designed as a UPnP media renderer (it’s a uClinux running rygel). It’s not more complex than similar products, it’s just not properly thought over. The original idea was to make it as simple as possible. Most likely having Apple in mind. However, it turned out that playing music became the proverbial pain in the ass. Despite the fact that PerfectWave DAC sounds better than the Transporter, I suddenly discovered that I almost stopped listening to music. And I consider myself as computer savvy and a diehard. My family keeps asking to connect the old CD-player back to the rig.

In the world of high-end audio, multiple functions and universality are not required. All we need is to bring x amount of bytes from one device to another. Some configuration is needed in any case, so I would sacrifice the incompatible and unreliable simplicity of UPnP and familiar but unstable and lossy nature of Internet streaming and use a platform independent solution (server and controller side) which is supposed to work with the Bridge only (client side) and not with any possible device.

The most elegant solution is from SlimDevices (now Logitech). Run-it-everywhere PERL driven server with a see-from-anywhere web-interface, direct connection to the player (Transporter, SqueezeBox, etc) and a bunch of plug-ins (there is also a UPnP plugin).

Linn created their own packages to make Twonky server work correctly with Linn UPnP media players and to add on-the-fly transcoding. Twonky is included in some NAS software (Linux), so the server issue is more or less solved.

At first, PS Audio relied on what was available on the market and wrote an UnNP controller application for Apple iDevices (how Apple centric!). Next step was the eLyric Music Manager – a UPnP/Database server which is still way too far from maturity. No UNIX support, no built-in UPnP controller (it’s possible feature for not the nearest future) and still extremely buggy.

The Bridge solution is about two year old, and we still have no reliable, platform independent and good sounding software.

And yes, I’m still using PWD/Bridge and sending eLyrics and Bridge bug reports. (Speaking of customer loyalty πŸ˜€ )