locked
Playing short clip in a topology with a tee node and multiple renderers cuts short RRS feed

  • Question

  • I've noticed a weird behavior when using short clips.  I have 2 sample MP3 files: a 1 second and a 3 seconds.

     

    When a build this topology (source->renderer), each clips play fine from beginning to end.

     

    When I add a tee node into the topology (source->teenode->renderers):

    If I use 2 renderers or more on the tee node, the 1 second clip stops slightly short of the end.

    If I use 1-3 renderers on the tee node, the 3 seconds clip plays until the end.

    If I use 4 renderers or more on the tee node, the 3 seconds clip stops playing after 1 second.

     

    No problem is exhibited with both samples if there is only one renderer on the tee node.

    No problem is exhibited with both samples if I have a 10 seconds or more clip.

     

    All this was reproduce using a modified example from the SDK.

    Thursday, June 14, 2007 8:33 PM

Answers

  • I would expect there to be a certain element of non-determinism here, since it would be highly timing-dependent.  Which means that it might act differently for different content.

     

    And since you're using audio renderers, I should mention another known issue where the last chunk of audio sent to the audio renderers can get cut off (it has to do with the MF audio renderer sending back the MEStreamSinkMarker before that last chunk actually finishes playing).  How much gets cut off, therefore, depends on how big that final chunk of audio happened to be.  It could be shorter for your long content than for your short content.

     

    At any rate, since you seem to know what you're talking about :-), I will try to investigate it over here and see if I turn up something other than my original theory...

    Monday, June 25, 2007 11:37 PM

All replies

  • We do have a known issue wherein if you have a Tee to sink1 and sink2, and sink1 consumes data more quickly than sink2, then the Media Session will end the clip shortly after sink1 finishes it, when in fact it should be waiting for both sinks to receive and play all the data. 

     

    Perhaps this is what's causing it?  I'm completely speculating here.  This would be a plausible explanation if there's any difference in how quickly your sinks are pulling data from one another.

    Tuesday, June 19, 2007 7:27 PM
  • It looks similar but not quite.  BTW, I am the one who posted about the situation originally:

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=818019&SiteID=1

     

    But, in this case, I think it is different.  All my sinks are the same i.e. audio renderers.  Also, the behavior changes depending on the length of the source which does not seem to indicate the same problem.  If my audio clip is longer than x number of seconds, the clip plays until the end.

    Thursday, June 21, 2007 9:24 PM
  • I would expect there to be a certain element of non-determinism here, since it would be highly timing-dependent.  Which means that it might act differently for different content.

     

    And since you're using audio renderers, I should mention another known issue where the last chunk of audio sent to the audio renderers can get cut off (it has to do with the MF audio renderer sending back the MEStreamSinkMarker before that last chunk actually finishes playing).  How much gets cut off, therefore, depends on how big that final chunk of audio happened to be.  It could be shorter for your long content than for your short content.

     

    At any rate, since you seem to know what you're talking about :-), I will try to investigate it over here and see if I turn up something other than my original theory...

    Monday, June 25, 2007 11:37 PM