Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[john_kane]

I can never get the IPC to appear in playing now.

The WDM driver is selected as Default Audio Device. 

external browser is outputting audio.   Windows is playing happily to driver (I see popping sounds levels in windows playback device).

WDM feature is enabled in MC23 ( or else there would be no MC driver to select from), I get that I've got to unselect "use default" for audio device etc., but what drives the appearance of the IPC input?

What am I missing?

[john_kane]

So this is 64 bit 23.91 on windows 7 x64, and I also tried .94 .

I tried uninstalling and reinstalling the WDM driver by disabling and renabling the feature. 

I had a zoneswitch rule to send iPC to a dlna zone (denon avr).

I start video playing in an external browser, and I see the audio levels driving in WDM driver.  I finally see Ipc show up in MC, and I try to play that.  Video immediately freezes in external browser. Stopping and starting to no avail.  I  cant get playback back until I kill MC service.

Had similar results with spotify external app, after a full reboot of machine and restart,  trying to play audio thru MC.

I tried disabling 'allow apps exclusive use' in audio setup, same thing.

[RoderickGI]

The WDM is an input to MC.

Playing Now shows the outputs from MC.

Your output device in MC should be something other than the WDM/IPC. As you say, you have to select an output in MC other than "Default Audio Device".

Your external Browser plays to the Windows Default Audio Device, which is the WDM Driver, called the "JRiver Media Center 23" in the Windows Playback Devices list.
The WDM Driver sends its output to the JRiver Media Center as an input.
MC plays its output to the Audio Device selected "Options > Audio > Audio Device".
Sounds play.


What was the question again?

[mattkhan]

IPC is the library item that jriver "plays" when it is handling the wdm driver input so it does appear in playing now and is reported as the currently playing item via mcws zone info.

@John_kane are you saying that the wdm driver simply doesn't work at all? It isn't clear.

[john_kane]

@mattkhan

Sorry if its not clear; yes, I am having problems getting it working at all.

Browser is playing to windows default audio, and JRMC23 audio driver is selected in windows as default audio device. This appears to be sourcing the audio into the WDM driver as I see the level bars pulsing in windows playback device for JRMC23.

In MC Audio setup, I have set the device to something other than default (spdif out from sound card).

