Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER for Linux

Reply
 
Thread Tools Display Modes
Old 06-27-2019, 01:17 PM   #1
lilith93
Human being with feelings
 
lilith93's Avatar
 
Join Date: Apr 2018
Location: Karlsruhe
Posts: 486
Default Media Xruns & Xruns while changing time selection

Found another issue:

Please lower volume before watching
https://vimeo.com/344883220

When changing the selected range while transport is on and making the range quite short this results in a hell of normal and media xruns. This happens with VST and audio data.
Is this normal or do I have to adjust some buffer size numbers? Reaper is running with Jack running at 528 samples and 48kHz.
__________________
https://soundcloud.com/lilith_93
https://open.spotify.com/intl-de/art...SMSwCW9VkqAN9Q
MX Linux, Behringer UMC 204 HD, Neumann KH120
lilith93 is offline   Reply With Quote
Old 06-27-2019, 03:40 PM   #2
JamesPeters
Human being with feelings
 
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
Default

I can't reproduce this behavior. I tried the option to unlink the time selection to the loop points (and with it linked too), I tried the option to seek on loop point change (such as you're doing) and also with that option disabled. I even ran my CPU around 85% with a buffer 1/10 the size you're using (while also not assigning a high priority to my audio device with rtprio). I tried ALSA, and also JACK (using the same buffering settings). My JACK setup involved default priority settings.

By the way, your buffer is 4 periods of 528 samples/"frames" (2112 samples total), not 528 samples. That's why Reaper shows that you're getting 44 ms round-trip latency. 528 samples at 48000 Hz = 11 ms latency (528/48000). 2112 samples at 48000 Hz = 44 ms.

Also I noticed you had lots of xruns before you even started the performance meter.

I recommend lowering that buffer setting to something more normal, around 4 periods of 128 for example. Sometimes using too high a buffer can cause problems.

Also: is the project sample rate the same as the sample rate of the WAV files on the audio tracks? If it's resampling in realtime that can stress the CPU.

Last edited by JamesPeters; 06-28-2019 at 08:50 AM. Reason: Clarification of buffer terminology
JamesPeters is offline   Reply With Quote
Old 06-28-2019, 01:13 AM   #3
lilith93
Human being with feelings
 
lilith93's Avatar
 
Join Date: Apr 2018
Location: Karlsruhe
Posts: 486
Default

Thanks for your comments. I´ll try to figure out what´s going on in the evening. From where did you see that I use 4 blocks? My latency as shwon in Jack is 11ms and I´m using a block size of 3. I also get the xruns when I mute the audio tracks and only play one midi track. The previous xruns came from the same issue. Just now by looking at the video I realized that RT CPU usage is indeed exceeding 100%. I don´t see these high numbers in Jack.

Quote:
Originally Posted by JamesPeters View Post
I can't reproduce this behavior. I tried the option to unlink the time selection to the loop points (and with it linked too), I tried the option to seek on loop point change (such as you're doing) and also with that option disabled. I even ran my CPU around 85% with a buffer 1/10 the size you're using (while also not assigning a high priority to my audio device with rtprio). I tried ALSA, and also JACK (using the same buffering settings). My JACK setup involved default priority settings.

By the way, your buffer is 4 blocks of 528 samples (2112 samples total), not 528 samples. That's why Reaper shows that you're getting 44 ms round-trip latency. 528 samples at 48000 Hz = 11 ms latency (528/48000). 2112 samples at 48000 Hz = 44 ms.

Also I noticed you had lots of xruns before you even started the performance meter.

I recommend lowering that buffer setting to something more normal, around 4 blocks of 128 for example. Sometimes using too high a buffer can cause problems.

Also: is the project sample rate the same as the sample rate of the WAV files on the audio tracks? If it's resampling in realtime that can stress the CPU.
__________________
https://soundcloud.com/lilith_93
https://open.spotify.com/intl-de/art...SMSwCW9VkqAN9Q
MX Linux, Behringer UMC 204 HD, Neumann KH120
lilith93 is offline   Reply With Quote
Old 06-28-2019, 08:04 AM   #4
JamesPeters
Human being with feelings
 
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
Default

Your latency is shown at the top right of that window in Reaper: 11/33ms. That's 11ms input latency, 33ms output latency. Combine the two and it's 44ms round-trip latency. It also shows the blocksize of 528 but it doesn't show the number of blocks/periods.

