Topic: Improved loopback - how to use? (Read 5176 times)

Trumpetguy · « **on:** September 18, 2012, 03:35:28 pm »

Yeay - MC18 is out in the open, congratulations - great work

First thing I tested was the promised improved loopback feature. I did not find any new way of activating it, so I tested opening the same URL as before live://loopback. I am not able to get any good playback, there is still quite a lot of clicks and pops every few seconds. I am bound to use ASIO, and have tested different buffers from 0.02s to 3s. There is no noticeable difference whatever buffer size I use. I have also tested with and without a large convolution delay, and whether or not this is active does not to seem to have any effect.

Could anyone explain to me if I am doing something wrong?

natehansen66 · « **Reply #1 on:** September 18, 2012, 07:08:04 pm »

What do you use for a sound card?

Trumpetguy · « **Reply #2 on:** September 19, 2012, 01:27:37 am »

Lynx, a combination of LynxTwoB (pci) and Aurora8 (external, via pci interface). All audio is routed through the Lynx mixer.

Matt · « **Reply #3 on:** September 19, 2012, 03:11:06 pm »

It was supposed to just work now. So apparently there's still a wrinkle that causes problems in some cases.

What's your JRMark score (Help > Benchmark)?

If you disable DSP, including resampling, does it make a difference?

(p.s. you still have to start loopback the hidden way, but this will change during v18)

Trumpetguy · « **Reply #4 on:** September 19, 2012, 04:31:17 pm »

Benchmark is just above 3500.

Tests:

I was just now able to gat glitch free playback when disabling all DSP, at least for a few minutes. Buffer time was set at 0.4s.
Then I tried to set default playback device to 24/48, and have MC resampling to 44.1 (my Lynx was playing at 44.1): Perfect playback
Default playback device to 16/44.1, no MC resampling + Convolution: First, some glitches, then almost perfect playback some of the time, then periods with frequent glitches.
Default playback device to 24/48, and have MC resampling to 44.1 + Convolution: Frquent glitches

natehansen66 · « **Reply #5 on:** September 19, 2012, 05:39:39 pm »

FWIW loopback is working just fine for me. I don't use convolution but I use copious amounts of DSP

I do get a few "hiccups" occasionally (and I do on MC17 as well), but not enough to bother me to try to fix it.

Trumpetguy · « **Reply #6 on:** September 20, 2012, 01:32:14 am »

Well, I can count on a couple of fingers how many times I get hickups with MC during the past three-four years when playing from MC library

With loopback and convolution, the pops and crackles vary from a few every minute to something resembling static noise.

I also was under the impression that it should be possible to have audio/video sync when using this feature to e.g. watch YouTube videos. I must have misunderstood, and frankly I really do not understand how that can be accomplished either. But then again, this is not exactly my area of expertise.... Maybe Matt can explain if it should be possible? And a few words on how?

rlebrette · « **Reply #7 on:** September 20, 2012, 02:59:12 pm »

I have the same problem with a different hardware:

Q9550 JRMark 1975
M-Audio Profire 610 - Convolution 8 paths 6.5 x realtime
- WASAPI ES => very noisy
- ASIO => sound but a lot of hickups.

mojave · « **Reply #8 on:** September 20, 2012, 03:26:32 pm »

Quote from: Matt on September 19, 2012, 03:11:06 pm

(p.s. you still have to start loopback the hidden way, but this will change during v18)

Until then, a quick way is to assign a Car Radio Button to the loopback.

Matt · « **Reply #9 on:** September 20, 2012, 03:34:04 pm »

I haven't been able to reproduce hiccups, even using resampling and convolution on 8 channels.

How many input channels are you playing? I'm testing input of 2-channel @ 96kHz.

Matt · « **Reply #10 on:** September 20, 2012, 04:39:45 pm »

I'm able to get playback to hiccup a bit testing with 8 channel @ 96 kHz -> 5.1 @ 48 kHz w/ AC3 encoding once I turn on convolution.

I'm guessing convolution is causing the output to be lumpy (since FFT works in windows) and this causes buffer shortfalls.

It may be a few builds before I get a chance to dig into this, but hopefully we'll be able to find a solution.

However, I don't think it's going to be that great with convolution regardless, because we don't have any way to compensate for high latency like that. If we ever write a WDM driver, I would hope we could adjust for the latency (but I don't know enough about this to be sure).