I also have a zoneswitch to take IPC and send to DLNA zone(Denon AVR).

 If I select IPC to play in playing now (IPC doesn't just start playing on its own), the browser video hangs:no audio, no video.  Nothing brings back the browser unless I kill the MC Service, and the video resumes in the external browser. 

Similar experience with external spotify app which is  audio only (just to rule out the video interaction).

[mattkhan]

If I select IPC to play in playing now (IPC doesn't just start playing on its own)

you do not have to select ipc, it should start up automatically. I suggest trying to get ipc working automatically first so you can see the content playing via dsp studio. You could set the output device to the null device (or a file) in order to rule out any sort of device clash & turn off zoneswitch. Once you have IPC working automatically then add zoneswitch and then the correct output device. If turning off the other bits doesn't get IPC playing then I think posting a log file from MC is the way forward.

[RD James]

Try playing to a local sound device rather than a DLNA device. Get that working first.

[RoderickGI]

IPC is the library item that jriver "plays" when it is handling the wdm driver input so it does appear in playing now and is reported as the currently playing item via mcws zone info.

Oops. My bad. I interpreted the OP as saying it wasn't appearing underneath the Playing Now heading, which is where target devices appear, such as Player, other MC installations, my TV, DLNA Renderers, etc. Yes, the IPC does appear in Playing Now as a stream being played.

So yeah, as above, keep it simple first. Turn off Zoneswitch, then play from a browser to a local Device such as your soundcard S/PDIF (if it connects to something so you can hear sound), and get it working.

Also confirm that sound plays correctly when you play a local video file directly to your Denon AVR.

If all that works, turn on Zoneswitch and start playing with the rules.

[john_kane]

Thanks for the responses, sorry for the delay, took me some time to get back into it. I wanted to make sure I had a handle on how the settings and operation are really supposed to work, and I think you've confirmed that for me.

Those were fair questions from you guys.   I have had such inconsistent results that I have been a bit all over the place.

I can and do stream to the DLNA renderer zone from MC without an issue regularly. But we'll start with just trying to play to the server's primary zone (soundcard). I disabled zoneswitch and took that out of it. I was having issues before zoneswitch addition, but didnt note that.
 
Sometimes I can see IPC connect and get audio through WDM input through MC to soundcard out, sometimes not, off a fresh reboot.

Logfile..there's another obvious thing that did not occur to me.   I have a logifle capture of a case where MC (right off a reboot) is stuck trying to connect to IPC.  I started a  youtube video  in external browser, sound never appeared.  I start up the GUI, and IPC is stuck trying to connect.


This line looks concerning as I see it repeatedly:
0485334: 7104: Sharing Plugins: VSocketReader::Bind: Socket bind failed: Unknown error Socket: 1904 Size: 16 Address: 172.16.0.1 Port: 1900

And thats the MC server.

That said, I saw this many times in the log when IPC was working/playing .I forgot to reset that log ahead of time, and it had been running for quite a while through various things I was trying so the log was convoluted.

This sequence in the fail case shows the fail:

0097703: 4180: Import: JRAnalyzer::AddFile: Start
0097703: 4180: Import: JRAnalyzer::AddFile: Filename: live://ipc?pipe=00000628&streaming=1
0097703: 4180: Reader: CWinINetReader::Open: Start
0097703: 4180: Reader: CWinINetReader::Open: Opening live://ipc?pipe=00000628&streaming=1
0097703: 4952: Reader: CWinINetReader::Thread: Start
0097703: 4952: Reader: CWinINetReader::Thread: url: live://ipc?pipe=00000628&streaming=1
0097703: 4952: Reader: CWinINetReader::Connect: Start
0097703: 4952: Reader: CWinINetReader::Connect: Failed, can't parse URL
0097703: 4952: Reader: CWinINetReader::Connect: Finish (0 ms)
0097703: 4952: Reader: CWinINetReader::Thread: Finish (0 ms)
0097703: 4180: Reader: CWinINetReader::Open: ConnectToURL failed, m_bConnectError=true, URL=live://ipc?pipe=00000628&streaming=1
0097703: 4180: Reader: CWinINetReader::Close: Start
0097703: 4180: Reader: CWinINetReader::Close: Finish (0 ms)

[RoderickGI]

I get those error messages as well, but the WDM/IPC works fine. The full log sequence is:

Code: [Select]

0069484: 2148: Database: CMediaDatabase::AddFile: JRAnalyzer: 0x1a123bd3e40
0069484: 2148: Database: CMediaDatabase::AddFile: Calling JRAnalyzer::Open
0069484: 2148: Import: JRAnalyzer::Open: Start
0069484: 2148: Import: JRAnalyzer::AddFile: Start
0069484: 2148: Import: JRAnalyzer::AddFile: Filename: live://ipc?pipe=000005F0&streaming=1
0069500: 2148: Reader: CWinINetReader::Open: Start
0069500: 2148: Reader: CWinINetReader::Open: Opening live://ipc?pipe=000005F0&streaming=1
0069500: 8772: Reader: CWinINetReader::Thread: Start
0069500: 8772: Reader: CWinINetReader::Thread: url: live://ipc?pipe=000005F0&streaming=1
0069500: 8772: Reader: CWinINetReader::Connect: Start
0069500: 8772: Reader: CWinINetReader::Connect: Failed, can't parse URL
0069500: 8772: Reader: CWinINetReader::Connect: Finish (0 ms)
0069500: 8772: Reader: CWinINetReader::Thread: Finish (0 ms)
0069500: 2148: Reader: CWinINetReader::Open: ConnectToURL failed, m_bConnectError=true, URL=live://ipc?pipe=000005F0&streaming=1
0069500: 2148: Reader: CWinINetReader::Close: Start
0069500: 2148: Reader: CWinINetReader::Close: Finish (0 ms)
0069500: 2148: Reader: CWinINetReader::Open: Finish (0 ms)
0069500: 2148: Reader: CWinINetReader::Open: Start
0069500: 2148: Reader: CWinINetReader::Open: Opening live://ipc?pipe=000005F0&streaming=1
0069500: 4308: Reader: CWinINetReader::Thread: Start
0069500: 4308: Reader: CWinINetReader::Thread: url: live://ipc?pipe=000005F0&streaming=1
0069500: 4308: Reader: CWinINetReader::Connect: Start
0069500: 4308: Reader: CWinINetReader::Connect: Failed, can't parse URL
0069500: 4308: Reader: CWinINetReader::Connect: Finish (0 ms)
0069500: 4308: Reader: CWinINetReader::Thread: Finish (0 ms)
0069500: 2148: Reader: CWinINetReader::Open: ConnectToURL failed, m_bConnectError=true, URL=live://ipc?pipe=000005F0&streaming=1
0069500: 2148: Reader: CWinINetReader::Close: Start
0069500: 2148: Reader: CWinINetReader::Close: Finish (0 ms)
0069500: 2148: Reader: CWinINetReader::Open: Finish (0 ms)
0069500: 2148: Import: JRAnalyzer::AddFile: Start
0069500: 2148: Import: JRAnalyzer::AddFile: Filename: live://ipc?pipe=000005F0&streaming=1
0069500: 2148: Reader: CWinINetReader::Open: Start
0069500: 2148: Reader: CWinINetReader::Open: Opening live://ipc?pipe=000005F0&streaming=1
0069500: 19232: Reader: CWinINetReader::Thread: Start
0069500: 19232: Reader: CWinINetReader::Thread: url: live://ipc?pipe=000005F0&streaming=1
0069500: 19232: Reader: CWinINetReader::Connect: Start
0069500: 19232: Reader: CWinINetReader::Connect: Failed, can't parse URL
0069500: 19232: Reader: CWinINetReader::Connect: Finish (0 ms)
0069500: 19232: Reader: CWinINetReader::Thread: Finish (0 ms)
0069500: 2148: Reader: CWinINetReader::Open: ConnectToURL failed, m_bConnectError=true, URL=live://ipc?pipe=000005F0&streaming=1
0069500: 2148: Reader: CWinINetReader::Close: Start
0069500: 2148: Reader: CWinINetReader::Close: Finish (0 ms)
0069500: 2148: Reader: CWinINetReader::Open: Finish (0 ms)
0069500: 2148: Import: JRAnalyzer::AddFileMJ: Start
0069500: 2148: Import: JRAnalyzer::AddFileMJ: Finish (0 ms)
0069500: 2148: Import: JRAnalyzer::AddFile: Finish (0 ms)
0069500: 2148: Import: JRAnalyzer::AddFile: Finish (16 ms)
0069500: 2148: Import: JRAnalyzer::Open: Finish (16 ms)
0069500: 2148: Database: CMediaDatabase::AddFile: JRAnalyzer::Open returned
0069500: 2148: Database: JRAnalyzerFile::GetImage: Start
0069500: 2148: Database: JRAnalyzerFile::GetImage: Finish (0 ms)
0069515: 19228: Playback: CPlayerZoneDisplayInfoLoadImageThread::Thread: Start
0069515: 19228: Playback: CPlayerZoneDisplayInfoLoadImageThread::Thread: Image: 00000000
0069515: 3256: Playback: CPlayerZone::Play: Start
0069515: 19228: Playback: CPlayerZoneDisplayInfoLoadImageThread::Thread: Finish (0 ms)
0069515: 3256: Playback: CPlayerZoneDisplayInfoUpdateThread::Destructor: Start
0069515: 17672: Playback: CPlayerZoneDisplayInfoUpdateThread::Thread: Finish (35671 ms)
0069531: 3256: Playback: CPlayerZoneDisplayInfoUpdateThread::Destructor: Finish (16 ms)
0069531: 3256: Playback: CPlayerZone::Play: Handling exclusive playback zones
0069531: 3256: Playback: CPlayerZone::Play: Getting actual playback track
0069531: 3256: Playback: CPlayerZone::Play: Processing play for 'live://ipc?pipe=000005F0&streaming=1'
0069531: 3256: Playback: CPlayerZone::Play: Updating internal track info
0069531: 3256: Playback: CPlayerZone::Play: Playing: <XMLFN version="1.0"><Item Name="Filename">live://ipc?pipe=000005F0&amp;streaming=1</Item><Item Name="PlaylistIndex">0</Item><Item Name="AlbumSequentialWithLastTrack">0</Item><Item Name="SampleRate"></Item><Item Name="VolumeReset">1</Item><Item Name="Channels"></Item><Item Name="ErrorFreeMode">1</Item><Item Name="VolumePeakLevels"></Item><Item Name="MediaType">Audio</Item><Item Name="DatabaseKey">28350</Item><Item Name="VolumeTrackMaxSafeGain">-1</Item><Item Name="Bitrate"></Item><Item Name="Bookmark"></Item><Item Name="BitDepth"></Item><Item Name="LengthInPCMBlocks"></Item><Item Name="VolumeLeveling">-10</Item><Item Name="DSP"></Item><Item Name="FileType"></Item><Item Name="UserInterfaceModeChangeEventHandle">000002D0</Item></XMLFN>
0069531: 3256: Playback: CJRPlaybackEngine::Play: Start
0069531: 3256: Playback: CJRPlaybackEngine::Play: Volume protection: 1
0069531: 3256: Playback: CJRPlaybackEngine::Play: Playing: live://ipc?pipe=000005F0&streaming=1
0069531: 3256: Playback: CJRPlaybackEngine::Play: Filetype: ; Type: 1; Can play: 1; Playback object: 0x1a123cf3850
0069531: 3256: Playback: CJRPlaybackEngine::StartPlayFile: Start
0069531: 3256: Playback: CMJPlaybackType::Play: Start
0069531: 3256: Playback: CMJPlayerCore::Play: Start
0069531: 3256: Playback: CMJPlayerCore::Play: Created feeder helper for type  (native: 1)
0069531: 3256: Playback: CLiveWaveFeeder::Play: Start
0069531: 3256: Playback: CAudioLivePluginLoader::Load: Start
0069531: 3256: Playback: CAudioLivePluginLoader::Load: Loading: ipc
0069531: 3256: Playback: CAudioLivePluginLoader::Unload: Start
0069531: 3256: Playback: CAudioLivePluginLoader::Unload: Deleting plugin
0069531: 3256: Playback: CAudioLivePluginLoader::Unload: Unloading DLL
0069531: 3256: Playback: CAudioLivePluginLoader::Unload: Finish (0 ms)
0069547: 3256: Playback: CAudioLivePluginLoader::Load: Finish (result: 1) (16 ms)
0069547: 3256: Playback: CLiveWaveFeeder::Play: Finish (16 ms)
0069547: 3256: Playback: CMJPlayerCore::Play: Play succeeded
0069547: 3256: Playback: CMJPlayerCore::Play: Result: 1
0069547: 3256: Playback: CMJPlayerCore::Play: Finish (16 ms)
0069547: 3256: Playback: CMJPlaybackType::Play: Play result: 1
0069547: 3256: Playback: CMJPlaybackType::Play: Finish (16 ms)
0069547: 3256: Playback: CJRPlaybackEngine::StartPlayFile: Play returned: 1
0069547: 3256: Playback: CJRPlaybackEngine::StartPlayFile: Finish (16 ms)
0069547: 3256: Playback: CJRPlaybackEngine::Play: StartPlayFile returned 1
0069547: 3256: Playback: CDisplayPlugin::LoadPlugin: Start
0069547: 3256: Playback: CDisplayPlugin::LoadPlugin: Plugin: Visualizations
The important line I guess is:
0069531: 3256: Playback: CJRPlaybackEngine::Play: Playing: live://ipc?pipe=000005F0&streaming=1

I had to let YouTube play via the WDM for at least 30 seconds in order to get that log, otherwise MC didn't seem to finish reporting the connection and playback. See if you can produce a similar log, and see what happens during the playback part of the log. See bolded highlight above.

If you get similar results in your log, take a look at your Volume settings. Make sure Volume Protection isn't just turning the volume right down, or something like that. Note that the Windows Volume Slider of the WDM has no effect when using Internal Volume, unless it is set to zero, in which case sound output is muted.

Note that when I stop playback in MC with a YouTube video playing to the WDM, the sound is muted, but within about 5 seconds the IPC sound is reinstated. So the WDM is pretty robust.


PS: I use Notepad++ to view logs as it is much better for finding things within large files, highlighting all instances, and so on. Worth a look. No affiliation.

[john_kane]

Roderick,

I had a long (2 hr) youtube playing during that capture, so it wasnt really an issue of waiting for it.   FYI, the issue isn't isoloated to youtube either, I have had same results with other sources.

In the MC view, the top title was stuck on "opening IPC..." if my memory serves; no level bars in MC as it never gets that far. I dont think it was volume protection muting.

Note that when I stop playback in MC with a YouTube video playing to the WDM, the sound is muted, but within about 5 seconds the IPC sound is reinstated. So the WDM is pretty robust.

I would really like that to be true here, but I'm not so fortunate.    For the success case that I mentioned, when I closed MC GUI, the video froze solid.  After that, the only way to recover the video playback is to kill jrmc service, and then playback restarts. Similar experience with audio only source (I think).

thats interesting as it seems like the external browser is blocked, so it seems like wdm is blocking here.

I dont have have a good log capture of above, I'll  try to get one. The Last two days has been more 'can't start' cases when I have had a chance to debug.

[john_kane]

Confirmed for the fail  that playing now shows   "IPC Open..."     and a slow pulsing asterisk/star under the JRMS play/stop graphic.

Interestingly, it never gets to  ipc live play start in log, but I see alot of this:

Code: [Select]


858068: 1224: General: JRWebWnd::OnTerminate: Start
0858068: 1224: General: JRWebWnd::OnTerminate: Sending destroy command
0858068: 1224: General: JRWebWnd::OnTerminate: Stopping process
0306386: 3424: General: JRWebApp::Destroy: Start
0306386: 3424: General: JRWebApp::Destroy: Finish (0 ms)
0306402: 3424: General: JRWebApp::Run: Finish (306324 ms)
0306402: 3424: General: JRWebApp::ExitInstance: Start
0306402: 3424: General: JRWebApp::ExitInstance: Stopping web engine
0306418: 3424: General: JRWebApp::ExitInstance: Stopping callback server
0306418: 3424: General: JRWebApp::ExitInstance: Stopping interface server
0306418: 3424: General: JRIpcServerThreaded::ServerStop: Start
0306418: 3424: General: JRIpcServerThreaded::ServerStop: Canceling thread
0306418: 3424: General: JRIpcServerThreaded::ServerStop: Canceling pending run
0306418: 3424: General: JRIpcServerThreaded::ServerStop: Stopping thread
0306418: 6352: General: JRIpcServerThreaded::Thread: Thread finishing (cancel: 1; errors: 1)
0306418: 6352: General: JRIpcServerThreaded::Thread: Finish (306340 ms)
0306449: 3424: General: JRIpcServerThreaded::ServerStop: Canceling response threads
0306449: 3424: General: JRIpcServerThreaded::ServerStop: Deleting response threads
0306449: 3424: General: JRIpcServerThreaded::ServerStop: Closing notification window
0306449: 3424: General: JRIpcServerThreaded::ServerStop: Finish (31 ms)
0306449: 3424: General: JRWebApp::ExitInstance: Finishing
0858131: 1224: General: JRWebWnd::OnTerminate: Closing callback server
0858131: 1224: General: JRIpcServerThreaded::ServerStop: Start
0858131: 1224: General: JRIpcServerThreaded::ServerStop: Canceling thread
0858131: 1224: General: JRIpcServerThreaded::ServerStop: Canceling pending run
0858131: 1224: General: JRIpcServerThreaded::ServerStop: Stopping thread
0858131: 6712: General: JRIpcServerThreaded::Thread: Thread finishing (cancel: 1; errors: 1)
0858131: 6712: General: JRIpcServerThreaded::Thread: Finish (306542 ms)
0858146: 1224: General: JRIpcServerThreaded::ServerStop: Canceling response threads
0858146: 1224: General: JRIpcServerThreaded::ServerStop: Deleting response threads
0858146: 1224: General: JRIpcServerThreaded::ServerStop: Closing notification window
0858146: 1224: General: JRIpcServerThreaded::ServerStop: Finish (15 ms)
0858146: 1224: General: JRWebWnd::OnTerminate: Closing window
0858146: 1224: General: JRWebWnd::OnTerminate: Finish (78 ms)
0860143: 1224: General: CMainUIWnd::SetMCView: Start
0860143: 1224: General: CMainUIWnd::SetMCView: View info name: Player
0860143: 1224: General: CMainUIWnd::SetMCView: Hiding old view




[RoderickGI]

I'm just using YouTube as a convenient external source. Mostly I only use the WDM for browser sourced audio, but other sources work the same, unless they are sending unusual audio formats, like Tidal with MQA Master Audio.

For the success case that I mentioned, when I closed MC GUI, the video froze solid.

When you say "closed the GUI", do you mean minimised, or completely shut down?

For the WDM Driver to work either the MC GUI or Media Server or both must be running, as it is MC that is processing the audio.

So, there are a few options here:
1. You could set MC and/or Media Server to start running with Windows. "Options > Startup >Windows Startup > Run on Windows startup" set to "Media Center", "Media Server", or "Media Center and Media Server"
2. You could just start the Media Server when you wanted to use the WDM Driver. Main menu in the GUI > Tools > Advanced Tools > Media Server".
3. You could just minimise Media Center when you are playing an external source, and optionally have MC minimise to the System Tray. "Options > General > Interface > Minimise to System Tray"

I have never seen the video lock up no matter what I do to MC when playing via the WDM. I just tested some more:

1. MC running without Media Server. Start YouTube video. Close MC completely. Sound disappears. Restart MC GUI. Sound restarts about 5 seconds later. Very robust.
2. MC running with Media Server. Start YouTube video. Close MC completely. Sound disappears for about 4 seconds, then restarts. Restart MC GUI, sound continues without a glitch, with the visual display of audio in MC in sync. Close Media Server, leaving MC running. Sound continues without a glitch. Couldn't be more robust.
3. MC running without Media Server. Start YouTube video. Minimise MC with "Minimise to System Tray" set. Sound continues without a glitch. Maximise MC. The same result, as expected.

This was all on my Workstation, which is a simple PC with a motherboard based Realtek soundcard, and just a couple of speakers. But it is a fair test of the WDM Driver itself.

What browser are you using? I am using Google Chrome. I just tried 1. above in Internet Explorer. It took 10 seconds for the sound to return. The video kept playing no problem. Microsoft Edge took 8 seconds for the audio to start again.
Windows Media Player playing music; 8 seconds for audio to restart. Playing video, 10 seconds to restart audio, with some minor pausing when MC was restarted, but no lockup and video kept playing when MC was closed.
VLC and DivX video player, 5 seconds to restart. No video glitches.
Only the free version of Zoom Player gave me any issues with audio in video playback. But then I couldn't just select the Windows Default audio device in that. It works more like MC in audio device management, selecting the device directly.


So what is different about what you are doing, or your system?

[john_kane]

Roderick,

To address your questions on a win7x64 system, with realtek onboard audio.

1)  I am already setup to Start MC Server on bootup. MC Server is always running. 
2) I am using firefox browser in my tests, but I replicated experience in IE explorer and external spotify app.
3) MC audio setup is set to the onboard audio (realtek) digital audio output (spdif).  There are options for SPDIF(WASAPI) and SPDIF(Direct Sound) in MC options.  I believe I have tried both.
4)MC Driver is to default device in windows

