http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #16 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Reproduction and measurements, in case they are useful. Where it goes wrong: OpenFile() in dlls/amstream/multimedia.c asks the source filter's pin enumerator for exactly one pin -- IEnumPins_Next(EnumPins, 1, &ipin, NULL) -- and renders that one. A source filter which parses the container itself exposes one output pin per elementary stream, so every pin after the first is left unconnected. Real application: Sacred Gold plays its cutscenes through amstream. In the quartz trace with the WM ASF reader as the ASF source filter (attachment 81776): - the reader exposes Source:"Raw Video 0" (001D5850) and Source:"Raw Audio 1" (001D5B20); - FilterGraph2_RenderEx is called exactly once, on 001D5850; - "Raw Audio 1" is enumerated and QueryDirection'd, then never rendered. The cutscenes therefore play silently. Attachment 81777 is the same scene after forcing File Source (Async.) as the ASF source filter instead: one "Output" pin, the GStreamer splitter connects Stream 00 and Stream 01, RenderEx returns 0, audio is there. That is a registry workaround rather than a fix, but it isolates the cause to the single-pin loop. Reproducing it without the game: a mocked IFilterGraph2 that records RenderEx/Render calls, plus a strmbase filter exposing two output pins, is enough. OpenFile() returns S_OK and only one pin is ever rendered, where two are expected -- so the check needs a todo_wine on current Wine. Still open, the question you asked: whether a pin that fails to connect should fail the whole call. Under AMMSF_RENDERALLSTREAMS I would say arguably yes, but I have not measured that on Windows and nothing covers it. If it is easier to write the change yourself, take any of this -- and I am happy to run whatever measurement you want on this end. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.