Trumpetguy · « **Reply #11 on:** September 21, 2012, 05:07:36 am »

Quote from: Matt on September 20, 2012, 03:34:04 pm

I haven't been able to reproduce hiccups, even using resampling and convolution on 8 channels.

How many input channels are you playing? I'm testing input of 2-channel @ 96kHz.

I have only tested with 2-channel @44.1 or 48kHz, which is the more used loopback use for me (Spotify mainly).

rlebrette · « **Reply #12 on:** September 24, 2012, 06:22:10 am »

Quote from: Matt on September 20, 2012, 04:39:45 pm

I'm able to get playback to hiccup a bit testing with 8 channel @ 96 kHz -> 5.1 @ 48 kHz w/ AC3 encoding once I turn on convolution.

I'm guessing convolution is causing the output to be lumpy (since FFT works in windows) and this causes buffer shortfalls.

It may be a few builds before I get a chance to dig into this, but hopefully we'll be able to find a solution.

However, I don't think it's going to be that great with convolution regardless, because we don't have any way to compensate for high latency like that. If we ever write a WDM driver, I would hope we could adjust for the latency (but I don't know enough about this to be sure).

Hi Matt,

I've played a little with different configurations, and everything is working fine in ASIO up to 5.1 / 96 Khz (MPC-HC as a source), but as soon as I activate the convolution, I get the problems.
You're talking about buffer shortfalls, is it related to the CPU or the sound card? If it"s CPU related, is there any way to know how much CPU power I should have to handle this kind of configuration?

Thanks for your help

Mikkel · « **Reply #13 on:** November 23, 2012, 09:50:26 am »

*BUMP*

Just wanted to hear if improving loopback when using convolution is being worked on or if it is on standby.

P.S. It works wonderfully with no convolution. That is definately an improvement compared to v17 (at least on my system). Good job.

Best regards,
Mikkel

Trumpetguy · « **Reply #14 on:** December 13, 2012, 02:10:26 am »

The loopback works perfectly in the .90 build when not using convolution, thanks for the improvements!

Once convolution is activated the sound still stutters violently regardless of ASIO buffer settings.

I use Audiolense filters with 131k taps, i.e. maximum filter length. I did not have the time yet to create and test with shorter filters. Is there any reason to believe shorter filters would work any better?

rlebrette · « **Reply #15 on:** December 13, 2012, 02:35:24 am »

I've shorter filters and face the same problem.

natehansen66 · « **Reply #16 on:** December 13, 2012, 09:29:52 am »

I've also tried shorter FIR filters with no luck, going down to 4k taps. Without convolution loopback is flawless. How low of a buffer are you guys using for clean playback from the pc with no loopback using convolution? 2 ms is the lowest I can go for clean playback, but loopback falls apart at this setting.

Matt · « **Reply #17 on:** December 13, 2012, 09:30:59 am »

What happens if you let playback continue for a few minutes? Do the stutters from convolution go away?

rlebrette · « **Reply #18 on:** December 13, 2012, 10:37:41 am »

Quote from: Matt on December 13, 2012, 09:30:59 am

What happens if you let playback continue for a few minutes? Do the stutters from convolution go away?

I've just tested what you have suggested, I have no improvement after more than 10 minutes.
I've tried a lot of configurations playing with convolution filters (taps), with the buffer size (from 4 seconds to 20 ms), with ASIO/WASAPI/WASAPI-ES.
I've monitored CPU and memory (35% CPU, 40% RAM)

Trumpetguy · « **Reply #19 on:** December 13, 2012, 11:26:02 am »

I have to correct myself. In the past, I have upsampled to 96kHz, upmixed from stereo to 7.1 (2.1 when source is stereo), and run a 15 paths filter 4.5x real time. THEN it stutters.
I just now tested with a stereo input, upsampling to 96kHz, then a stereo filter (131k taps) with two paths only (23.5x real time). Now playback is smooth even with convolution!

I have a >4000 benchmark computer, but it may not be powerful enough for the 15 paths filter?

Anyways - most sources for loopback are stereo, so this is a tremendous step forward!

Matt · « **Reply #20 on:** December 13, 2012, 11:50:58 am »

Could you email a copy of the 15 path 7.1 filter to matt at jriver dot com?

I'll test the same here and see what happens.

Thanks.