For the cases above,  the procedure was:
1) boot up machine.. (verified) MC service is running
2) start firefox, start a long youtube video.  Video is playing browser.  there is no audio.  I see levels thrashing on windows playback device MC(WDM driver), but not on the digital audio output(SPDIF) playback device (windows audio mixer)

So, audio should have just started playing here, but it doesn't.

3) I fire up Media Center GUI, and I see  "IPC:  Starting...." in window, and pulsing asterisk.

Additional log snippet from my last post above is what I see repeating.

I have had audio start playing through WDM and routing through MC Server a couple times, but I wasn't able to get it going this weekend during these tests.    I may have/probably had MC GUI up ahead of time.   But in those few working cases, when I closed(exited) the MC GUI, the video hung in external browser.

Starting up MC GUI again had no effect. In that case, I have go into task manager and kill the JR server process to get video playback back, but no audio comes back.

[mattkhan]

it sounds like it is blocked for some reason on opening the output device, I previously said

You could set the output device to the null device (or a file) in order to rule out any sort of device clash

have you done this? this would enable you to positively assert the problem is on the output device side of things (or not)

[RoderickGI]

3) MC audio setup is set to the onboard audio (realtek) digital audio output (spdif). 

<snip>

I see levels thrashing on windows playback device MC(WDM driver), but not on the digital audio output(SPDIF) playback device (windows audio mixer)