It's not a blocksize of 3 that you are using in JACK. It's 3 periods.

Since the blocksize is 528 "frames" (JACK refers to this as "Frames/Period") and the round-trip latency is 44ms, that means there must actually be 4 periods of 528 frames. (Note: in Reaper, it refers to the blocksize as "samples", not "frames/period".)

If you are using JACK, apparently it uses an "extra block" (I had read about this months ago but I forget what the specific reason is). So if you choose "3 periods/buffer" in JACK it will use an additional one (making it 4 periods total).

You can try just using ALSA in Reaper instead. You'll see how using 4 periods of 528 will give the same latency you're currently seeing, but if you use 3 periods it will be reduced accordingly to 33ms round-trip latency.

I still recommend trying 4 periods of 128, at least as a test.

About what you said on the RTIRQ thread: I think it's possible you're assigning too high a priority to JACK. When I said that I found it problematic to increase "Reaper's priority" too high, I meant when using ALSA drivers. There's a section in the audio preferences, when using ALSA, to set Reaper's ALSA RT priority, and it recommends keeping it at 40 for realtime use (assuming default RT priority of the audio hardware, I guess). So I think if you set JACK's priority too high, you can have the same problem. I recommend lowering it to at least 60 as a test; that should be low enough. If that doesn't help: maybe just reset all your RTIRQ settings to their defaults, and go from there. I didn't need to use RTIRQ on my system at all to get excellent performance, and I know now that if you use the wrong RTIRQ settings it can make things worse. Giving things too high a priority can be worse than the default settings.

Last edited by JamesPeters; 06-28-2019 at 08:59 AM.
JamesPeters is offline   Reply With Quote
Old 06-28-2019, 12:50 PM   #5
lilith93
Human being with feelings
 
lilith93's Avatar
 
Join Date: Apr 2018
Location: Karlsruhe
Posts: 486
Default

I made some tests again. When using ALSA instead of Jack with buffer sizes of 128 samples and 528 samples and block numbers of 2-3 I always get the same behavior, i.e. xruns and crackling. I also lowered the priority of Jack / Reaper again to 80, which is the default setting in Cadence.
I observed that when using VST instruments there's even crackling without xruns (?? see the video below). With CPU heavy VST (like Repro 5). I can get xruns with even one instance when changing the time range. When just playing the project it's no issue at all.

For just one audio file there's no RT xruns, no crackling, but media xruns for very small time ranges. It also does not depend on the sampling rate of the sample. I think my system is configured fine as I get quite good results with the xruncounterscript (from https://linuxmusicians.com/viewtopic...it=xruncounter ; see below). I made a test with a live MXLinux system (which is not configured for RT audio) and get the same behavior.

@JamesPeters: Is your CPU load also increasing when making the time selection window shorter? If so, that would explain it. It seems to results in very sharp CPU load spikes leading to xruns. I played with the buffer numbers (Preferences -> Audio -> Buffering), but that made no change at all. Could you make a test with a bunch of U-he plugins (DIVA or Repro)?

Here's a short clip again: https://vimeo.com/345087420 Samples on the second track is 44.1 kHz, Samples on the third track is 48kHz.

Another thing: When I have an audio sample on a track and e.g. Repro-1 or Hive on the same track (without midi data). I get crackles (when playing with looped time selection) when I activate Repro-1. With deactivated Repro-1 it's fine. When using e.g. Dexed I don't see this effect.

Code:
marco@fox:~/src$ ./xruncounter 

******************** SYSTEM CHECK *********************

    Sound Playback: Loopback - Loopback
     Sound Capture: USB-Audio - ZOOM R8
      Graphic Card: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
  Operating System: Debian GNU/Linux 9 (stretch)
            Kernel: Linux 4.9.0-9-amd64
      Architecture: x86-64
               CPU: Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz

****************** jackd dbus running ******************


********************** Pulseaudio **********************

Connection failure: Connection refused
pa_context_connect() failed: Connection refused
    pulse is not active

********************** Test 1 Core *********************

