Print

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

[RD James]

I can't pin-point specifically when this happened but lately it seems to have been 50/50 for whether any audio being played to the JRiver WDM driver is going to work or not.
It seems to get stuck on "opening..." for no apparent reason.
To fix playback I need to open up the main JRiver window and clear the playlist, then audio starts working immediately.

Can we get an option to set a time-out to prevent it from getting stuck like this?
My device takes something like 0.5s to initialize so a time-out of 1-2 seconds should mean that it continues to work instead of being stuck in this "opening..." state indefinitely.
 
I think it might be related to the fact that the JRiver WDM device closes its connection immediately as soon as audio stops playing.
So when I seek in a YouTube video the connection is dropped and it tries to reconnect again but the playback device has not yet been released and it gets stuck in this "opening..." state.
A way to prevent that from happening would be good too.
I'd like the WDM driver to remain "open" for at least 60 seconds after playback stops, if not longer.

[RD James]

Does no-one else see this?
When seeking in YouTube videos in the browser (Firefox) or 3-4 videos into a YouTube playlist this always happens and I have to open up JRiver and intervene to fix audio playback.

[mwillems]

Does no-one else see this?
When seeking in YouTube videos in the browser (Firefox) or 3-4 videos into a YouTube video this always happens and I have to open up JRiver and intervene to fix audio playback.

I do see the IPC getting stuck occasionally, but never in the cases you're describing; I only see it stick like that if something tries to open the IPC when I'm actively playing music in JRiver.  I tried seeking around in a youtube video, but coudln't reproduce it, the worst I could get was missing a second or two of audio here and there.  Maybe different buffering settings?

One tip i can offer: when it gets stuck for me I don't have to clear the playlist; just pressing stop in the appropriate zone solves the problem and allows the IPC to reengage.  Not sure how much that helps, but if you have media keys/a remote it certainly makes it faster to work around.

[RD James]

I have IPC set up to play to its own zone.
Nothing else on my system accesses the playback device for that zone. (NVIDIA HDMI)
Because it has its own zone I don't have quick access to the stop command for it. My regular audio/video zone is the one that has "focus" in JRiver.

I've tried changing buffer settings but that doesn't seem to be the issue.
I can cause this to happen 100% of the time if I have a program send audio to the HDMI device via WASAPI exclusive, and then start IPC playback.
This gets stuck on "Opening..." every time, and remains that way indefinitely until I intervene.

But I don't normally allow anything else on the system to play to the HDMI device, JRiver is the only one.
I think what happens is that JRiver drops the WDM/IPC connection every time you seek or change video and then tries to re-connect almost immediately after, which causes it to conflict with itself because the exclusive lock on the HDMI device has not been released yet.
If JRiver wouldn't immediately drop the connection with WDM/IPC, and held onto it for 30-60 seconds, I think that would avoid this situation 90% of the time.

But I also think that JRiver should handle the conflict state much better than it does now.
It shouldn't be possible to get stuck on "Opening..." indefinitely.
That should automatically clear itself after a second or two, instead of completely blocking all WDM playback indefinitely.

[mwillems]

I've tried changing buffer settings but that doesn't seem to be the issue.
I can cause this to happen 100% of the time if I have a program send audio to the HDMI device via WASAPI exclusive, and then start IPC playback.
This gets stuck on "Opening..." every time, and remains that way indefinitely until I intervene.

I see the same thing with this fact pattern.

But I don't normally allow anything else on the system to play to the HDMI device, JRiver is the only one.
I think what happens is that JRiver drops the WDM/IPC connection every time you seek or change video and then tries to re-connect almost immediately after, which causes it to conflict with itself because the exclusive lock on the HDMI device has not been released yet.

Have you considered trying a non-exclusive output mode for the WDM zone?  I don't see the problem you're seeing even using an exclusive output mode, but you mgiht be able to easily work around by using wasapi non-exclusive or direct sound.

If JRiver wouldn't immediately drop the connection with WDM/IPC, and held onto it for 30-60 seconds, I think that would avoid this situation 90% of the time.

The drop was introduced to solve a different problem; some system software would open the WDM driver and hold it open (exclusively) even with no sound playing (flash was a particular offender).  This would create an issue where IPC would continue playing indefinitely while no sound as coming out, that would interfere with normal usage.  So they built in silence detection to cause the IPC to drop out within a reasonable time if there's no input.  The timer is, I think, 5 seconds.  This is all based on recollection from an old thread I can't find now.

But I also think that JRiver should handle the conflict state much better than it does now.
It shouldn't be possible to get stuck on "Opening..." indefinitely.
That should automatically clear itself after a second or two, instead of completely blocking all WDM playback indefinitely.

I agree; it seems like solving this would solve all the other issues.

[RD James]

Non-exclusive might work around this, but then you're going through the Windows mixer twice.