Trumpetguy · « **Reply #21 on:** December 14, 2012, 02:57:34 am »

Quote from: Matt on December 13, 2012, 11:50:58 am

Could you email a copy of the 15 path 7.1 filter to matt at jriver dot com?

I'll test the same here and see what happens.

Thanks.

Sure. I'm not home for a couple of days, but I will send it to you as soon as I can.

Matt · « **Reply #22 on:** December 18, 2012, 11:56:16 am »

Next build:
Changed: When doing live playback, WASAPI and ASIO were using 10ms as the maximum hardware buffer size. This could lead to audio hiccups, so now the user setting is always honored. If you do loopback playback, you might try a small buffer size to reduce latency.
Changed: Improved buffer allocation scheme used by WASAPI - Event Style, so that lower latency settings will work better.

Hopefully this solves any remaining loopback issues.

Trumpetguy · « **Reply #23 on:** December 18, 2012, 02:19:23 pm »

Thanks a lot - looking forward to try it. This feature is becoming more and more interesting as the number of streaming services increases!

Mikkel · « **Reply #24 on:** December 21, 2012, 03:24:06 am »

Quote from: Matt on December 18, 2012, 11:56:16 am

Next build:
Changed: When doing live playback, WASAPI and ASIO were using 10ms as the maximum hardware buffer size. This could lead to audio hiccups, so now the user setting is always honored. If you do loopback playback, you might try a small buffer size to reduce latency.
Changed: Improved buffer allocation scheme used by WASAPI - Event Style, so that lower latency settings will work better.

Hopefully this solves any remaining loopback issues.

Hi Matt,

Both some good and some less good news. Loopback now works better than ever on my machine, where I upmix to 7.1 and convolve the audio. However, that unfortunately only means that I get less hick-ups than previously and the level of hick-ups is still too high to make the (wasapi) loopback useful.

I have tried different latency adjustments (up to 500 ms) but it does not change anything.

It seems convolution is the bottle-neck on my system when it comes to the loopback feature.

Best regards,
Mikkel

JimH · « **Reply #25 on:** December 21, 2012, 06:50:27 am »

Quote from: Mikkel on December 21, 2012, 03:24:06 am

I have tried different latency adjustments (up to 500 ms) but it does not change anything.

Try very low numbers.

natehansen66 · « **Reply #26 on:** December 21, 2012, 10:27:38 am »

I agree with Mikkel, the Loopback is working much better with the new build, but I'm still getting some hiccups. I've got 6 channels of FIR convolution going (using the least amount of taps to get an acceptable result), and I'm using a .06ms buffer.

In my case I wonder if my PC isn't quite up to the task. I get a 1408 score for the math benchmark, and a JRMark of 1808.

JimH · « **Reply #27 on:** December 21, 2012, 12:57:06 pm »

Try running MC's benchmark (under Help) and post the results.

Trumpetguy · « **Reply #28 on:** December 21, 2012, 03:14:53 pm »

Tested .101: Without convolution, all works perfectly. Also convolution with only two paths. With multichannel convolution (7.1, 15 paths) it is much the same as before or even worse.

mojave · « **Reply #29 on:** December 21, 2012, 04:57:46 pm »

I assume you are using ASIO output with your Aurora 8. Are you also adjusting the latency in the drivers? They may need larger buffers while the buffer in JRiver is decreased. You can also untick "use large hardware buffers."

How are you connected - Firewire, USB? If Firewire, then there is also a Firewire buffer than can be adjusted.

Are you resampling in JRiver? This caused some problems for me. The automatic sample rate switching for convolution makes it so you don't have to resample anymore.

Trumpetguy · « **Reply #30 on:** May 04, 2013, 11:27:50 am »

Old thread brought to life. I just thought I should try loopback with convolution again today - and it works flawlessly! That is, I only tested stereo with a 131k tap filter, not multichannel. I have not tested it since build .101 (now using .177), because I have not noticed anything in the changelog that indicated loopback improvement. But now it works! Great!

PS: I have not changed my hardware since last time, but I may have deactivated some stuff in BIOS because it interfered with my Lynx card at high sample rates. Its the only thing I can think of that has changed besides new JRiver MC builds.

INTERACT FORUM

Author Topic: Improved loopback - how to use? (Read 5176 times)

rlebrette

rlebrette

rlebrette

rlebrette