Future Linux audio hardware Interface support

[finotti]

In the news today, Intel is still putting some weight behind TB it seems. For the better or worse they're gonna put the TB3 controller on die:
https://arstechnica.com/gadgets/2017/05 ... -adoption/

Does any one have any insight if this will (positively) affect the possibility of support for TB3 in Linux?

On an older post:

USB 2.0 is capable of delivering the speed necessary to move audio in and out of a computer. USB 3.0 would increase the bandwidth, but being USB 2.0 can handle 32 channels in and 32 out, that satisfies the requirements of most people using USB audio interfaces. If you need more than 32 channels in either direction or work with high sample rates, I think there are professional audio equipment options (Thunderbolt, AVB, etc.) that are preferred over USB for latency and stability. Unfortunately, Linux compatibility on those devices is rare, if it exists at all.

I probably just don't understand how things work, but if USB 2.0 is good enough, why can't I record with "low" latency (4ms) when I have plugins in Ardour (when I only realize I need to rerecord something in the mixing process) without a milling xruns. Even with no plugin, (jack with 3 periods, 48K/256) has more xruns that I would like. (Most of the time, when I go back and listen to it I see no problem, though.) And when I tried to use Carla to load amp simulations, I had constant xruns...

Since the machine is not weak (i7-4771, 16GB of RAM, SSD) and "optimized" for audio (as in http://wiki.linuxaudio.org/wiki/system_configuration), I was blaming the interface (Focusrite 2i2 2nd generation). Am I wrong? USB 3.0 or TB3 would not help with that? (In that case, where is my system failing? CPU? Memory?)

[folderol]

There is something really odd about your setup.
Here, I can run a KA6 at 48k, 64 frames, 2 periods - showing 2.67mS
Then have Rosegarden spit 16 channels to Yoshimi, with some pretty heavy duty patches and not get a single Xrun

[asbak]

I probably just don't understand how things work, but if USB 2.0 is good enough, why can't I record with "low" latency (4ms) when I have plugins in Ardour (when I only realize I need to rerecord something in the mixing process) without a milling xruns. Even with no plugin, (jack with 3 periods, 48K/256) has more xruns that I would like. (Most of the time, when I go back and listen to it I see no problem, though.) And when I tried to use Carla to load amp simulations, I had constant xruns...

Since the machine is not weak (i7-4771, 16GB of RAM, SSD) and "optimized" for audio (as in http://wiki.linuxaudio.org/wiki/system_configuration), I was blaming the interface (Focusrite 2i2 2nd generation). Am I wrong? USB 3.0 or TB3 would not help with that? (In that case, where is my system failing? CPU? Memory?)

Most of the guides floating around about Linux Audio OS configuration were written years ago, the information is out of date, poorly presented, not always relevant, sometimes based on fallacies and popularly repeated nonsense, sometimes lacking, confusing, contradictory, incomplete ... I could go on. It takes ages to work one's way through all the possibilities, to understand what is affected by what and to discard the rubbish and keep what's relevant.

The easiest way to get a rough idea about what ballpark you're in is to install something like AVLinux on a spare drive and to try again. AVLinux already has most of the OS optimisation work done for you. If the xruns magically decrease or disappear it's a clear indication that your OS is poorly configured.

If not, the problem would more likely be with the hardware you're using. Such problems can sometimes be remediated by changing various BIOS settings, by adjusting USB port settings in BIOS, by flashing a later firmware on the soundcard and so forth. USB3 doesn't work well with Linux Audio. There should be a way to set the ports to USB2 for use with audio hardware.

The hard reality is that there are many factors which conspire against the Linux Audio user and until one overcomes all of them - through blind luck, through due diligence or through skill - things probably won't work as well as they should.

[CrocoDuck]

USB3 doesn't work well with Linux Audio.

Not to be confrontational, but I am afraid that this falls into this category:

based on fallacies and popularly repeated nonsense

I think that the conviction that USB3 is not good for Linux audio originated at the early times of USB3 support. Most of the problems should be ironed out now. USB tend to give troubles when multiple devices (wifi card, mouse, keyboard, webcam...) are all served by the same USB hub, which tend to produce interrupts. Actually it would be advisable to try an USB3 port for audio, as it is usually on its own, so it is less likely to have conflicting hardware communicating with the chipsets controlling it.

Anyway I see what you mean, and I agree. I don't really know anymore what is effective for audio configuration and I lack the time to investigate into it. I wish I could go on a quest to try updating the documentation with some proper quantitative testing. Something we started discussing some time ago.

[autostatic]

Most of the guides floating around about Linux Audio OS configuration were written years ago, the information is out of date, poorly presented, not always relevant, sometimes based on fallacies and popularly repeated nonsense, sometimes lacking, confusing, contradictory, incomplete ... I could go on. It takes ages to work one's way through all the possibilities, to understand what is affected by what and to discard the rubbish and keep what's relevant.

That's exactly what http://wiki.linuxaudio.org/wiki/system_configuration tries to do, even after all those years. I still think it is the most complete guide out there to get your machine in shape for doing Linux audio.

[gimmeapill]

@finotti

Does any one have any insight if this will (positively) affect the possibility of support for TB3 in Linux?

If TB3 gets widespread support in the industry it will eventually be supported on Linux (unless something fishy with IP/licensing terms maybe). Then more audio devices will show up, and TB for audio on Linux *should* happen as well. The question is when
Intel's push seems to be in the right direction, but I wouldn't realistically expect anything for us within 2 years or so (my crystal ball is a bit dirty, sorry for that).

Oh, and +1 with CrocoDuck on USB3: Most of the gloom and doom comes from an era when drivers were still quite young.
USB3 is a safe default nowadays, and USB2 as fallback in case of HW/SW incompatibility (= business as usual for Linux users).

Regarding your latency issues, as Folderol pointed out there's probably something else: the 2i2 2nd gen should be one of the most capable interfaces latency wise.

First check you hardware:
- Connect it to your fastest usb port (this might require some trial and error or even finding the blueprint of your motherboard to avoid internal hubs)
- No external hub (this goes without saying)
- try another usb cable
- disconnect anything else USB - at least during testing

On the SW side:
- To make sure you didn't forget anything during the tuning steps, start with Raboof's quick scan https://github.com/raboof/realtimeconfigquickscan
- Trying AV linux or any other audio optimized live distro could indeed be a good idea, even if just to ensure you're getting consistent results
- Then, generally speaking, the lighter the better.
Consumer distros with full blown DEs using graphically accelerated interfaces are not necessarily the best thing for low latency audio.
Not to say they don't work, but at least during troubleshooting, you may want to trim some fat, just to get this out of the way.
- Same logic at the application level: do some A/B testing between hosts with the same plugins, try different plugins with the same functionality.
Maybe some of those amp sims are totally allergic to real time?
On the host side I personally found Ardour to be unsuitable for really low latency configurations, whereas Qtractor does usually better in terms of xruns, but of course it doesn't offer the same level of functionality - ymmv.

But please open a separate thread if you want to do more troubleshooting, we're drifting off topic here

[wjl]

If TB3 gets widespread support in the industry it will eventually be supported on Linux (unless something fishy with IP/licensing terms maybe). Then more audio devices will show up, and TB for audio on Linux *should* happen as well. The question is when
Intel's push seems to be in the right direction, but I wouldn't realistically expect anything for us within 2 years or so (my crystal ball is a bit dirty, sorry for that).

It says "next year Intel plans to make the Thunderbolt protocol specification available to the industry under a nonexclusive, royalty-free license." in https://newsroom.intel.com/editorials/e ... verywhere/

Whatever that means. They should do the right step and open source it if they want wide adoption.

[asbak]

USB3 doesn't work well with Linux Audio.

Not to be confrontational, but I am afraid that this falls into this category:

based on fallacies and popularly repeated nonsense

I think that the conviction that USB3 is not good for Linux audio originated at the early times of USB3 support. Most of the problems should be ironed out now. USB tend to give troubles when multiple devices (wifi card, mouse, keyboard, webcam...) are all served by the same USB hub, which tend to produce interrupts. Actually it would be advisable to try an USB3 port for audio, as it is usually on its own, so it is less likely to have conflicting hardware communicating with the chipsets controlling it.

Anyway I see what you mean, and I agree. I don't really know anymore what is effective for audio configuration and I lack the time to investigate into it. I wish I could go on a quest to try updating the documentation with some proper quantitative testing. Something we started discussing some time ago.

Fair enough, if USB3 works better now for most people then more power to them. I still avoid using it, simply because I have the luxury of USB2 ports available to me.

Otoh, I have no problems with running WIFI at the same time as audio, an issue which seems to affect many people. So mileage varies.

Imo both USB3 and WIFI are potential causes of major issues which can be worked around by disabling them. Not an ideal solution but at least something to get up and running with initially.

[asbak]

That's exactly what http://wiki.linuxaudio.org/wiki/system_configuration tries to do, even after all those years. I still think it is the most complete guide out there to get your machine in shape for doing Linux audio.

It's a decent guide and a good starting point but it could really do with a major update, additions and a re-write. Good effort though.
My personal view is that beginners are still going to struggle for the most part, even when consulting that guide.

And even if one wrote the world's most perfect guide a user may not necessarily interpret and apply it correctly. It is so easy to forget or miss something or misinterpret it or to be caught out by an unusual caveat.

Hence why imo a pre-baked distro is the quickest and potentially more reliable way to eliminate potential software configuration issues as the culprit when it comes to poor audio performance.

[finotti]

First of all, thanks all for the helpful replies.

There is something really odd about your setup.
Here, I can run a KA6 at 48k, 64 frames, 2 periods - showing 2.67mS
Then have Rosegarden spit 16 channels to Yoshimi, with some pretty heavy duty patches and not get a single Xrun

OK, I've put the wrong number there. (Those were the higher latency settings I use to edit/mix.) I run 48k, 64 frames, 3 periods (about 4ms latency). As I said, I have more xruns than I would expect (with minimal plugins) in that set up (but not a major problem, as usually they are not audible in the recording), and many if I have a lot of plugins loaded on Ardour. The most frustrating part is that I cannot run LePou amp sims in Carla is impossible due to the xruns (with the settings above).

I'd like to thank again all that replied. It seems I will need to take sometime to figure out how to improve my system.

And sorry for taking the thread away from its topic. Any further question comment I may have will be in a new topic.

[MGdesigner]

First of all, thanks all for the helpful replies.
OK, I've put the wrong number there. (Those were the higher latency settings I use to edit/mix.) I run 48k, 64 frames, 3 periods (about 4ms latency).

My audio interface is Alesis IO2 Express. I can record in : 48000hz, 128 frames,3 periods without xruns. The latency is 2.7ms . My CPU is 2010 Sandy intel core i5-540M.

I think you may need to check :
1.if your kernel is realtime or low-latency one?
2. Was your audio realtime priority set?

[finotti]

First of all, thanks all for the helpful replies.
OK, I've put the wrong number there. (Those were the higher latency settings I use to edit/mix.) I run 48k, 64 frames, 3 periods (about 4ms latency).

My audio interface is Alesis IO2 Express. I can record in : 48000hz, 128 frames,3 periods without xruns. The latency is 2.7ms . My CPU is 2010 Sandy intel core i5-540M.

I think you may need to check :
1.if your kernel is realtime or low-latency one?
2. Was your audio realtime priority set?

Thanks for the reply. No for 1, yes for 2. I did install Debian's linux-image-rt-amd64 kernel, but did not notice much difference (at the time). From what I understand (quotes from the kernel developer), "quite a lot of -rt improvements have been merged into the normal kernel over the years" and the kernel I'm using (slh's from aptosid) "uses HZ_1000 and NO_HZ, that should get quite a long way" (again from what I was told).

What seems to have helped recently was using fluxbox instead of KDE. But it seems inconsistent. Some days I have no xruns at all, some I have a few (on the same project). I definitely need more experimenting, including trying the RT kernel more.

Thanks again!

[MGdesigner]

Thanks for the reply. No for 1, yes for 2. I did install Debian's linux-image-rt-amd64 kernel, but did not notice much difference (at the time). From what I understand (quotes from the kernel developer), "quite a lot of -rt improvements have been merged into the normal kernel over the years" and the kernel I'm using (slh's from aptosid) "uses HZ_1000 and NO_HZ, that should get quite a long way" (again from what I was told).

What seems to have helped recently was using fluxbox instead of KDE. But it seems inconsistent. Some days I have no xruns at all, some I have a few (on the same project). I definitely need more experimenting, including trying the RT kernel more.
Thanks again!

There are diferent levels about "realtime".

Realtime kernels (hard realtime )are patched by RT-patch. Low-latency kernel (soft realtime) are built from normal kernel source code with more aggressive configuration to further reduce latency. Usual kernels' names which are without realtime,low-latency,PREEMPT, they are just generic kernels.

About WM like KDE or fluxbox, I think it's not very important issue. For example,my system is KXstudio,but my desktop is mate+compiz(I love eye candies ), I can record or realtime play my electronic instruments with Rakarrack or Guitarix (realtime amp +pedals simulation) withour xruns.

ex:my Lovin' You cover

My cpu is just 2010 Core i5,not as good as your Core i7. You computer shouldn't get so many xruns. I think in your situation, the kernel is the main issue.