DLNA renderer: gapless playback
#1
Hi,

For audio, I use XBMC as a DLNA Renderer, controlled by a laptop running (typically) J River Media Center. One of my biggest gripes with this setup is the delay/gaps between sequential tracks. While it was previously suggested that this is due to slow seeking on XBMC's part, I think this would only effect the size of the gap, not its existence per se.

Over on the JRiver forum it was suggested that one way to achieve gapless playback is through SetNextAvTransportURI.

With the fantastic new audio engine, it would be great to have improved DLNA functionality!

Cheers!
Reply
#2
Hi,

I would absolutely LOVE that! Should this be a feature request in TRAC?

Best

Martin
Reply
#3
BUMP Wink

It's is a bit complicated to achieve gapless UPNP playback. The problem is that the UPNP specification does not really care about playlists.

The usual playback works as follows:
  • The control point (e.g. a mobile device with control app) has a list of tracks to play (playlist)
  • The CP sends the URI of the track to play to the UPNP-server
  • The server pushes the track to the UPNP-renderer
  • If the track is finished the UPNP-renderer informes the UPNP-CP about it
  • The CP sends the URI of the next track to play to the UPNP-server
  • and so on .....
This approach has two major backdraws:
  • If the UPNP-CP enters sleep mode (mobile device needs to save power) playback will stop after current track
  • There will always be a short (~2s) gap between songs

LINN (http://linn.co.uk) came up with a good solution to evade both backdraws:
  • A LINN UPNP-player (DS devices) offers to interfaces
    • First interface is the UPNP/DLNA compliant interface that works with every UPNP-control point & server as described above.
    • The second interface is the 'Playlist' interface
      • The control point (e.g. BubbleUPNP DS) has a list of tracks to play (playlist)
      • It tries to send the playist to the UPNP renderer
      • The UPNP-renderer is then fetching the tracks from the UPNP-server itself

This feature has only one backdraw:
  • It is more difficult to implement, but since XMBC supports gapless playback (not anymore in frodo due to a bug in AE) it should be feasible Wink

BUT this feature has some major advantages:
  • Only the client (UPNP renderer needs to be adapted, there are already apps out there for various platforms which support the LINN-UPNP-extension like BubbleUPNP DS, Linn Kinsky, etc
  • The Control Point does not need to stay online all the time. It can be turned off after pushing the playlist to the renderer
  • The UPNP renderer can prefetch the next song in order to achieve gapless playback

Any better place to place this information? E.g. feature request tool?

Reply
#4
As far as I know jriver, teufel (teufel.de) are supporting this approach as well in their products.

Some info can be found here: http://oss.linn.co.uk/trac/wiki/UpnpPlaylistService
Reply
#5
Are there any news on this topic? I'm really interested in this Smile
Reply
#6
Big Grin 
I am super interested in this topic. I've searched the forums but didn't find an answer to my question...

I've been dreaming of having some setup where I can use a mobile device to select music on my server and pipe it to a player. I must have been living under a rock because I only recently connected the dots that this could be achieved via upnp, well only 95%.. I'll try and keep it short...

I've been doing a lot of research into this, and in upnp land, my server is the library (running minimserver - absolutely fantastic), my raspberry pi is the renderer (xbmc - also absolutely fantastic) and my mobile device is the control point (bubble upnp - yep you guessed it, also fantastic).

Anyway, to my complete dismay, the entire setup breaks down for me for two (what I consider to be) absolutely critical reasons..

1) once my mobile / control point goes to sleep, the renderer (xbmc) doesn't know what to do, and it's most important job is to play the next track. that's all i want.
2) if i grab another mobile device and it becomes the control point, it has no idea of what's been going on

The neat thing about bubble upnp is that it can act as a renderer, library and control point, so while screwing in the settings, I noticed one of super high interest - "enable an OpenHome renderer" so that it can advance the playlist when the control point sleep.

What is this Open Home I googled? holy @#$ some peeps are already on this with the ohnet stack. Check it out: http://www.openhome.org/wiki/OhNet

and to answer the original post, it supports gapless playback because the renderer has the info to make it happen. If you look at the reference applications, you'll see they've been implemented by Linn

So now the question becomes - does XBMC have plans to incorporate the ohnet upnp stack? If not, I'll have to make a formal request.

PS If anyone is wondering why I'm running xbmc on my pi instead of a lighter alternative, it's because I've been using xbmc since it was xbmp and because I can preload and configure it on the pi in literally 5 minutes.

UPDATE: nevermind, I've come to the conclusion this is just a spec, someone would have to implement it in an open source fashion, and if XBMC is using Platinum UPNP as their upnp provider / spec implementation, someone would have to write an open home implementation and make it available for xbmc or the platinum folks would have to update their implementation.

UPATE2: It turns out that BubbleUPNPs server does more than transcode, it can wrap existing upnp renderers into open home ones (and exposes open home versions of them) so it can handle the issues I listed. It looks like it depends on the source renderer to support gapless playback though. Regardless, this is amazing, its exactly what I need. I tested with multiple mobile devices. All work well together to see what's going on with the playlist and neither need to be on for the playlist to advance!
Reply
#7
@duren
Thanks for pointing us to OpenHome. I brought the OpenHome API/spec to the attention of our devs (in case they haven't read your post), let's see if one is interrested in adding this. And in case you haven't seen, it's more than just a spec - they also seem to share working C++/C# libraries etc - see https://github.com/openhome
Reply
#8
(2014-04-06, 06:58)duren Wrote: UPDATE: nevermind, I've come to the conclusion this is just a spec, someone would have to implement it in an open source fashion, and if XBMC is using Platinum UPNP as their upnp provider / spec implementation, someone would have to write an open home implementation and make it available for xbmc or the platinum folks would have to update their implementation.

UPATE2: It turns out that BubbleUPNPs server does more than transcode, it can wrap existing upnp renderers into open home ones (and exposes open home versions of them) so it can handle the issues I listed. It looks like it depends on the source renderer to support gapless playback though. Regardless, this is amazing, its exactly what I need. I tested with multiple mobile devices. All work well together to see what's going on with the playlist and neither need to be on for the playlist to advance!
Maybe it would be best to submit a suggestion upstream to Plutinosoft for ohNet (OpenHome Networking) compatibility support in Platinum UPnP SDK?

http://www.plutinosoft.com/platinum/

As if and when Platinum UPnP libraries supports this ohNet spec. then all projects downstream would gain the benefit of any improvements, including XBMC.

Plutinosoft might also have a commercial incentive to implement missing ohNet compatibility it it could mean that more people would use their SDK.
Reply

Logout Mark Read Team Forum Stats Members Help
DLNA renderer: gapless playback1