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

Reply
 
Thread Tools Display Modes
Old 10-04-2021, 07:32 AM   #1
audiojunkie
Human being with feelings
 
audiojunkie's Avatar
 
Join Date: Nov 2011
Posts: 971
Default [NEWS] Linux 5.16 Aims For Better USB Low-Latency Audio Playback

https://www.phoronix.com/scan.php?pa...6-USB-Audio-LL

Linux 5.16 Aims For Better USB Low-Latency Audio Playback

The Linux kernel is trying again to enhance the low-latency playback mode of its USB audio driver.

Takashi Iwai of SUSE who oversees the Linux kernel's sound subsystem and has been responsible for many of the sound improvements to the kernel drivers over the past number of years has taken a fresh stab at enhancing the low-latency playback support.

Takashi explained with one of the patches, "This is another attempt to improve further the handling of playback stream in the low latency mode. The latest workaround in commit 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback") revealed that submitting URBs forcibly in advance may trigger XRUN easily. In the classical mode, this problem was avoided by practically delaying the submission of the actual data with the pre-submissions of silent data before triggering the stream start. But that is exactly what we want to avoid. Now, in this patch, instead of the previous workaround, we take a similar approach as used in the implicit feedback mode. The URBs are queued at the PCM trigger start like before, but we check whether the buffer has been already filled enough before each submission, and stop queuing if the data overcomes the threshold. The remaining URBs are kept in the ready list, and they will be retrieved in the URB complete callback of other (already queued) URBs. In the complete callback, we try to fill the data and submit as much as possible again. When there is no more available in-flight URBs that may handle the pending data, we'll check in PCM ack callback and submit and process URBs there in addition. In this way, the amount of in-flight URBs may vary dynamically and flexibly depending on the available data without hitting XRUN."

These USB-audio driver patches were queued into the sound subsystem's "-next" branch ahead of the 5.16 merge window opening next month. This low-latency playback code should particularly help JACK use-cases with its small period size. The latest usb-audio driver improvements are in sound for-next.
audiojunkie is offline   Reply With Quote
Old 10-04-2021, 07:45 PM   #2
pax-eterna
Human being with feelings
 
Join Date: Jun 2018
Posts: 850
Default

Thanks for the heads up
pax-eterna is offline   Reply With Quote
Old 10-05-2021, 07:02 AM   #3
fsynth
Human being with feelings
 
Join Date: Sep 2020
Posts: 119
Default

Amazing how far Linux has came for audio already and they are still trying to improve :-)
After hearing the latency people have been getting with the Behringer USB boxes I had to try.
Got the UMC204HD can run 64 samples 2.6ms reported by Reaper using ALSA on both an i5 and a little RPi4 with no drop outs, life's good.
fsynth is offline   Reply With Quote
Old 10-05-2021, 08:06 AM   #4
audiojunkie
Human being with feelings
 
audiojunkie's Avatar
 
Join Date: Nov 2011
Posts: 971
Default

Quote:
Originally Posted by fsynth View Post
Amazing how far Linux has came for audio already and they are still trying to improve :-)
After hearing the latency people have been getting with the Behringer USB boxes I had to try.
Got the UMC204HD can run 64 samples 2.6ms reported by Reaper using ALSA on both an i5 and a little RPi4 with no drop outs, life's good.
Yep, and the work is continuing on mainlining the RT patches. When that finally gets done, there will be no need for special RT kernels. Vanilla kernals will have full RT functionality. :-) Kernel 5.15 got more real time patches mainlined, and now 5.16 will have lower USB audio device latency. It's slow, it it is steadily progressing. :-)
audiojunkie is offline   Reply With Quote
Old 10-05-2021, 09:33 AM   #5
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 7,239
Default

Indeed it is amazing
my USB interface already works great.. I don't know what else they want to optimize. I hope they don't break something else with something that already works well for old USB devices
heda is offline   Reply With Quote
Old 10-05-2021, 10:03 AM   #6
elcalen
Human being with feelings
 
elcalen's Avatar
 
Join Date: Sep 2019
Location: Finland
Posts: 758
Default

My question, as someone who doesn't really understand a whole lot about the nuts and bolts of how this all works, is if these improvements make any difference for those of us *not* working with low latencies? As someone who mostly makes music with software synthesizers and lots of FX, I need CPU power much more than I need low latency, so typically set my buffer size as big as it goes...
elcalen is online now   Reply With Quote
Old 10-05-2021, 02:58 PM   #7
audiojunkie
Human being with feelings
 
audiojunkie's Avatar
 
Join Date: Nov 2011
Posts: 971
Default

Quote:
Originally Posted by elcalen View Post
My question, as someone who doesn't really understand a whole lot about the nuts and bolts of how this all works, is if these improvements make any difference for those of us *not* working with low latencies? As someone who mostly makes music with software synthesizers and lots of FX, I need CPU power much more than I need low latency, so typically set my buffer size as big as it goes...
Here's the short answer. If you don't work in the realm of real time at all, then it is not important. An example of this would be a musician who inputs notes into a sequencer one at a time by clicking the mouse. Then, pressing play on the sequencer to listen to the music you sequenced. However, if you are doing any kind of music work that involves real time, then it becomes very important, for example actually playing an instrument through software synthesizers and effects, singing, recording midi or audio, playing in time with one another, etc.

Long version (requires reading & research):

Note: the following is based off of numerous sources found across the internet and is not my own work or descriptions

There is always a cost. You get low latency (responsiveness) at the cost of throughput. In general, vanilla Linux kernels are configured for as much throughput as possible. In other words, they are configured (tuned) for Server-type operations where high throughput is valued much more than low latency.

In desktop situations, low latency is valued equally as much as throughput, and so it is best for desktop systems to be tuned differently than servers. The goal here is to have the best configuration for desktop, multimedia, and gaming workloads. An example of this is the Zen kernels (Liquorix kernels), who tune the kernel for responsiveness at the cost of throughput and power usage.

Real Time configuration is where you have the goal of having the lowest latencies possible, at the cost of throughput. Examples of use cases could be, automotives, Airline traffic control systems, Command Control Systems, Airlines reservation systems, Heart Pacemakers, Network Multimedia Systems, Robotics, cameras, complex multimedia animation systems, and communications.

So, why is this important?

Here are some quick links that explain it better than I could:

https://en.wikipedia.org/wiki/Latency_(audio)

https://transverseaudio.com/tip/what...sic-production

https://www.sweetwater.com/sweetcare...n-my-computer/

https://www.practical-music-producti...audio-latency/
audiojunkie 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 07:45 AM.


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