{"id":1511,"date":"2014-04-20T11:45:12","date_gmt":"2014-04-20T09:45:12","guid":{"rendered":"https:\/\/alax.info\/blog\/?p=1511"},"modified":"2014-04-20T11:54:13","modified_gmt":"2014-04-20T09:54:13","slug":"audio-playback-at-non-standard-rates-in-directshow","status":"publish","type":"post","link":"https:\/\/alax.info\/blog\/1511","title":{"rendered":"Audio playback at non-standard rates in DirectShow"},"content":{"rendered":"
\n

DirectShow streaming and playback in particular offers flexible playback rates for scenarios where playback is requested to take place slower or faster than real time. For a DirectShow developer, the outer interface is pretty straightforward:IMediaPosition::put_Rate<\/code><\/a>\u00c2\u00a0<\/span>takes playback rate and that’s it.<\/p>\n

\n

Playback rate. Must not be zero.<\/p>\n

The playback rate is expressed as a ratio of the normal speed. Thus, 1.0 is normal playback speed, 0.5 is half speed, and 2.0 is twice speed. For audio streams, changing the rate also changes the pitch.<\/p>\n<\/blockquote>\n

Even after taking out the case of reverse playback, which is\u00c2\u00a0<\/span>not supported<\/a>\u00c2\u00a0<\/span>out of the box and requires some DirectShow magic to implement, there is a nasty problem from those who want to be able to change playback rate flexibly on the go.<\/p>\n

\n

Rates greater than one are faster than normal. Rates between zero and one are slower than normal. Negative rates are defined as backward playback, but in practice most filters do not support it. Currently none of the standard DirectShow filters support reverse playback.<\/p>\n<\/blockquote>\n

The problem comes up when an audio-enabled file\/stream is being played back and there is an audio renderer in the pipeline. The filter graph would connect and play excellently, but once you try to change playback rate too much, the request might fail unexpectedly with\u00c2\u00a0<\/span>0x8004025C<\/code>\u00c2\u00a0<\/span>VFW_E_UNSUPPORTED_AUDIO<\/code>\u00c2\u00a0<\/span>“Cannot play back the audio stream: the audio format is not supported.” error.<\/p>\n

An application that “almost does everything right” is unable to do a small thing as simple as fast forward playback!<\/p>\n

The root of the problem is in audio renderer. Requests to change playback rate propagate through filter graphs through IMediaSeeking<\/code>\u00c2\u00a0<\/span>interface and Filter Graph Manager sends the new rates through renderers upstream. Audio renderer rejects to accept the rates it does not support and this breaks the whole thing.<\/p>\n

Earlier implementations had [supposedly?\u00c2\u00a0<\/span>“But I cannot call SetRate with more than 2, it returns VFW_E_UNSUPPORTED_AUDIO<\/code>.”<\/a>] a limit of 50%..200% rate range, and since Vista the actual range is somewhat relaxed. Having no documentation reference, my educated guess is that actual playback rate limit is defined by ability of the renderer to resample the data into format accepted by underlying device. That is, a device taking up to 192 kHz audio could be used to play 44.1 kHz content at rates up to 435%.<\/p>\n

The nasty part of the problem is that even though one might want to mute the audio part at such rates, or exclude audio substream at all, this is only possible with transition through stopped state (due to supposed changes in filter graph topology) and otherwise audio renderer blocks rate changing with the mentioned error code.<\/p>\n

So, is there any way\u00c2\u00a0<\/span>to fix\u00c2\u00a0<\/a>VFW_E_UNSUPPORTED_AUDIO<\/code><\/a> issue?<\/a>\u00c2\u00a0<\/span>with reuse of existing components and smooth user experience on the UI side? One of the approaches is to customize the behavior of standard audio renderer,\u00c2\u00a0<\/span>DirectSound Renderer Filter<\/a>.<\/p>\n

Filter Graph Manager would use its\u00c2\u00a0<\/span>IMediaSeeking<\/code>\/IMediaPosition<\/code>\u00c2\u00a0<\/span>interfaces directly, so the filter cannot be added into filter graph as is. Fhe following is the checklist for required updates:<\/p>\n