Mixing rate sink and rateless sink on a tee node

I modified the WavSinkSample and inserted a tee node so I could also add an Audio Renderer output node. When I do this, the topology starts playing just fine. But it ends as soon as the WavSink finishes writing the wave file.

Is this the intended behavior I would have expected the topology to stop when all output nodes are done processing samples. I tried a bunch of workarounds:
- Changing the order in which I connect the nodes.
- Set MF_TOPONODE_RATELESS to 0 on the WavSink output node.
- Set MF_TOPONODE_PRIMARYOUTPUT to 0 (index of the audio renderer) on the tee node.
- Set MF_TOPONODE_DISCARDABLE on the tee node for all secondary node.

But none of these worked. Is there any ways to accomplish when I want or is this a bug

Also, I tried to "slow down" the wave file writing by putting a Sleep(1000) when processing the sample. When I do that, the topology does play for longer. But it also glitches significantly. What intrigues me if that somehow the 2 sinks run at different speed which is why the topology stops as soon as the file is finished writing. But on the other hand, the audio renderer sink is being affected by the custom wav sink. It's also troubling knowing that the WavSinkSample uses the work queue.

BTW, I'm running RC2 (5744).

Thanks!

Marc

Answer this question

Mixing rate sink and rateless sink on a tee node

Jakein2006
I traced and put debug info and all the calls to ProcessSamplesFromQueue are coming from the callback (CAsyncCallback::Invoke -> CWavStream::OnDispatchWorkItem -> CWavStream::DispatchProcessSample -> CWavStream->ProcessSampleFromQueue.

If you want, I can send you the modified example to illustrate it.

Any other ideas Otherwise, that looks like a bug to me.

Marc
Blkbird

I suppose I ought to mention _why_ setting the output to be DISCARDABLE will work around your EndOfStream problem...

It doesn't really solve it, but it does keep the two sinks receiving samples more or less in line with one another, since your fast sink output's branch will be receiving samples off the Tee about when the SAR output's branch does, rather than speeding ahead like you're seeing now. Therefore, the MEEndOfStream event won't be "jumping the queue" for the SAR output branch like it is for you right now.
Annihil8

Nope, if you allocate your own work queue (MFAllocateWorkQueue) like the wavsinksample does, it will be associated with its own thread, and your workitem callback will occur on that thread. No need to do your own thread stuff. So whatever you're doing on that thread shouldn't affect the MF threads that are delivering samples.

And the fact that your custom sink is "slow" shouldn't hold up the pipeline. Of course, as we've discussed above, it will have that problem where it gets cut off the instant the SAR node reaches the end.

So the only explanation I can think of for your glitching is the fact that -- at least in the wavsink sample -- there are a couple places where ProcessSamplesFromQueue (which calls WriteSampleToFile) is actually called in the context of the calling thread. Like I'm seeing that Flush() does this...
Allan Huang
Yes, marking the custom-fast-sink output as DISCARDABLE worked. Thanks!

I've also entered the bug on the connect site:

https://connect.microsoft.com/windows/feedback/ViewFeedback.aspx FeedbackID=229740

Marc
Derek Chan
I do see what you're talking about.

Let's first talk about the issue where you're running a topology with a tee that has an audio renderer (SAR) output and a custom "fast" sink output. I tried this, and I do see the problem you're reporting, where the presentation ends way before the SAR is done with it. The underlying cause of this is that we propagate the MEEndOfStream event through each of the tee nodes' outputs regardless of whether there are any samples waiting to be propagated through that output; in your case, of course, there are many samples waiting there to be propagated to the SAR. That seems to be a bug.

There is a workaround, though: Try marking your custom-fast-sink output as DISCARDABLE. You mentioned you tried this to no avail, but make sure you're doing it right. Assuming your tee has output 0 going to your custom fast sink and output 1 going to the SAR, you should be doing something like this:

UINT32 unDiscardableOutput = 0;

pTeeNode->SetBlob( MF_TOPONODE_DISCARDABLE, (BYTE *) &unDiscaradableOutput, sizeof( unDiscardableOutput ) );

Note that this attribute goes on the tee node, not your output node.

Now if you do this, it means two things:
1. Any MEStreamSinkSampleRequest requests made by your custom sink will be ignored. Instead, the pipeline will be driven completely by requests made by the SAR, and your sink's branch of the topology will get whatever comes out of that.
2. Conversely, if your sink is slow to request more samples, instead of building up a queue of samples that waits at that output of the tee node like we usually do, we will keep dropping those samples, and when your sink does get around to requesting a sample, it'll get whatever was last made available. This means that if your sink is a discardable output, it should expect to miss samples every now and then.
As for the glitching, it's most likely unrelated... My best guess is that your custom sink is doing its slow processing on the same thread as its ProcessSample call. Since by default this is the same thread that services the SAR node, tying it up for long periods of time would probably cause glitches. Instead, see if you can do any lengthy processing on another thread; you can use the MF work queues (MFPutWorkItem) if you want. The simple fact that the custom sink is taking a long time to request its next sample will not in and of itself tie up the pipeline.

Try the above and let me know how it works for you...
Ronaldlee Ejalu
Absolutely. But I fear finding some last minute bugs that would not be fixable for the RTM. I dont know if you are at leasure to discuss this but realistically and without holding you to it, until when can we expect reporting bugs with chances of being fixed That might help me prioritize my work.

Also, what your take on the glitching I am hearing when my custom sink takes some time to process the sample Is that normal If I understand you correctly, 2 sinks should be allowed to consume samples at different rates and should not affect each other. Otherwise, I'll have to implement another buffering mecanism on top of the work queue.

Marc
sajohnstone
Thanks, I'll try the above and let you know.

Regarding the glitching, I have not tried to do the processing on another thread. But the example I use DOES use the MF Work Queue. You can just use the wavsink example and insert a sleep in the WriteSampleToFile(IMFSample *pSample) method to see the effect.

Can you please clarify, Do I also have to spawn a thread on top of it when I am using the work queue I tought I would only need to do the processing in another thread if I did not use the work queue.

Marc
Ayala24

I really wouldn't have expected that to happen -- generally, the topology will play until all sinks have signaled that they are done. In your case, the audio renderer would play the stream in real time and only when it's done would the topology end. If there aren't any other problems in how you set this up, etc, this sounds like a bug. Give me a couple days to try this out myself, OK
Mixing rate sink and rateless sink on a tee node

Answer this question