Samplerate is 48000Hz 
Buffersize is 528 
Buffer/Periods  2
jack running with realtime priority 80
Xrun 1 at DSP load 98.51% use 10.39ms from 11.00ms jack cycle time		
in complete 1 Xruns in 44338 cycles                                  
first Xrun happen at DSP load 98.51% in cycle 44337
process takes 10.39ms from total 11.00ms jack cycle time
marco@fox:~/src$ ./xruncounter 

******************** SYSTEM CHECK *********************

    Sound Playback: Loopback - Loopback
     Sound Capture: USB-Audio - ZOOM R8
      Graphic Card: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
  Operating System: Debian GNU/Linux 9 (stretch)
            Kernel: Linux 4.9.0-9-amd64
      Architecture: x86-64
               CPU: Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz

****************** jackd dbus running ******************


********************** Pulseaudio **********************

Connection failure: Connection refused
pa_context_connect() failed: Connection refused
    pulse is not active

********************** Test 1 Core *********************

Samplerate is 48000Hz 
Buffersize is 528 
Buffer/Periods  2
jack running with realtime priority 80
Xrun 1 at DSP load 97.93% use 10.27ms from 11.00ms jack cycle time		
in complete 1 Xruns in 44322 cycles                                  
first Xrun happen at DSP load 97.93% in cycle 44309
process takes 10.27ms from total 11.00ms jack cycle time
__________________
https://soundcloud.com/lilith_93
https://open.spotify.com/intl-de/art...SMSwCW9VkqAN9Q
MX Linux, Behringer UMC 204 HD, Neumann KH120

Last edited by lilith93; 06-28-2019 at 01:01 PM.
lilith93 is offline   Reply With Quote
Old 06-28-2019, 02:39 PM   #6
JamesPeters
Human being with feelings
 
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
Default

Yes my CPU increases as I change the time selection and/or loop points (it seems similar to what CPU increase you're seeing in that last clip, only a few % CPU). RT CPU doesn't increase much though. It doesn't cause problems for me, unless I'm using plugins to the point where the CPU is near 90% already.

Have you tried another audio device? Also what port are you connecting that Zoom to. If it's USB3, that could be contributing to your problem (or just making your CPU use higher, and latency not as low as it could be). USB2 audio devices sometimes don't work well on USB3 ports. So be certain it's plugged into a USB2 port before doing anything else.

Sorry but I won't install U-He products to test this. I'm already testing with my CPU hitting 90%+ no matter what plugins I'm using (ReaPitch x55, for instance).

Good news though: I was able to reproduce this behavior, and I know more about why it happens now.

While I was typing this post I decided to try something very specific: make sure the loop start point was in motion as the playback was reaching the loop end point. That means Reaper might not be able to buffer properly for the start of the loop, since that point is constantly changing. I experienced the same issue when doing this. However it's not nearly as bad on my system. That's at least partly because I'm using a much smaller buffer than you are.

Remember that the audio has to be buffered as the loop starts again, so the larger the buffer the longer it takes for Reaper to be ready (completed filling the buffer) when the loop start point is moved. If you keep moving it, Reaper has to keep trying to buffer for a new loop start point every time. If your loop start point is moving in very small increments (or you're zoomed out a lot), this makes things worse, because Reaper tries to buffer every time the loop start point "snaps" to the grid. (If snapping is turned off, Reaper probably tries buffering at a fixed interval which is relatively small, so that's no good either.) Plus with a large buffer, Reaper is constantly buffering/stopping and starting buffering when the loop start is moved.

The problem was happening for you before playback hit the end loop point, because it was already starting to buffer for the next loop start point (it needs to be doing that more in advance than on my system, which isn't buffering as much). So for me to replicate that issue I had to very specifically try to move the loop start point just as playback was hitting the end loop point.

Notice how the issue was only happening when your playback was near the loop end point, or just after the loop re-started, and you were moving the loop start point. If you moved the loop start point while playback was in the middle of the loop, it was ok. That was a hint.

I recommend that you 1) set the buffer a lot lower, as I mentioned before, and 2) try to not be moving the loop start point when playback is near the loop end point. Also 3) if you're using plugins with high PDC, remember this can be making the problem worse.

I posted a bug report about this, recommending a change to Reaper's behavior to help avoid this problem in the future: add an option something like "if loop start point is currently being moved, start the next loop cycle using the previous loop start point to avoid playback glitches". Or to have some kind of tolerance which will only allow buffering during start loop point changes to happen within 1 second / 1 "buffer size" (whatever makes sense) but not smaller increments.

