DLNA: Challenges

Introduction

Last year, I started to work on a DLNA library for Arduino. There are some existing implementations, but they only implement “Control Points”, but no “Devices”. Now that the weather is getting colder, I decided to give this topic some more “love”.

The Digital Living Network Alliance (DLNA) aimed to establish interoperability among PCs, consumer appliances, and mobile devices across wired and wireless networks. The goal was to provide a common solution for sharing digital media and content services.

Though this technology is now more than 20 years old and can be considered obsolete, it is still quite useful for some use cases: For Audio and Video the successor protocols are Chromecast and AirPlay. Chromecast is closed-source and uses secure channels to Google, so you can’t implement your own devices. On the other hand, AirPlay is Apple-specific and is not available on other platforms (e.g., Android). This leaves DLNA as the only open and flexible standard for accessing and sharing digital media (audio, video, images…)!

Challenges

Implementing the Digital Living Network Alliance (DLNA) standard on microcontrollers presents a unique set of challenges, primarily due to the inherent resource constraints of these small, embedded devices. The protocol’s foundation, UPnP, demands a significant amount of memory for XML parsing, device description, and maintaining an HTTP server for media delivery. Furthermore, the computational overhead of handling network discovery via multicast, managing SOAP actions for control, and processing audio codecs like MP3 or AAC can easily overwhelm a microcontroller’s limited processing power. This is compounded by network limitations, where simplified TCP/IP stacks may struggle with the continuous, uninterrupted data streams required for audio playback, and power considerations, as the “always available” nature of DLNA conflicts with the low-power operation that many microcontroller applications require.

On the other hand, modern microcontrollers like the ESP32 or the RP2040 should have enough resources and should be powerful enough to overcome these hurdles, with the help of a microcontroller friendly, optimized implementation!

Here is how I decided to address these challenges:

• Do not not store the Soap XMLs in RAM, but generate them dynamically by writing the data using the Arduino Print API.
• When receiving XML, parse xml fragments incrementally, so that we do not need to store the full XML in RAM but we can dynamically read the data with the Arduino Stream API.
• Do not integrate any Audio functionality into the DLNA, but provide a flexible API, so that we can easily integrate other (Audio) libraries.
• Do not provide a full Soap implementation, but just provide a simple API to create and process SOAP actions and to provide replys.
• Provide a device class and a control point class that provide the relevant functionality for implementing individual devices and control points.

In my next blog, I will describe the cool DLNA Architechtrue and the possibilites that are opened up by providing this functionality for Microcontrollers