INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: AndrewFG on January 05, 2012, 09:16:09 am
-
I see that your UPnP DLNA media Renderer supports SetNextAvTransportURI "for control points that use it".
So given that you think it is a valuable feature, my question is therefore why does the MC control point not use this action?
Implementing it should make the playback experience much smoother.
-
I see that your UPnP DLNA media Renderer supports SetNextAvTransportURI "for control points that use it".
So given that you think it is a valuable feature, my question is therefore why does the MC control point not use this action?
Intel recommended against using SetNextAvTransportURI in one of the official UPnP documents (sorry I don't have a link).
Personally I think it's better than nothing since it makes gapless and cross-fading work with DLNA. So we support it when rendering.
When controlling, we try to do the most compatible approach which is to not call SetNextAvTransportURI.
Maybe it should be an option?
-
When controlling, we try to do the most compatible approach which is to not call SetNextAvTransportURI.
Maybe it should be an option?
I would certainly support having it as an option. You could test if SetNextAvTransportURI is listed in the device's SCPD document, and if so use it, and otherwise do it the old way...
-
Maybe it should be an option?
This could give us gapless playback when playing music from jrmc to squeezebox devices when played through Andrews Whitebear upnp server. This would be the best solution for me and I think a lot of more people who think jrmc is the best app for organizing and selecting our music and have squeezebox devices in our homes to play our music.
-
Intel recommended against using SetNextAvTransportURI in one of the official UPnP documents (sorry I don't have a link).
If you google this, you will find quite a few rumours about what "Intel once said..." but there is no reference to any actual official document from Intel. Therefore I suppose that they have in the meantime withdrawn any such statement. The fact is that 3 guys from Intel did put their name officially to the approved versions of the UPnP AvTransport specification (the latest version 3 of which was issued on December 31, 2010) which I excerpt as follows:
2.4.2 SetNextAVTransportURI()
This OPTIONAL action specifies the URI of the resource to be controlled when the playback of the current resource (set earlier via SetAVTransportURI()) finishes. This action allows a device to prefetch the data to be played next, in order to provide a seamless transition between resources. This type of prefetching or buffering is particularly useful for protocols such as HTTP, where the data is usually buffered before playback.
-
If I understand the responses to this thread and my thread correctly, I would love to see it as an option !!!!!
-
If you google this, you will find quite a few rumours about what "Intel once said..." but there is no reference to any actual official document from Intel. Therefore I suppose that they have in the meantime withdrawn any such statement. The fact is that 3 guys from Intel did put their name officially to the approved versions of the UPnP AvTransport specification (the latest version 3 of which was issued on December 31, 2010) which I excerpt as follows:
I wonder how that fits into the end of track logic? Perhaps that's why it doesn't seem to be implemented anywhere? I'm going to do some thinking out loud..
So lets say we do a SetAvTransportURI to the first track..
then while it's playing, anytime (I assume) we can do a SetNextAvTransportURI for the next track and how then is the end of the playing of the current track handled?
Normally we go through the playing/transitioning/stopped logic (depending on the device, they are all not the same with the timing at end of track).
Perhaps the DMR doesn't do the playing/transitioning/stopped logic when it's already set to request the next track. However we are going to need to know it's transitioned to the next track so we can display it properly and get the next one queued up for the next SetNextAvTransportURI call.
What do you think Andrew?
-
We sat around and brainstormed on this a bit today and came up with the following idea:
We create a new function, let's say SetAVPlaylist.
In that, instead of CurrentURI and CurrentURIMetadata we have PlayListMetaData with blocks of didl that look the same as the CurrentURIMetadata but it's the whole list of items to be played on the DMR. Now in there we can have an index into the playlist to specify which to item to start with. For example, if I wanted to start with the 5th track on an album and go from there the index would be 5 (and would start playing immediately). If the index was 0 we could say that indicates that this playlist should be appended to any previously existing playlist after finishing the current item. If it's -1 it replaces any existing playlist and plays after finishing the current item.
If the DMR returns an error when fed a SetAVPlaylist, we revert to SetAVTransportURI.
Once the SetAVPlaylist was sent one could even shut off the DMC (assuming the DMS was some other machine).
-
I don't think it is a good idea to implement a non standard approach.
The two standardised UPnP/DLNA actions are SetAVTransportURI and SetNextAVTransportURI. Period. You should not try to create something else...
-
Intel recommended against using SetNextAvTransportURI in one of the official UPnP documents (sorry I don't have a link).
Personally I think it's better than nothing since it makes gapless and cross-fading work with DLNA.
wait.... what? How do I get gapless via DLNA? Every single control point I have used cannot send MC the playlist and is therefore decidedly gapped.
Thanks!
Patrick
-
I wonder how that fits into the end of track logic?
What do you think Andrew?
Assuming MC has a master playlist containing several track URIs, I would suggest (something like) the following. (You could probably optimise the loop) :-
if PlayList.Count > 0 then
begin
priorTrackIndex := 0;
nextTrackIndex := 1;
SetAVTransportURI( PlayList[priorTrackIndex].URI );
while nextTrackIndex < PlayList.Count do
begin
if nextTrackIndex > priorTrackIndex then
begin
SetNextAVTransportURI( PlayList[nextTrackIndex].URI );
priorTrackIndex := nextTrackIndex;
end;
NowPlayingURI := GetPositionInfo().TrackURI;
if NowPlayingURI = PlayList[nextTrackIndex].URI then
nextTrackIndex := nextTrackIndex + 1;
wait 3..5 seconds
if interrupted then break;
end;
end;
No doubt somebody will notice the "wait 3..5 seconds" in the above and complain about how that cannot possibly provide gapless playback....
Well the point is that the SetAVTransportURI plus the SetNextAVTransportURI means that the player always has a local mini- playlist consisting of TWO tracks (only); while it is playing the first track, it can start queueing the second track; and when it has finished the first track, it is in a position to start playing the second track immediately. At this point the local mini- playlist shrinks to one track only, the second track becomes the first and now playing track. At some point while this track is being played, (with some delay), MC will learn via GetPositionInfo that the now playing track is not what is was before, and it then calls SetNextAVTransportURI to add the next track from its master playlist into the player's local mini- playlist.
In this model, you get gapless playback for all but the shortest (3..5 seconds) tracks...
Edit: there is of course one edge case in the above code, if the MC master playlist would contain the same track URI twice in succession, then the second instance of that track would not be played. I leave it as a programmers exercise how to resolve that ;-)
-
Every single control point I have used cannot send MC the playlist and is therefore decidedly gapped.
That is because none of the existing CPs and very few renderers have implemented SetNextAVTransportURI. Probably due to lazyness on all sides. We need to start a virtuous circle, whereby CP makers and renderer makers start to see SetNextAVTransportURI as being an essential part of compliance to the standard. Please lobby all parties involved, to get this circle going. If MC would implement it quickly, then they would have a first mover advantage for gapless playback via UPnP. So please lobby them to do it too..
-
And Gapless DLNA would make a nice feature advantage for MC.
We were listening via MC/Whitebear/SB DLNA the other day, and the gaps between songs was distinctly noticeable.
-
We sat around and brainstormed on this a bit today and came up with the following idea:
If you plan to develop a gapless solution I'd advise you to go with Linn/OpenHome Playlist service which moves playlists to the renderer and also supports multi-controller operations.
Most of the implementation code is Open Source with a BSD licence, so you could eventually include it in your code without any legal side effect.
Some controllers already support Playlist service. Plugplayer is one of them.
-
That is because none of the existing CPs and very few renderers have implemented SetNextAVTransportURI. Probably due to lazyness on all sides.
I am not sure if this is the same thing as "Linn Style" Playlists, but it seems like more than a few are using this method. The dev of PlugPlayer was surprised that MC didn't have gapless replay with PP as control point. They were in discussions with Jim/Bob about possible implementation of whatever would allow PP to send the entire playlist to MC.
At some point I recall Jim/Bob (sorry I dont recall which) said it was on the short list of future features.
Would this type of playlist solve Andrew's problems above?
Thanks!
Patrick
-
That is because none of the existing CPs and very few renderers have implemented SetNextAVTransportURI. Probably due to lazyness on all sides. We need to start a virtuous circle, whereby CP makers and renderer makers start to see SetNextAVTransportURI as being an essential part of compliance to the standard. Please lobby all parties involved, to get this circle going. If MC would implement it quickly, then they would have a first mover advantage for gapless playback via UPnP. So please lobby them to do it too..
Actually, MC as a renderer supports SetNextAVTransportURI (since version 14). Anyone got a CP to test it with??
Of course, implementing SetNextAVTransportURI as a CP won't help at all with the issue of sending a playlist then exiting the CP.
What we were proposing would solve both gap-less and walk away playlist without the complexity of the openhome extensions.
-
... advise you to go with Linn/OpenHome Playlist service which moves playlists to the renderer and also supports multi-controller operations.
Most of the implementation code is Open Source
Its easy to say "open source". But do you seriously think that any of the major renderer manufacturers (think Sony, Denon, Samsung etc.) would even dream of implementing an "open source" solution developed by Linn? ... Dream on...
-
Its easy to say "open source". But do you seriously think that any of the major renderer manufacturers (think Sony, Denon, Samsung etc.) would even dream of implementing an "open source" solution developed by Linn? ... Dream on...
Maybe not the "major" mfrs. But the "high-end" mfrs seem to like it e.g. Boulder, PS Audio, Linn, Olive, Meridian etc, along with a few different control points, eLyric, PP, Kinsky, etc.
-Patrick
-
Of course, implementing SetNextAVTransportURI as a CP won't help at all with the issue of sending a playlist then exiting the CP.
Actually, if you only want to do that, there is an already existing, tried and tested solution: When you call SetAvTransportURI, instead of passing the url of a single track, you just pass the url of a .pls or .m3u playlist file. The renderer downloads the playlist file and works through the playlist accordingly. Obviously in this scenario, you can't actually exit the CP, because it is also your server, so you need it running so the renderer can get the tracks. Also it is a bit of a munge because there is no mechanism for passing track meta data.
-
Actually, MC as a renderer supports SetNextAVTransportURI (since version 14). Anyone got a CP to test it with??
Apparently (from reading others' posts) Plugplayer can issue SetNextAVTransportURI. But it will only work if he implemented the pseudo code playlist stuffing algorithm that I posted earlier in this thread. Clearly if the CP waits for the current track to end before sending SetNextAVTransportURI then there will obviously anyway be a delay. The CP must be proactive in pushing the next track into the renderer's playlist immediately it sees that the current playing track has changed; that gives the renderer the whole duration (more-or-less) of the current playing track to set up for playing the subsequent track.
-
Apparently (from reading others' posts) Plugplayer can issue SetNextAVTransportURI. But it will only work if he implemented the pseudo code playlist stuffing algorithm that I posted earlier in this thread. Clearly if the CP waits for the current track to end before sending SetNextAVTransportURI then there will obviously anyway be a delay. The CP must be proactive in pushing the next track into the renderer's playlist immediately it sees that the current playing track has changed; that gives the renderer the whole duration (more-or-less) of the current playing track to set up for playing the subsequent track.
I just tried PP with both MC and the WDTVLive (which claims in it's service XML for AVTransport that it supports NextAVTransportURI).
PP doesn't send SetNextAVTransporURI in either case.
I assume that PP doesn't really support SetNextAVTransporURI or not the way I'm trying to do it.
What I do is to select the WDTVLive as my renderer in PP devices, my MC library as the server and browse to an album I have of a classical MP3 album with short gapless tracks, I use PP's select to select the whole album to a playlist and start playing it. Observing the wireshark trace, PP is only using SetAVTransportURI for feeding the tracks to the WDTV and I get the expected long gaps between tracks.
MC is much better as a renderer in this situation only giving short gaps between tracks, however PP is still not using SetNextAVTransportURI to send the subsequent tracks...
-
Let's hope someone bites the bullet and tries adding SetNextAVtransportURI to their control point so that we can get definitive evidence if it works or not :-)
Who knows, maybe I will try it myself one day (but only in a month or two) ...
-
Just an update here:
- MC v17 now supports this, both on its Control Point and on its renderer
- Whitebear v2.3 now supports it on its renderers too
You can get Whitebear v2.3 here http://www.whitebear.ch/mediaserver.htm (http://www.whitebear.ch/mediaserver.htm)
-
JRiver and AndrewFG,
I greatly appreciate you all adding this functionality to your software. Awesome. (One day) This will be great.
For now, who has suggestions on how to get the major electronics manufacturers to update their firmware. I have a recent Denon box. Tried it as soon as MC made the improvements, but no luck. The receiver is not connnecting with the new DLNA commands from MC yet. Any ideas how to effectively pursuade Denon and others?
Once again, greatly appreciate the improvements !!
Steve
-
For now, who has suggestions on how to get the major electronics manufacturers to update their firmware.
I guess three things:
- Lobby the UPnP organisation http://www.upnp.org (http://www.upnp.org)
- Lobby the DLNA organisation http://www.dlna.org (http://www.dlna.org)
- Lobby your product manufacturer
-
This worked great all day yesterday (latest WB / MC).
-
Hello,
[not sure if this is the correct thread to post this in, Mods please feel free to move it, naturally]
My set up includes (currently Win7-based) XBMC as a renderer and the latest MC on a laptop used as a controller. While it roughly works, I have always had issues with gaps between tracks. I discussed this a while ago here http://yabb.jriver.com/interact/index.php?topic=61688.0 (http://yabb.jriver.com/interact/index.php?topic=61688.0), and even though the delay between tracks is much better, it can still take a second or two. I am not sure which side the problem lies on and I have tried to get the XBMC community to look at it, but to no avail.
I was hoping that with SetNextAvTransportURI implemented and XBMC apparently supporting this function, gapless playback would be possible. This doesn't seem to be the case. Has anyone (MC devs or users) tested this setup? In fact, the 'Next' field displayed by XBMC is empty.
I have tried with both XBMC 10.1 Dharma and 11 beta 2,3, controlled by the last half a dozen builds of MC (currently 17.0.106).
Any info would be great. I am more than happy to assist by providing logs if that would help. I would love get this working, Dark Side of the Moon with gaps between tracks just doesn't work!
Thanks in advance,
Pawel
-
Hello,
[not sure if this is the correct thread to post this in, Mods please feel free to move it, naturally]
My set up includes (currently Win7-based) XBMC as a renderer and the latest MC on a laptop used as a controller. While it roughly works, I have always had issues with gaps between tracks. I discussed this a while ago here http://yabb.jriver.com/interact/index.php?topic=61688.0 (http://yabb.jriver.com/interact/index.php?topic=61688.0), and even though the delay between tracks is much better, it can still take a second or two. I am not sure which side the problem lies on and I have tried to get the XBMC community to look at it, but to no avail.
I was hoping that with SetNextAvTransportURI implemented and XBMC apparently supporting this function, gapless playback would be possible. This doesn't seem to be the case. Has anyone (MC devs or users) tested this setup? In fact, the 'Next' field displayed by XBMC is empty.
I have tried with both XBMC 10.1 Dharma and 11 beta 2,3, controlled by the last half a dozen builds of MC (currently 17.0.106).
Any info would be great. I am more than happy to assist by providing logs if that would help. I would love get this working, Dark Side of the Moon with gaps between tracks just doesn't work!
Thanks in advance,
Pawel
Hi Pawel,
I just checked and xbmc doesn't support the SetNextAvTransportURI function.
This is pretty easy to check. You just download the upnp tools for developers, then run device spy and expand the AVTransport list.
-
Hi Pawel,
I just checked and xbmc doesn't support the SetNextAvTransportURI function.
bummer.
Thanks bob.
-
bummer.
Thanks bob.
Maybe you can bug them about it and get them to put it on their todo list?
-
That is because none of the existing CPs and very few renderers have implemented SetNextAVTransportURI.
I wonder how you come to that conclusion. I am currently developing an Android-tablet-based CP and have also come across the issue of SetNextAVTransportURI. My intial testbed was XBMC, and it does not implement it. Since then, I have moved to a Sony Sony CMT-G2NiP and a Sony SMP-N200, which both have it. I also have a 2 years old Freecom MusicPal, which also has it, and so does MC. I would consider any renderer implementation without SetNextAVTransportURI non-serious, and turn the device in to the manufacturer. In my CP, using SetNextAVTransportURI is the default approach (actually, I dont even have the other approach implemented yet), and it works well with the CMT-G2NiP, which was my testbed until now. I'm about to get into MC, see how that fares.
regards,
chris
-
I wonder how you come to that conclusion. I am currently developing an Android-tablet-based CP and have also come across the issue of SetNextAVTransportURI. My intial testbed was XBMC, and it does not implement it. Since then, I have moved to a Sony Sony CMT-G2NiP and a Sony SMP-N200, which both have it. I also have a 2 years old Freecom MusicPal, which also has it, and so does MC. I would consider any renderer implementation without SetNextAVTransportURI non-serious, and turn the device in to the manufacturer. In my CP, using SetNextAVTransportURI is the default approach (actually, I dont even have the other approach implemented yet), and it works well with the CMT-G2NiP, which was my testbed until now. I'm about to get into MC, see how that fares.
regards,
chris
I've got a boatload of renderers here and only the Sony Bravia NX8 and Media Player N100 support it and neither does it properly! (they wait too long to request the next file so there is still a small gap). Whitebear with the squeezebox and MC as a renderer are the only ones I have that work properly.
-
I've got a boatload of renderers here and only the Sony Bravia NX8 and Media Player N100 support it and neither does it properly!
interesting! I've been pondering for some time to setup a reference table with UPnP devices and their capabilities/shortcoming/quirks. What about maintaining that here on the MC site, possibly in the Wiki? Do you have experience with Denon and Marantz devices?
-
interesting! I've been pondering for some time to setup a reference table with UPnP devices and their capabilities/shortcoming/quirks. What about maintaining that here on the MC site, possibly in the Wiki? Do you have experience with Denon and Marantz devices?
That would be interesting (the wiki idea) it'd have to be kept current somehow since the DLNA devices often get firmware updates that change their behavior. For example, the Sony Media player we have didn't support renderering at all until a firmware update put in renderer capability (albeit somewhat broken). We got a lot of feedback on a Marantz receiver from a user and got it working well. Haven't heard anything on the Denon devices...
-
I believe that both of the approaches mentioned in this thread are incorrect.
The correct approach to this problem is to be able to supply a continuous stream of data that the renderer can use (usually either LPCM or WAV) using a variety of sources (MP3, WMA, FLAC, etc).
The problem that I can see with this approach is that it may not be possible to deliver track title updates (what does the LPCM stream allow?), so a certain part of the aesthetics would take us back to the days before media tags were common place and that might upset some people. I'm ok with that.
At least from where I sit, this problem space needs a new meta file type as the .M3U file is just too limiting.
A new playlist file format is required that allows
- control over inter track gap
- inclusion of directories rather than just files
- be able to reference files and directories outside of "."
- there are likely other things that could be included that I'm ignorant of
The "inter track gap" could be set to 0 (no gap), a positive number (silence) or a negative number (overlapping of the end/start of audio tracks.)
As for the "clicks" or "pops" at the end of tracks due to rounding during decoding that has been mentioned before, well that sounds like a software problem (i.e. a bug) that needs fixing and not something that is a road block preventing progress.
My goal is to convert n MP3 files into a single LPCM audio stream to my renderer that it then can playback out of its speakers. and the desire is for that LPCM audio stream to be a constant stream of music, not closed and opened with teach track boundary, etc.
-
AFAIK, there would be one ideal solution to the gapless issue that would be covered by the UPnP spec. The spec does allow to send an album URI to the renderer, which would point to one file containing the sound data, while the information about the individual tracks would be sent along in the AVTransportURIMetadata. On disk, that information would be stored in a CUE sheet accompanying the data file (or embedded within). So you could store all your albums as single FLAC image files with accompanying CUE sheets, and server/renderer would exchange the complete album stream while still maintaining the metadata.
Of course, this is just theory. I dont know of any server/renderer out there that does this. They all rely on individual tracks being sent, which is a pity. I have always thought that FLAC images w/ CUE sheets is the natural way of storing music albums..
-
We did implement the SetNextAVTransportURI and it works very well with the devices that support it properly (and we also support it as a renderer). AndrewFG's Whitebear renderer supports it perfectly.
-
I have implemented SetNextAVTransportURI in the next (unreleased) versions of BubbleUPnP and foo_upnp (for use with foobar2000).
For both programs I did the renderer and controller part, using MC as a reference implementation.
BubbleUPnP as a gapless renderer will require Android 4.1+ (as the Android media framework is not capable of gapless in previous versions).
So MC, foobar2000, BubbleUPnP should be intereoperable in all directions regarding gapless.
It has been a bit challenging to implement especially for the control point part, due to having to find a hacky way to detect track changes to issue successive SetNextAVTransportURI commands.
What I did is abusing GetPositionInfo().TrackURI to detect track changes as explained in one of the previous post.
No wonder noone implemented SetNextAVTransportURI as it is totally underspecified and guess work. There is almost 0 chance a random
Control Point SetNextAVTransportURI implementation work against a random Renderer SetNextAVTransportURI implementation without testing it.
For the Control Point to consider gapless control, the renderer must have action SetNextAVTransportURI.
But I consider this is not sufficient to enable gapless control and for now I use a white-list of renderers "known to work".
What renderers are known to work with MC implementation, besides WhiteBear, and a way to identify them (model name, model description, ...) ?
-
Hi bubbleguum,
I am delighted that you have been "motivated" to address the challenge of gapless playback :-)
It has been a bit challenging to implement especially for the control point part, due to having to find a hacky way to detect track changes to issue successive SetNextAVTransportURI commands.
What I did is abusing GetPositionInfo().TrackURI to detect track changes as explained in one of the previous post.
Strictly speaking GetPositionInfo().TrackURI is NOT the right solution. UPnP has two types of URI, namely "media URI" and "track URI". A media URI refers to a container having one or more tracks in it, and a track URI refers to any one such track within the media container. If the media URI is the URI of a single music track (e.g. http://something.mp3) then the media and track URIs are deemed identical (i.e. the media container contains just one track). HOWEVER if the media URI is the URI of a playlist (e.g. http://something.m3u) then the media and track URIs are NOT identical; rather the track URI would be the URI of one of the music tracks within the m3u playlist.
The current and next media URI (called AVTransportUri & NextAvTransportUri) are written by the property setter actions SetAVTransportUri & SetNextAVTransportUri, and they are read by the property getter action GetMediaInfo. The track URI is read by the getter action GetPositionInfo; the track URI has no setter action.
In your case, you are setting single track URIs via SetAVTransportUri & SetNextAVTransportUri, and -- in this special case -- GetPositionInfo will return the same URI as GetMediaInfo. However in the general case you cannot rely on GetPositionInfo and GetMediaInfo returning the same URIs.
For example if you set a playlist containing (say) 3 tracks via SetAVTransportUri, and another playlist also containing (say) 3 tracks via SetNextAvTransportUri, then the player will play those six tracks in sequence (and BTW nominally gaplesslessly). GetPositionInfo.TrackUri will transition through six consecutive URIs (corresponding to each of the six tracks), whereas GetMediaInfo will transition through only two URIs (corresponding to the URIs set by SetAvTransportUri & SetNextAvTransportUri).
If you use the GetPositionInfo.TrackUri transition to trigger sending the next SetNextAvTransportUri, you will in general not be playing the playlists that the user had intended. Instead you should use GetMediaInfo transitions to trigger sending the next SetNextAvTransportUri (either check if GetMediaInfo.CurrentTrackUri has transitioned to what you had set with SetNextAvTransportUri, or check if GetMediaInfo.NextTrackUri has transitioned to a now empty value).
If you insist on using GetPositionInfo.TrackUri then you must explicitly check the actual value of TrackUri and determine if the track is WITHIN one of the playlists (in which case don't trigger the next SetNext) or if it represents the specific transition from the last track in the first playlist to the first track in the second playlist (in which case DO trigger the next SetNext)...
Note that when the renderer does NOT support SetNext, you must also follow a similar logic to decide when to send the next SetAvTransportUri i.e. you should only send the next SetAvTransportUri when GetMediaInfo.CurrentUri transitions to an empty value, (or when GetPositionInfo.TrackUri transitions to an empty value), or when the player state transitions to STOPPED (the latter is perhaps the easiest choice in this case).
For the Control Point to consider gapless control, the renderer must have action SetNextAVTransportURI.
As you can see from the above, this statement is not 100% true. If you use only SetAVTransportURI and pass playlists, then all transitions WITHIN playlists can (depending on the renderer) be played gaplessly. But all transitions BETWEEN playlists will necessarily have a gap.
-
I have implemented SetNextAVTransportURI in the next (unreleased) versions of BubbleUPnP and foo_upnp (for use with foobar2000).
For both programs I did the renderer and controller part, using MC as a reference implementation.
BubbleUPnP as a gapless renderer will require Android 4.1+ (as the Android media framework is not capable of gapless in previous versions).
So MC, foobar2000, BubbleUPnP should be intereoperable in all directions regarding gapless.
It has been a bit challenging to implement especially for the control point part, due to having to find a hacky way to detect track changes to issue successive SetNextAVTransportURI commands.
What I did is abusing GetPositionInfo().TrackURI to detect track changes as explained in one of the previous post.
No wonder noone implemented SetNextAVTransportURI as it is totally underspecified and guess work. There is almost 0 chance a random
Control Point SetNextAVTransportURI implementation work against a random Renderer SetNextAVTransportURI implementation without testing it.
For the Control Point to consider gapless control, the renderer must have action SetNextAVTransportURI.
But I consider this is not sufficient to enable gapless control and for now I use a white-list of renderers "known to work".
What renderers are known to work with MC implementation, besides WhiteBear, and a way to identify them (model name, model description, ...) ?
We've got a Sony Bravia TV and Sony Media player which both work with MC. They are not transitioning gaplessly though the gap is much reduced. I'm pretty sure they are not holding the audio device open between tracks. The Bravia worked as expected, just like Whitebear. The Media Player had a bug that needed to be worked around (I'd have to go back and look to find it, can't remember all of the renderer bugs) ;)
-
Hi bubbleguum,
I am delighted that you have been "motivated" to address the challenge of gapless playback :-)
I've been motivated mostly to bring gapless to my Android renderer (on 4.1+). And even, I discovered later that the Android media framework is gapless only
for FLAC, OGG and WAV (there are very small gaps with MP3 and AAC).
Thanks for the nice explanation on how playlist URI are working. None of my control points and renderers supports .m3u URI though.
So I'll keep using the GetPositionInfo.TrackURI method which works reasonably well for that special case.
-
We've got a Sony Bravia TV and Sony Media player which both work with MC. They are not transitioning gaplessly though the gap is much reduced. I'm pretty sure they are not holding the audio device open between tracks. The Bravia worked as expected, just like Whitebear. The Media Player had a bug that needed to be worked around (I'd have to go back and look to find it, can't remember all of the renderer bugs) ;)
Ok, but if it has small gaps it is not gapless in my book :p.
-
Ok, but if it has small gaps it is not gapless in my book :p.
Too true!
Both of them are firmware updatable though and if Sony uses the same base firmware across all of their TV's there is some hope they could fix it for tons of renderers all at once :)
-
Actually, if you only want to do that, there is an already existing, tried and tested solution: When you call SetAvTransportURI, instead of passing the url of a single track, you just pass the url of a .pls or .m3u playlist file. The renderer downloads the playlist file and works through the playlist accordingly. Obviously in this scenario, you can't actually exit the CP, because it is also your server, so you need it running so the renderer can get the tracks. Also it is a bit of a munge because there is no mechanism for passing track meta data.
What about the case where your CP is not your server?
-
What about the case where your CP is not your server?
Actually I was wrong. The CP could indeed push an .m3u or .pls playlist to the renderer via SetAVTransportUri, and if the playlist contained only urls that are not on the CP machine, then the CP machine could safely go offline and the renderer could still GET those playlist tracks from whatever server they are on..