10-04-2021, 07:32 AM | #1 |
Human being with feelings
Join Date: Nov 2011
Posts: 971
|
[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. |
10-04-2021, 07:45 PM | #2 |
Human being with feelings
Join Date: Jun 2018
Posts: 850
|
Thanks for the heads up
|
10-05-2021, 07:02 AM | #3 |
Human being with feelings
Join Date: Sep 2020
Posts: 119
|
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. |
10-05-2021, 08:06 AM | #4 | |
Human being with feelings
Join Date: Nov 2011
Posts: 971
|
Quote:
|
|
10-05-2021, 09:33 AM | #5 |
Human being with feelings
Join Date: Jun 2012
Location: Spain
Posts: 7,239
|
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 |
10-05-2021, 10:03 AM | #6 |
Human being with feelings
Join Date: Sep 2019
Location: Finland
Posts: 758
|
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...
|
10-05-2021, 02:58 PM | #7 | |
Human being with feelings
Join Date: Nov 2011
Posts: 971
|
Quote:
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/ |
|
Thread Tools | |
Display Modes | |
|
|