Sorry, you need to enable JavaScript to visit this website.


Your feedback is important to keep improving our website and offer you a more reliable experience.


As an umbrella project, dLeyna hosts a cluster of middleware components for the implementation of Digital Media Servers, Digital Media Renderers, Digital Media Controllers and Digital Media Players. These readily available APIs enable consumer electronics system builders to reduce Build-of-Material costs and time-to-market.

The dLeyna project was born out of the belief that client side DLNA functionality should be not be restricted to a single application, such as a DMP. Rather, it should be made easily accessible to all applications that can potentially benefit from it. There are many such applications. For example, a smart phone may contain a media player for playing audio and video content, a photo application for browsing photos, a photo editor for touching up images, etc. All these applications are potential clients of a DMS, so all could benefit from some level of DMP functionality. Also, any application that can download or create content, such as a paint app, a podcast tool, and perhaps even a browser, could be enhanced by the ability to push that content to a renderer.

DLNA For All

The scene has now been set. Our fictitious smart phone is now brimming with applications, all making use of the DLNA network to the delight of its users. To make our smart phone a reality, application authors need to have access to APIs that they can use to take advantage of DLNA functionality. Now, it so happens that there already some excellent APIs, maintained by the GUPnP project, for discovering and manipulating UPnP devices. DMSs and DMRs, types of UPnP devices, can be manipulated directly with these APIs (DLNA devices use the UPnP protocol to communicate with each other). However, in our desired scenario, where there are multiple DLNA applications all potentially running at the same time, it does not really make sense for these applications to use the GUPnP APIs directly. There are a number of reasons for this. Firstly, the GUPnP APIs are generic APIs that can be used to manipulate any UPnP device, such as a router, a printer, or a light switch, and so are necessarily low level. You need to write quite a lot of code to search a DMS or to retrieve the contents of its root directory. So, the direct use of GUPnP in each application would, in all likelihood, result in code duplication. The problem is exacerbated by the fact that large portions of the UPnP specifications are optional. Search for example is optional. So, DMS A might support search, while DMS B does not. In fact, the situation is even worse than it first appears because both servers might support search, but DMS A might allow the user to search on album and artist name, while DMS B might only permit searches on artist name. This makes it difficult to write DLNA applications because these applications need to contain code to cope with the various levels of support that DMSs and DMRs have for the optional features of the standards. Again, direct use of GUPnP in applications would require such code to be duplicated in each application. Secondly, correct use of the GUPnP libraries requires in depth knowledge of the UPnP specifications and hence is reasonably complex. Such complexities may discourage developers from including DLNA functionality in their applications. Thirdly, and perhaps most importantly, the direct use of the GUPnP libraries in each application will generate a lot of redundant network traffic. Every time a new DMS joins the network, it sends out a broadcast message announcing its presence. This broadcast message contains a URL. Each DMP on the network uses this URL to download at least three different XML files, which need to be parsed before the DMP can talk to the DMS. The amount of network traffic generated, and the amount of XML that needs to be parsed, varies according to the capabilities of the DMS. For basic DMSs, about 50kb of data is downloaded and parsed by each DMP. However, this value will increase substantially in the future, as DMSs begin to support more features. This is a problem in our scenario because there will be multiple applications taking advantage of DLNA functionality and all of these could run at the same time. If ten such applications were running, each would download and process at least 50Kb of data when a new DMS joined the network. The problem here is that each application would be downloading and processing the exact same data. So, our smart phone would be downloading and processing 450kb of redundant data. This problem could be much worse when the device joins a new network that contains multiple DMSs. If, for example, the network hosted three DMSs, the device would be likely to become sluggish on joining the network as 10 applications needlessly download and process 1.35MB of redundant data. Our discussion here has focused on DMSs, but it applies equally to DMRs. In fact, the situation is likely to be worse where DMRs are concerned because there will potentially be more DMR clients. As previously mentioned, every application that can download and create content is a potential client of a DMR.

The Missing Link

Hopefully, it will be clear to the reader, at this stage, that something is missing from our DLNA stack. Namely, some high level DLNA APIs that make it easy for applications to implement the DLNA use cases, that isolate the applications from the complexity of the DLNA and UPnP specifications, and that eliminate redundant network traffic when multiple DLNA applications are running at the same time. In short, the dLeyna project aims to provide these missing APIs with the introduction of two new pieces of middleware, dleyna-server-service and dleyna-renderer-service.

dleyna-server-service can be used to implement a DMP or to implement the Download System Use Case. dLeyna-renderer-service can be used to implement two-box push. Together, these components can be used to create a DMC. These components expose high level APIs that can be used to easily integrate DLNA functionality into applications. They are implemented not as libraries, but as d-Bus services. This allows them to offer toolkit and language independent APIs and also to eliminate the problem of redundant network traffic by issuing requests to the various DLNA devices on behalf of the applications. For more details about dleyna-renderer-service and dleyna-server-service, refer to respective project pages.


The image below shows how dleyna-server-service and dleyna-renderer-service fit into the overall software architecture.


As can be seen from the diagram, both dleyna-server-service and dleyna-renderer-service make use of the GUPnP libraries. DLNA applications, in turn, depend on the dLeyna components. The MediaPlayer and the Photo Viewer applications use dleyna-server-service to access remote media content hosted on DMSs. The Browser and the Podcast App use dleyna-renderer-service to push media and podcasts to DMRs, running perhaps on televisions or HiFis. The DMC application uses both dleyna-server-service and dleyna-renderer-service. Note that a DMC is not the only application type that might be able to take advantage of both dLeyna components. For example, a photo editor application running on a smart phone might use dleyna-server-service to locate source images to edit and dleyna-renderer-service to render edited images onto a larger screen.