home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
HTPC Projects
Software
Operating System
Windows 7 & half fullscreen
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Scythe42" data-source="post: 955047" data-attributes="member: 95833"><p>It's not possible to solve this audio problem during playback without using a custom audio renderer (exception are HDMI switchboxes that always present a connected device even if it is disconnected. But these are pricey. I personally use a DVDO Edge from day one one for these reasons).</p><p> </p><p>But back the what happens inside Windows:</p><p> </p><p>Here's the long story:</p><p> </p><p>A HDMI audio renderer is an external device from an Windows point of view (the receiver is not inside your HTPC).</p><p> </p><p>When you turn off your receiver (or switch inputs) the connection to your HTPC gets separated This triggers a plug and play event that notifies the system of the removal of the HDMI audio renderer (also reference clock and related classes). This is perfectly fine. The device is not connected to the HTMP anymore.</p><p> </p><p>Once it is gone the current DirectShow Graph cannot play any audio anymore as the audio renderer isn't connected anymore. Fine also (bad drivers, like on my system can cause a crash of MP).</p><p> </p><p>But now the sad part: DirectShow is not capable of "re-initalize" an audio renderer on the fly once it is reconnects to the system. Only stopping/starting playback can use the newly connected HDMI audio renderer.</p><p> </p><p>With additional audio renderes (like MPAR) as an abstraction layer, it is possible to disconnect/reconnect an audio renderer as it is not part of the DirectShow graph.</p><p> </p><p>So when MPAR supports re-inits of the final audio-renderer on demand this issue can be solved and playback can continue even if a device is disconnected as MPAR is the receiver of the audio stream inside Direct Show. But as long as you use any of the DirectShow Audio Renderers, you are stuck. This is a limitation of DirectShow and nothing much we can do about it.</p><p> </p><p>MPAR will support re-inits of audio renderers in future.</p><p> </p><p>Only fix I am doing is: current used audio render gone -> stop playback (as audio will never come back).</p><p> </p><p>Reason is that DirectShow was designed before HDMI came up and MS never updated it in regards to this issue as it wants people to move away from DirectShow. Would be fine for us, but the huge number of existing filters (read codecs) is the issue here why we can't move away from it at this point in time.</p><p> </p><p>Testing audio works for you, because when you open the settings app it actually connect to the audio device at this time when it is available again. So this is not related and it never experienced the loss. It would be like restarting MP.</p><p> </p><p>If you have a general problem that once your the HDMI audio device was removed (when depends largely on the receiver) it can NEVER be used for playback again, that might be a different and solvable issue!</p><p> </p><p>But this seems more or less a driver issue. Plug and Play for HDMI devices should work without hickups. But not during playback without an audio renderer that supports plug and play events.</p><p> </p><p>Also if you have sounds enabled in a skin these are affected as well because the sound device is pulled under our feet. This one can be solved but isn't high on our priority list.</p><p> </p><p><strong>Can you provide a few more detail when and how you loose audio and under which circumstances it never comes back?</strong></p><p> </p><p><strong>Also your configuration in regards to audio inside Windows as well as inside MP?</strong></p><p> </p><p>If it is just a matter that the plug and play event doesn't come through to MP, we could force a re-enumeration of audio devices to workaround a potential driver problem on the arrival of audio devices. Basically re-enumerating stuff. But that shouldn't be necessary as we just use a "filter name" stored in the configuration that doesn't change and is used every-time we build a Direct Show Graph.</p></blockquote><p></p>
[QUOTE="Scythe42, post: 955047, member: 95833"] It's not possible to solve this audio problem during playback without using a custom audio renderer (exception are HDMI switchboxes that always present a connected device even if it is disconnected. But these are pricey. I personally use a DVDO Edge from day one one for these reasons). But back the what happens inside Windows: Here's the long story: A HDMI audio renderer is an external device from an Windows point of view (the receiver is not inside your HTPC). When you turn off your receiver (or switch inputs) the connection to your HTPC gets separated This triggers a plug and play event that notifies the system of the removal of the HDMI audio renderer (also reference clock and related classes). This is perfectly fine. The device is not connected to the HTMP anymore. Once it is gone the current DirectShow Graph cannot play any audio anymore as the audio renderer isn't connected anymore. Fine also (bad drivers, like on my system can cause a crash of MP). But now the sad part: DirectShow is not capable of "re-initalize" an audio renderer on the fly once it is reconnects to the system. Only stopping/starting playback can use the newly connected HDMI audio renderer. With additional audio renderes (like MPAR) as an abstraction layer, it is possible to disconnect/reconnect an audio renderer as it is not part of the DirectShow graph. So when MPAR supports re-inits of the final audio-renderer on demand this issue can be solved and playback can continue even if a device is disconnected as MPAR is the receiver of the audio stream inside Direct Show. But as long as you use any of the DirectShow Audio Renderers, you are stuck. This is a limitation of DirectShow and nothing much we can do about it. MPAR will support re-inits of audio renderers in future. Only fix I am doing is: current used audio render gone -> stop playback (as audio will never come back). Reason is that DirectShow was designed before HDMI came up and MS never updated it in regards to this issue as it wants people to move away from DirectShow. Would be fine for us, but the huge number of existing filters (read codecs) is the issue here why we can't move away from it at this point in time. Testing audio works for you, because when you open the settings app it actually connect to the audio device at this time when it is available again. So this is not related and it never experienced the loss. It would be like restarting MP. If you have a general problem that once your the HDMI audio device was removed (when depends largely on the receiver) it can NEVER be used for playback again, that might be a different and solvable issue! But this seems more or less a driver issue. Plug and Play for HDMI devices should work without hickups. But not during playback without an audio renderer that supports plug and play events. Also if you have sounds enabled in a skin these are affected as well because the sound device is pulled under our feet. This one can be solved but isn't high on our priority list. [B]Can you provide a few more detail when and how you loose audio and under which circumstances it never comes back?[/B] [B]Also your configuration in regards to audio inside Windows as well as inside MP?[/B] If it is just a matter that the plug and play event doesn't come through to MP, we could force a re-enumeration of audio devices to workaround a potential driver problem on the arrival of audio devices. Basically re-enumerating stuff. But that shouldn't be necessary as we just use a "filter name" stored in the configuration that doesn't change and is used every-time we build a Direct Show Graph. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
HTPC Projects
Software
Operating System
Windows 7 & half fullscreen
Contact us
RSS
Top
Bottom