So, audio should have just started playing here, but it doesn't.

Just checking here, but you do have working digital speakers connected to the (realtek) digital audio output (spdif) port don't you? What I mean is, you aren't relying on seeing activity in the Windows Audio Mixer to decide if audio is playing?

Because I don't get any indication of audio output in the Realtek Volume Mixer accessible by right-clicking the speaker icon in the System Tray. I also don't see any indication in the "Playback Devices" list, also accessible by right-clicking the speaker icon in the System Tray. I do see the bars moving in the Spectrum Analyser in MC both when I output YouTube audio to the "Realtek High Definition Audio" Playback Device (which has real analogue speakers connected to the outputs) and when I output to the "Realtek Digital Output(Optical)" Playback Device, which has nothing connected to it and so I hear no audio.

I also don't have a "Windows Audio Mixer", but that is probably because I am using Windows 10 rather than Windows 7. Sound management changed a lot with Windows 10, so I guess if you have a "Windows Volume Mixer", it was removed from Windows 10. Unless you are referring to the Realtek "Volume Mixer". You don't have any additional sound drivers or applications that may have components running that interfere with the MC audio do you?


Perhaps interestingly, I did manage to replicate your problem for a while, sort of. With all the changes I was making to the Windows Default Playback Device, while MC and Media Server was running, I managed to screw something up and lost audio output from YouTube video. But then I checked if I could play audio from within MC and couldn't, getting the error message "Something went wrong with playback". What I found eventually was that MC had got caught up somehow, stuck in a situation where it wouldn't play audio, but also wouldn't close. I found the "Media Center 23" item still listed in the Windows Task Manager when MC and Media Server were closed. When I killed that stuck process I got normal audio playback back, and the WDM Driver playback also worked again. You have already mentioned killing the MC process, so I am assuming that this was never your issue. I suspect that in my case the WDM Driver was still an attached process to MC, and prevented it closing properly, because I had already changed the Windows Default Playback Device, or something like that. The MC process does sometimes get stuck and needs to be killed.

