Reply to thread

Message

<blockquote data-quote="tourettes" data-source="post: 653564" data-attributes="member: 10858">No, it wouldn't be easy <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /><ul>
<li data-xf-list-type="ul"> Renderer cannot handle dynamic (internal) renderer type changes (between WASAPI / directshow). It would require</li>
<li data-xf-list-type="ul"> Currently the input pin is implemented by the filter itself, it would require quite much work to separate that to a different class</li>
<li data-xf-list-type="ul"> It would slow down the automatic directshow graph building when there are two pins around</li>
</ul>One possibility would be to introduce property page(s) for the filter (where all registry settings are) - but it will still require the dynamic settings to be handled (changing some settings on the fly aren't even possible without completely restarting the playback, so the effort for this would be quite big). Since the audio renderer's target is to be used in MP the settings configuration is quite much useless for the real use. After all the filter needs to be in such shape when it is used within MP that there is no need for the setting changes. It must just work.At current state, please consider that you donate some development time every time you change a setting in the registry and reload the graph in GraphStudio <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" /></blockquote>

[QUOTE="tourettes, post: 653564, member: 10858"] No, it wouldn't be easy :) [list] [*] Renderer cannot handle dynamic (internal) renderer type changes (between WASAPI / directshow). It would require [*] Currently the input pin is implemented by the filter itself, it would require quite much work to separate that to a different class [*] It would slow down the automatic directshow graph building when there are two pins around [/list] One possibility would be to introduce property page(s) for the filter (where all registry settings are) - but it will still require the dynamic settings to be handled (changing some settings on the fly aren't even possible without completely restarting the playback, so the effort for this would be quite big). Since the audio renderer's target is to be used in MP the settings configuration is quite much useless for the real use. After all the filter needs to be in such shape when it is used within MP that there is no need for the setting changes. It must just work. At current state, please consider that you donate some development time every time you change a setting in the registry and reload the graph in GraphStudio :D [/QUOTE]

Verification