The drop was introduced to solve a different problem; some system software would open the WDM driver and hold it open (exclusively) even with no sound playing (flash was a particular offender).  This would create an issue where IPC would continue playing indefinitely while no sound as coming out, that would interfere with normal usage.  So they built in silence detection to cause the IPC to drop out within a reasonable time if there's no input.  The timer is, I think, 5 seconds.  This is all based on recollection from an old thread I can't find now.

Staying open indefinitely would be ideal, as it would eliminate the latency of WDM playback starting and the 1-2 seconds of audio that are lost at the beginning of playback.

But is definitely not looking for 5 seconds of silence before disengaging. It is instant.
As soon as I seek in a YouTube video playing in Firefox, the IPC connection is dropped and re-opened - which I think is the cause of it ending up in this conflict state. (Opening...)
 
In fact it sometimes seems as though the cut-off happens before audio has finished playing as I get a glitch/click/pop through my speakers if a video plays sound right to the end.
When a video like that finishes, the WDM driver seems to cut off as soon as the video stops in the browser, not the 0.5s later or whatever the delay there is for audio being passed through JRiver.

I agree; it seems like solving this would solve all the other issues.

Well it would work around the other issue, but would mean at least a second or two of missed audio every time it occurs.
Ideally both issues would be fixed.

[mwillems]

Staying open indefinitely would be ideal, as it would eliminate the latency of WDM playback starting and the 1-2 seconds of audio that are lost at the beginning of playback.

It maybe ideal for your use case, but it's not ideal.  Think of a more typical case where someone only has one output device and is using the WDM driver with the same output device that they use for regular audio playback. Opening the WDM driver and never releasing it with WASAPI exclusive meant you couldn't start audio playback in JRiver on the same device without a "device not available" type error (which is why the silence timout was put in, because some software would open a connection and never release it even while not playing any audio).  More to the point you couldn't just "stop" the WDM driver as in some cases it would immediately re-open itself (to play silence).

But is definitely not looking for 5 seconds of silence before disengaging. It is instant.
As soon as I seek in a YouTube video playing in Firefox, the IPC connection is dropped and re-opened - which I think is the cause of it ending up in this conflict state. (Opening...)

It only waits 5 seconds for silence while a program is holding the audio output open; if the program that "opened the driver" closes the connection, the IPC ends more or less instantly.  That's very likely what you're seeing in your seeking activity; the browser (or flash) opening and closing the audio device connection repeatedly.  Again, this is a feature if you're trying to use the same device for IPC and normal playback.  I agree it should hande getting stuck more gracefully, obviously.

In fact it sometimes seems as though the cut-off happens before audio has finished playing as I get a glitch/click/pop through my speakers if a video plays sound right to the end.
When a video like that finishes, the WDM driver seems to cut off as soon as the video stops in the browser, not the 0.5s later or whatever the delay there is for audio being passed through JRiver.

That's probably because of what I mentioned above; the stream gets cut off when the browser closes the connection rather than when the data runs out.  You might be able to solve that with smaller buffers.

[RD James]

It maybe ideal for your use case, but it's not ideal.  Think of a more typical case where someone only has one output device and is using the WDM driver with the same output device that they use for regular audio playback. Opening the WDM driver and never releasing it with WASAPI exclusive meant you couldn't start audio playback in JRiver on the same device without a "device not available" type error

Well that's another issue. I never understood why JRiver can't manage its own zones and stop one then start playback in another instead of giving a generic error. But I can't figure out zone switch either. The way it decides to follow rules or not doesn't make much sense.
Still, the option to stop IPC from closing would be nice.

That's probably because of what I mentioned above; the stream gets cut off when the browser closes the connection rather than when the data runs out.  You might be able to solve that with smaller buffers.

Oh, the buffers are as small as they can be. It's the only way I can keep audio in sync for videos.
I have tried other settings though to see if it would remedy this. (it did not)
I've started keeping track of it and I've had to manually go in and fix IPC eight times this evening.

[RD James]

I tried keeping track of the number of times that this happened over the weekend, and it was over 20 before I lost count.
It's definitely been worse ever since moving to Windows 10. (a clean install, not an upgrade)

On Windows 8 it seemed to happen maybe 10% of the time, on Windows 10 it seems more like 30%.
Some changes to help improve this would be much appreciated.

[JimH]

Do you have any Sony software installed?  Vegas, etc.  They had a problem with our ASIO that occurred, at least in part, because their software was opening every ASIO connection as soon as it started.  Or at least that's my understanding of it.

[RD James]

Do you have any Sony software installed?  Vegas, etc.  They had a problem with our ASIO that occurred, at least in part, because their software was opening every ASIO connection as soon as it started.  Or at least that's my understanding of it.

No Sony software installed, and the problem is with the WDM driver not the ASIO driver.

[RD James]

This is still a constant nuisance. Does no-one on the JRiver team use Firefox or other applications which may cause Media Center to quickly drop and reconnect the IPC connection, causing it to stall?

[RD James]

Bump

[RD James]

Are there any plans to fix this?
I have had to stop using the JRiver driver now because it constantly hangs and causes many applications/games to crash when it is in this state.