Print

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

[Amfibius]

This is the situation: I use JRiver on my PC, which outputs to the DAC and the sound system. I use BubbleUPNP on my Samsung tablet as a control point to stream Tidal to JRiver, and to play files stored locally on the PC. I also get JRiver to perform convolution to 8 channels as my speaker has been converted to active. I have a number of third party DSP VST's including uBACCH.

The problem: there is severe latency between entering any command in BubbleUPNP and JRiver responding. For example, if I hit "Play", it takes several seconds for JRiver to load up the track and start playing. Likewise, any change in volume takes a short while for JRiver to respond.

Attempted solutions:
- Turn off all VST plugins: no difference
- Upgrade JRiver from MC29 to MC31: no difference
- I bought an mConnect license and used that instead of JRiver: no difference

The ONLY control point which does not result in any latency is JRemote2.

I spoke to a friend who uses the same setup (BubbleUPNP --> JRiver) and he does not have any problems with latency.

The result of all this testing makes me suspect there is some kind of setting in JRiver which is causing all this latency. It can't blame BubbleUPNP because I have the same problem with mConnect. I can't blame the FIR filters I use for convolution because there is no latency with JRemote2. I can't blame the VST plugins because the problem is still there when I switch it off.

Any ideas where I should look?

[Amfibius]

BTW I have spoken to someone else who reports that he has latency issues with BubbleUPNP --> JRiver as well. He thinks it might have something to do with JRiver's implementation of DLNA. Given that JRemote2 (which doesn't use DLNA) has minimal latency, and two separate apps (BubbleUPNP and mConnect) have the same issue, I am inclined to suspect that the latency is a JRiver problem.

I would like to know if there is a setting which I missed, or whether this is a known problem on JRiver's "to do" list?

[markf2748]

I just tested with BubbleUPnP on phone, using Flac 44.1 kHz stereo on the MC end, and MC's only DSP is level adjustments.  MC's response to Bubble commands is pretty snappy, less than 1 second.  Have you tested this simple case?

In MC:  Options > Audio > Audio Device > Device settings... > Buffering > 25ms

In BubbleUPnP player on Android:
More > Settings > Renderers settings > Select renderer > (Your PC Server): Player > Renderer polling interval > Interval: 900 ms

900 ms is the default and shortest valid setting according to Bubble.  Is yours set longer?  If so, try 900, restart Bubble, confirm the value was accepted, and test.

There are also a bunch of other Bubble settings in that same area to check, for example try turning on "Use eventing".

Win11 Pro 23H2 (64-bit) | JRiver MC 31.0.87 | BubbleUPnP player 4.3.1.2 on Samsung Galaxy S9 Android phone | Intel NUC8i5BEH,  flac files on external USB SSD | RME ADI-2 DAC FS via USB, RME ASIO MADiface USB driver.

[Amfibius]

Thank you. I forgot to add, I have a number of other things which may cause latency to be worse than normal.

- JRiver hosts the convolution files for my audio system. It creates the crossover. So it takes a 2ch input and splits it into 8 channels. This goes into an 8ch DAC and then to my 4 way speaker system. I wondered if JRiver's convolver is a little bit slow, so I got JRiver to output 2ch to Acourate Convolver. I get the same result. I think the FIR filters are adding latency.
- I have been upsampling to 192kHz because I get a benefit of improvement in SINAD from -110dB at 44.1kHz to -118dB at 192kHz. Changing this back to 44.1kHz has lowered the latency. Interestingly, if I get JRiver to perform convolution at 192kHz, I get audio stuttering and dropouts, despite CPU usage at 20%. If I get JRiver to upsample to 192kHz and send that to Acourate Convolver, it plays flawlessly.
- I have already been using the BubbleUPNP settings and JRiver settings you recommended. In fact, I was using 5ms buffering in JRiver.

For now, I am going to point the blame at the long FIR filters and the 192kHz upsampling. I can't do anything about the long FIR filters, it took me a lot of effort to make them and they sound excellent - well worth the cost in latency (if that is the cause). But the 44.1kHz -> 192kHz upsampling I can do without, so I have dropped it back to 44.1kHz.

I wonder if there is an explanation for the stuttering and dropouts when I upsample to 192kHz and apply convolution in JRiver instead of Acourate convolver. I mean, CPU usage is only 20% ...

[mattkhan]

common use of acourate is to create linear phase filters, by default these would be 65k taps at standard audio sample rates (upto 48kHz). To maintain the same low frequency precision, this would become a 262k tap filter at 192kHz but the delay would be the same in either case (a little under 0.7s). I can't think of a reason why upsampling would have any material impact on latency though it will definitely increase CPU load, I can't think of a reason why it's beneficial either so no harm getting rid of that.

another thing to check is whether it's transcoding to some other format when it sends it to bubble, this may add additional buffers on top of existing ones though I can't say I've ever looked into it, just a possible extra source of lag.

[Amfibius]

another thing to check is whether it's transcoding to some other format when it sends it to bubble, this may add additional buffers on top of existing ones though I can't say I've ever looked into it, just a possible extra source of lag.

Thank you for your response. Just to be clear, I am using BubbleUPNP as a remote control for JRiver. It has a very important feature, which is its ability to stream Tidal to any DLNA endpoint. In this case, I am using JRiver as a DLNA endpoint. Even Tidal's own app can't do that. I do not use BubbleUPNP to receive audio from JRiver.

[mattkhan]

Thank you for your response. Just to be clear, I am using BubbleUPNP as a remote control for JRiver. It has a very important feature, which is its ability to stream Tidal to any DLNA endpoint. In this case, I am using JRiver as a DLNA endpoint. Even Tidal's own app can't do that. I do not use BubbleUPNP to receive audio from JRiver.

I would look at the logs in MC to see exactly when it responds and compare that to when playback is initiated, look to see if MC is slow to receive the instruction or receives it quickly but is slow to start

[Amfibius]

I would look at the logs in MC to see exactly when it responds and compare that to when playback is initiated, look to see if MC is slow to receive the instruction or receives it quickly but is slow to start

Great suggestion! Forgive me for being so stupid, but how do I do that? I am running MC 31 for Windows. I just had a look at C:\Program Files\J River and I could not find anything that looks like a log?

[mattkhan]

Great suggestion! Forgive me for being so stupid, but how do I do that? I am running MC 31 for Windows. I just had a look at C:\Program Files\J River and I could not find anything that looks like a log?

Details in https://wiki.jriver.com/index.php/Logging

I would reset the log just before you trigger playback and then copy the log file as soon as playback starts, this way you will get a log that contains the minimal amount of info required to see what was going on