So, if you have real working speakers attached to your PC and can play audio from within MC to those speakers successfully, but when you try to play from an external source such as YouTube via the WDM Driver you get no sound... well, have you tried what Mattkhan suggested, to eliminate any sort of device clash?

Maybe you need to look more closely to the comment below, which I pretty much skipped over. It could be a problem.

This line looks concerning as I see it repeatedly:
0485334: 7104: Sharing Plugins: VSocketReader::Bind: Socket bind failed: Unknown error Socket: 1904 Size: 16 Address: 172.16.0.1 Port: 1900

I'm not sure what that means. What is using port 1900 on your PC? Do you have any plugins installed in MC? What happens if you remove all plugins and try the WDM Driver again?

[mattkhan]

I believe 1900 is a port used by upnp

[RoderickGI]

So it is. Maybe that is just used for DLNA Discovery then, in which case the message could be related to discovery of the Denon AVR, which was part of the original problem here.

[RoderickGI]

Just for you John I installed Firefox and tested the WDM Driver. Works fine.

[john_kane]

Roderick and Matt,

I have to say thank you to you both for your patience and time, I really appreciate it.  It takes a while to do the detailed testing and has to be when the system isn't in use .  Loading  firefox yourself to test as well as the suggestions have been over and above.

Matt,

I missed your original suggestion to try the diskwriter or null output device.  It was a good one.  I tried this the other night, and I had better success; the video kept playing, IPC live played in MC and diskwrite stored some segments of the audio from the video playing in the browser. 