For now I think the solution is going to be: lower the buffer, and "don't do that anymore" as much as possible anyway.

There may be some other buffering setting in Reaper you can change to help, but I don't know what it would be. The main problem is your buffer size plus that specific thing you're doing.

Last edited by JamesPeters; 06-28-2019 at 03:57 PM.
JamesPeters is offline   Reply With Quote
Old 06-28-2019, 03:30 PM   #7
lilith93
Human being with feelings
 
lilith93's Avatar
 
Join Date: Apr 2018
Location: Karlsruhe
Posts: 486
Default

Thanks for your time Peter and doing the tests! It's exactly like you say. When I avoid moving the loop start when the playhead is close to the loop end point it works. Lowering the buffer size is not an option as I mostly use VSTs and I don't want to stress the CPU too much, because of the fan noise . I will file a bug report tomorrow. It's not a big deal, but if it happens while the volume is high it's a bit distracting

I have checked the USB port of the interface and it's connected to USB 2.

edit: I don't know if this is related, but someone at KVR mentioned that U-he plugin threads a re running with a very high RT priority, higher than that of Reaper. I also saw it this evening, but it's not always that high.
__________________
https://soundcloud.com/lilith_93
https://open.spotify.com/intl-de/art...SMSwCW9VkqAN9Q
MX Linux, Behringer UMC 204 HD, Neumann KH120
lilith93 is offline   Reply With Quote
Old 06-28-2019, 03:35 PM   #8
JamesPeters
Human being with feelings
 
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
Default

Glad to help!

I'd say that RT priority of the u-he plugins could be contributing to this, so maybe that could be changed (by u-he).

I just posted a bug report about this, so hopefully it gets changed in the future. There's no need for you to post a bug report now.
JamesPeters is offline   Reply With Quote
Old 06-28-2019, 03:39 PM   #9
lilith93
Human being with feelings
 
lilith93's Avatar
 
Join Date: Apr 2018
Location: Karlsruhe
Posts: 486
Default

Quote:
Originally Posted by JamesPeters View Post
Glad to help!

I'd say that RT priority of the u-he plugins could be contributing to this, so maybe that could be changed (by u-he).

I just posted a bug report about this, so hopefully it gets changed in the future. There's no need for you to post a bug report now.
Thanks!!! Where did you post it? I thought Linux Bugs is the right place, but I'm never sure if a bug affects all systems.
__________________
https://soundcloud.com/lilith_93
https://open.spotify.com/intl-de/art...SMSwCW9VkqAN9Q
MX Linux, Behringer UMC 204 HD, Neumann KH120
lilith93 is offline   Reply With Quote
Old 06-28-2019, 03:43 PM   #10
JamesPeters
Human being with feelings
 
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
Default

I was actually editing the post before hitting submit. It's on the bug report forum, not the Linux bugs thread.

https://forum.cockos.com/showthread.php?t=222466

It affects the Windows 64-bit version of Reaper too (I just tested it on my Windows laptop), so it's likely that's just the way Reaper works on all platforms.
JamesPeters is offline   Reply With Quote
Old 06-28-2019, 03:49 PM   #11
lilith93
Human being with feelings
 
lilith93's Avatar
 
Join Date: Apr 2018
Location: Karlsruhe
Posts: 486
Default

Quote:
Originally Posted by JamesPeters View Post
I was actually editing the post before hitting submit. It's on the bug report forum, not the Linux bugs thread.

https://forum.cockos.com/showthread.php?t=222466

It affects the Windows 64-bit version of Reaper too (I just tested it on my Windows laptop), so it's likely that's just the way Reaper works on all platforms.
Ok, thanks. Annoyed is a bit exaggerated, but that way it hopefully gets the right attention
__________________
https://soundcloud.com/lilith_93
https://open.spotify.com/intl-de/art...SMSwCW9VkqAN9Q
MX Linux, Behringer UMC 204 HD, Neumann KH120
lilith93 is offline   Reply With Quote
Old 06-28-2019, 03:58 PM   #12
JamesPeters
Human being with feelings
 
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
Default

It was only my interpretation of what was happening. Plus I'm sure someone is going to read my referring to you as "he" and say "why are you referring to Lilith as 'he'?"
JamesPeters is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 03:21 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.