Networked A/V setup on the cheap with UPnP

As some insiders might already know,I recently acquired a flat. After 1+ month of heavy renovation, now comes the geek-entertaining time of setting up a sound and video system.
edit: the flat is now on the market again.

Having a very few physical media supports, the setup favors digital content and provide it to any interested playing or controling device. 
UPnP AV/DLNA became quickly obvious with its isolated media provider, controller and renderer concepts.
Unwilling to overpay a dedicated bundle and favoring standards and openess, I went on building my own small wireless flexible A/V system. Might be worth sharing.

The main content is made available by a UPnP server driven by Rygel and Tracker on a spare old laptop (200€). Tracker indexes medias from file system later served by Rygel UPnP server.
The setup was a breeze on Fedora 16 with the minor annoyance of DBus requiring a X session. I guess this coupling will soon be broken in our waylandy days. Hopefully.
Furthermore, each other devices exports its local media content "on the wire".

Music is mainly played on a pair of Raumfeld Speaker M (600€). Those babies access and renders music from UPnP servers through Wifi. 
Take my world as a non-audiophile, but they sound very good at all volumes exposing a clear separation of trebbles, mediums and bass. Dont be fooled by the cryptic documentation, the dedicated Controller is not required to integrate nicely within a standard UPnP network. A small web interface is provided to set them up as standalone.

A Panasonic plasma tv P42GT30 (620€) will take care of sending photons from UPnP content. It is quite on the cheap currently and got a slimmer design while keeping the plasma picture quality.










Free UPnP control point apps were installed on Maemo, Android, webOS, linux, and osx devices. They act as fine-grained remote controllers to distribute content to renderers (speaker or screen).

A cheap WiFi router ties everything together with an auto-magical discovery.


A Spotify/UPnP bridge would be greatly welcome but I couldn't find any up-to-date working solution. Independify seems un-maintained ans segfaults with current deps.

Typesafe GObject through static bindings

Recently, I've spent some time discovering type systems theory and got hook to strong statically-typed languages benefits. I just want a compiler to catch more errors thus giving me thrust and guarantees in the predictability of the product and its code.
I also like my IDE to have a lot of contextual data to help me through the implementation. Completion, early errors and defects detection are quite lifesavers.

Contrary to what one might naively expect from a compiled language, C/GObject lakes such insurances and proofs about the correctness of the generated binary.

GCC unawareness of anything but structs and functions makes it a bad helping hand when it comes to code with confidence.
In order to provide OO idioms to developers, GObject does most of its typing at runtime: types, signals and properties are all resolved and bound at the last minute.
Thereby a successfully compiled binary might fail at runtime for type related issues that a compiler could have spotted earlier. Typoing "opened" instead of "open" as signal or property name might have unexpected consequences at execution for example.
Test coverage should include reading stderr where Glib/GObject throws type warning. Not fun as it implies a edit-compile-run loop.

Lets illustrate the issue. In the following code the signal is always referred as an int within an enum or a string. Arbitrary values could be passed without the compiler to raise any flag. Also the arguments typing is enforced only at runtime through a complex marshaling system. Here again, mistakes might sneak in:
C/GObject (example taken from http://simonpena.com/blog/mswl/discovering-gobject-signals/ )


Some languages bindings with compiler's support of OO idioms exists (Vala, Gtkmm, C#, java-gnome., mono...). Their compilers checks the correctness of types/signals/properties definitions and accesses. Note bellow how both the signal and its handler parameter are typed thus bindings error will be caught at compilation:
Gtkmm

Vala


More than their conciseness, the aforementioned benefits of strongly typed bindings makes them really advisable to newcomers IMHO. The C API might be improved by enforcing the wrapping of signals and their handlers within class. This solution implies some verbosity and a more complex bindings generation that could hinder its desirability. Not my call!