So that got me back to looking at the audio output driver and the selection options in MC: Digital Output (WASAPI) and digital output (direct sound).  Selecting each one repeatedly and trying again, I noticed failure following wasapi.  If I closed the gui with wasapi selected, video hung. That didnt seem to be the case with digital output(direct sound) selected.

And finally, on the 500th scroll through the various settings, I caught a discrepancy.  In the WDM driver advanced settings, default sample rate was set to 44.1khz.  Maybe this is default when driver is loaded, I dont recall setting it.   But the SPDIF audio output driver is set to 48khz (preferred input rate of the receiver) in advanced settings.  So.. given that wasapi is a no touch driver, I think the rate mismatch could be causing a problem,  and direct sound possibly does the rate conversion.  It did sometimes work with the mismatch though through MC.

I changed the WDM driver to 48 kHz sample rate, and as of tonight, that seems to have fixed it.   Operation tonight is more in line with your observed behavior.   I'll stay at this stage for a while and test some more before trying the next steps.

Roderick,
At least on Windows 7 audio mixer, I do(always) see sound level thrashing on the realitek (when there really is audio flowing).  I do thinks this differs in windows 10.


I would like to get to the bottom of the port 1900 error issue; maybe someone from MC team has input on this.

To answer your questions, I don't have any plugins enabled, and I checked the PC processes/NBTSTAT connections etc. I dont see anything else on the machine with 1900 open.

