[Question/Feature request]: streaming "system audio" to an iOS device; integrate a DLNA server?

[RJVB]

Apologies if this isn't the proper place for discussing the below:

I've been looking at a "simple" way to stream locally playing audio to an old iPhone that's connected to a proper sound system. Until now I've been able to do that from an old MSWin netbook that holds all my audio content but also has playlists with internet radios, Spotify etc (and is connected over HDMI to my main hifi system); it has Rogue Amoeba's Airfoil installed which does exactly what I want. I can go to a different room, fiddle with the Airfoil Satellite app on the iDevice there, and the audio playing on the main hifi starts playing over that iDevice. That old netbook is showing signs of weakness, Rogue Amoeba no longer market their MSWin version of Airfoil, so I'm looking at options to do the same thing from Linux.

I've done lots of fighting with minidlna, pulseaudio-dlna and Rygel which all allowed my to play content stored on my linux rig from VLC/iOS but which fail to provide something for the currently playing system audio that iOS DLNA clients recognise. Yesterday I finally figured out how to capture output from Pulseaudio (= let the user toggle output to a pipe) and how to play that stream from iOS.

It works, but isn't exactly user friendly:

• you have to enter the stream URL (which can't be customised) by hand in VLC
• there's no way to stream something other than mp3?
• instructions on how to set up the pulseaudio pipe are succinct at best, I still haven't figured out how to give it different name from the pipe file itself
• you have to select the pulseaudio pipe in the Remote app which (of course...) doesn't control local playback.

I haven't yet found an alternative iOS app to the Remote app that also works as a player but if that's impossible because of Apple's silly rules, wouldn't it be an idea to integrate a DLNA server into forked-daapd? I assume that it should be possible (if not feasible ;)) to use requests from the DLNA client as commands to select content and output device and control playback. You'd need only a single daemon to serve DLNA clients too ... and if you can make the streamed pulseaudio pipe like a regular "song" to DLNA it might actually show up in iOS clients (existing ones, no need for a new app which would probably never be available for repurposed=older iOS devices).

[ejurgensen]

Yes, Apple doesn't make playing to an iPhone easy. I looked a bit at DLNA a while ago, but at the time I didn't really find any reason to proceed with it. I agree with you that it could bring the benefit that the user could then listen to the non-file sources (pipes, radio stations, Spotify) that forked-daapd supports. I'm not sure exactly how much work would be in it, but it is probably significant. I know the similar task of serving non-file sources to iTunes (also not supported currently) isn't trivial.

[RJVB]

Except that in this case you should be able to build upon almost any number of existing DLNA server implementations, from utility libraries like GUPnP-DLNA to a complete "mini reference implementation" like minidlna.

I'm no expert in these matters, or else I'd volunteer to start hacking on this. But I do note that a DLNA client in fact plays back a stream over http (e.g. http://192.168.1.46:8200/MediaItems/699.m4a); after getting that URL through VLC's DLNA browser I can just play it anywhere. Downloading it gives me an exact copy of the source file (also for mp3 and wav files). If I had to guess I'd say I'd expect you could reuse all the "icing on the cake" related to indexing the library, and you'd "only" need to figure out how to insert the stream.mp3 URL in the context exposed over DLNA.