124114: 5260: Sharing Plugins: VSocketReader::Bind: Socket bind failed: Unknown error Socket: 1356 Size: 16 Address: 172.16.0.1 Port: 1900

I know its dlna related as I've seen the multicast discovery messages on that port in some of the logs.

[RoderickGI]

If you really want to get to the bottom of the port 1900 issue, be ready for some work!

Download AndrewFG's "Whitebear Digital Media Renderer Analyser" from here: http://www.whitebear.ch/dmra
Andrew is a member of the forum and our resident DLNA expert. His analyser should be able to tell you the capabilities of your Denon AVR, and if there are issues in connecting to it. I will stay out of that because I am no expert on the analyser!


Your fix for the WDM Driver issue is still a little confusing for me, unless there was another App involved that was trying to play audio in Exclusive Mode while you were trying to play something via the WDM Driver.

Using the old faithful YouTube as an example, the audio chain goes something like this:

YouTube		Plays audio via Windows Audio functions, and allows other applications to play audio while it is playing. So it is using Shared Mode and therefore Direct Sound. (Or you could say YouTube is using Direct Sound so it is playing in Shared Mode. Either way around works for me.) Windows will resample all audio inputs to the same bit-depth and sample rate so that it can then merge those audio streams into one stream for playback. So you hear both YouTube and Windows Sounds, or perhaps a Skype phone call ring, at the same time. YouTube can't take Exclusive Mode control of the target audio device. So for example, if two 16bit audio sources play at the same time, one a 44.1KHz and the other a 48KHz source, Windows will resample one or both audio streams to match the target output stream.
▼
▼
JRiver WDM Driver		Is the Default Output / Playback Device for Windows audio. When the input is in shared mode, Windows will use the bit-depth and sample rate set in the WDM Driver Advanced tab for mixing multiple audio streams into one stream. If the "Allow applications to take exclusive mode control of this device" and "Give exclusive mode applications priority" settings are checked (recommended) and an application is capable of outputting audio in Exclusive Mode (i.e. Tidal), then only one audio source can play to the WDM Driver at a time, and any other audio stream is lost. This usually means that Windows (Shared Mode) Sounds are lost unless the WDM Driver isn't playing anything in Exclusive Mode at the time.
▼
▼
JRiver Media Center		Takes in whatever audio stream is passed to it from the WDM Driver, at whatever bit-depth and sample rate is supplied. Converts the audio stream to 64bit for internal processing. If DSP is being used, will resample the stream to the Audio Output setting specified. The "Audio Path" feature in MC shows what bit-depth and sample rate it is receiving, what processing it does to the audio stream, and what bit-depth and sample rate it is outputting. Can output in Exclusive Mode or Shared Mode, based on audio settings.
▼
▼
Selected MC Output Device		Takes the audio stream MC has sent to it and plays the audio.

So theoretically changing the Shared Mode input sample rate that the WDM Driver uses, and informs Windows to use, should have no effect whatsoever on the sample rate used for the output from MC to the target Audio Device. If multiple audio inputs to the WDM Driver is Shared Mode don't match, Windows Direct Sound should resample them to the required sample rate. If the output of the WDM Driver doesn't match the capabilities of the target Audio Device in MC, and the DSP Output Format settings are correct for the Device, MC will resample to the correct Output Format.

Again, theoretically, the only situation where a change of the WDM Driver Shared Mode sample rate fixed the issue you were seeing is if;
1. YouTube switched output sample rate when starting to play a video, and Windows didn't respond quickly enough to resample to the correct target rate. So Windows tried to play the YouTube sample rate while also trying to play another audio stream using a different sample rate. Seems unlikely.
2. Some other application was playing to the Windows Default Audio Device (the WDM Driver) in Exclusive Mode, and took control of the WDM Driver while YouTube was playing some audio, and so there was a clash and YouTube lost, and didn't fail gracefully. Selecting both the Exclusive Mode settings in the WDM Driver mentioned above may make a difference, and is recommended.
3. The WDM Driver didn't inform Windows Direct Sound what sample rate to use in a timely manner. Possible.
4. YouTube (or the browser) didn't inform Windows Direct Sound what sample rate it was playing at in a timely manner. Possible.
5. Some combination of 3. and 4. above, with timing issues. Possible, but unlikely to be repeatable.
6. ? Windows voodoo is bad.

So John once you are satisfied that your fix seems to be working, you could try changing the WDM Driver Default Shared Mode sample rate back to 44.1KHz and see if the problem came back. Also you should note that I think YouTube generally does play at 48KHz, so setting the WDM Driver to that value means no resampling required by Direct Sound, so by default it works. If that is the case, whenever you play something that isn't 48KHz to the WDM Driver you may see a problem of some kind.

What fun, working inside the bowels of Windows!

[john_kane]

So John once you are satisfied that your fix seems to be working, you could try changing the WDM Driver Default Shared Mode sample rate back to 44.1KHz and see if the problem came back. Also you should note that I think YouTube generally does play at 48KHz, so setting the WDM Driver to that value means no resampling required by Direct Sound, so by default it works. If that is the case, whenever you play something that isn't 48KHz to the WDM Driver you may see a problem of some kind.

Roderick,

I verified this part already.  I switched back and forth 3 or 4 times. Problem follows a WDM SPDIF mismatch AND WASAPI output. "Sometimes" it will play through IPC in this state.

If WDM is set 44.1, and SPDIF out set to 48 (WASAPI), problem occurs, and behavior is unpredictable.   Most times,  won't even play from start
 
If I make only one change: set SPDIF out to Direct Sound, seems reliable.

If I set WDM to 48khz and SPDIF out to WASAPI, seems reliable.

Thanks for your detailed note on the flow.  From your description, I get that it should work.   It is interesting that closing down the GUI locks it up.  In the normal working case, audio will mute for 5-10 secs when you close the GUI.


  I don't think there is anything special about the youtube, or a sample rate change mid viewing, anything like that. I've tried different sources too.

As for the DLNA piece. Well, things mostly work on my setup, I am able to dlna stream around to devices, especially the AVR.  I'm trying to effectively setup a standing  WDM input-> stream to dlna zone, and its got to be rock solid or its going to fail the family user test.

I'll take a look at the  tools.  the port error happens at the server itself, so it would seem to point to something local.  But I don't see any other process with that port open.

[RoderickGI]

Sounds good John. Thanks for the update.

It is a weird situation alright. It could be that there is a problem with the WDM Driver, but if it can't be repeated on other hardware and installations it is hard to say.

The DLNA error at the server makes sense, since it is the server that connects to the Denon. The Digital Media Renderer Analyser queries DLNA devices to see what capabilities they have and what commands they respond to. I would think that the failure to bind to a socket is a DLNA connection negotiation issue.

Enjoy the music!