Linux Users, What's You Distro Experience?

[Tiles]

Um, this is how you set it up. You can set this values to whatever you want. I talk about the real performance. So i misunderstood what you wrote above. I thought you have really tested it. My mistake.

[Guenon]

Tl;dr: no trusting threads like this for making informed decisions on topics like this. Too much bias, and too much trying to win a debate instead of staying level-headed and checking out the actual situation and facts.

JACK uses ALSA'S MMAP mode. So do linux pro audio apps, which can be set to use ALSA directly, such as Ardour, QTractor, Muse, the linux version of Bitwig, etc.

I wanted to emphasize this as there's some (intentional?) confusion on a legacy emulation layer playing some part in any of this. Having used both Windows and Linux on my main RME workstations, I've come to the conclusion that the (superb) latencies I'm getting are exactly the same, and I can just concentrate on working, no matter which system is in use. I've used both systems extensively for quite a bit of professional work, and as the GUIs of the software environments themselves (Reaper, Bitwig, Renoise) are 1:1 the same, it's easy to even forget which operating system is running, hah.

There is in fact an extra software emulation layer under the ALSA driver that does not exist for ASIO or the solution at Mac. And i repeat, you cannot outsmart physics. There is no wormhole that goes directly to the hardware.

We talk about the OSS Emulation module here. Where we disagree is if this plays a significant role.

This is, at the very least, misleading (probably intentionally), and inconsequential in today's professional audio software landscape. If intentional, it's not really honest saying something like "There is in fact an extra software emulation layer under the ALSA driver", based on OSS emulation existing. None of the DAWs mentioned use OSS emulation in any way, and it doesn't come into play in modern software like that, at all.

This is a compatibility layer for an older audio standard, used for running legacy solutions that happen to rely on it, and it doesn't reflect on the performance of modern working environments in any way. It simply isn't there, from the standpoint of someone using a modern DAW system.

If being sceptical, one can even check from /proc/asound/oss whether any emulation has been aggregated on your workstation when working in your DAW of choice.

Google for the software architecture of ALSA. UNDERSTAND what you read.

More unfortunate is reading documentation like this, on the surface level, in order to have just enough fodder to seem knowledgeable, for the sake of debating something like this, and then using that for writing biased descriptions that sound technically proficient to someone not experienced in the topic.

The bias shows a lot, for example not questioning different buffer settings when doing latency comparisons (!), and just rolling with it because it suits your bias:

I am not on a quest. But i love truth and facts.

So i learned something here, which i love. Thanks again for the tests EnGee.

In this case you'll love the comparison also when buffer-matched:

I have just tested Bitwig on the three systems and it is the same on the three OSes

When being presented with technical details from someone who has extensive knowledge in the inner workings of these systems, this is the tone:

Either way, thanks for the details. Even when imho some of it is more wishful thinking and theory it's for sure of interest for some.

Sums up why this is not the place for discussing some technical matters. If one "loves truth and facts", and has a passion for audio technology and working in this field... then get your actual truth and actual facts, actual professional discourse, from somewhere else - without the noise

[Guenon]

Um, this is how you set it up. You can set this values to whatever you want. I talk about the real performance. So i misunderstood what you wrote above. I thought you have really tested it. My mistake.

[Tiles]

... I've come to the conclusion that the (superb) latencies I'm getting are exactly the same ...

Also for the audio interface? And is it more a feeling or a real testing result?

A test could be in Reaper to have the same instances of the same plugin running and add them in the mixer until it starts to crackle. Reverbs are usually resource hogs. But this doesn't take hardware like an audio interface into account. And at Linux it is hard to test all the vst's that are at Linux simply not available. Kontakt for example.

Sums up why this is not the place for discussing some technical matters. If one "loves truth and facts", and has a passion for audio technology and working in this field... then get your actual truth and actual facts, actual professional discourse, from somewhere else - without the noise

I have yet to find a place where you can really talk about Linux in any unbiased manner. There will always be noise. But we have to start somewhere.

[j_e_g]

We talk about the OSS Emulation module here. Where we disagree is if this plays a significant role.

This is a code path that isn't even taken by linux apps that don't use OSS, and therefore of absolutely no relevance to performance of such. (In fact, the kernel defaults to being compiled without this "software emulation layer" included. So most distros don't even include it, because OSS is so obsolete on linux. It has been many years since I've seen a linux app that used it).

I strongly urge you to abandon your "conclusion" because it is 100% factually incorrect, and undermines any confidence that you're arguing from a factual perspective.

There are definitely things to complain about ALSA. But your false depiction of OSS emulation affecting latency of today's linux audio support is definitely not pertinent.

But as tests from EnGee has shown, ALSA is as a matter of fact simply slower than ASIO.

Tests I've made with my own software/hardware have shown the opposite. But as with EnGee's tests, extrapolating any blanket conclusions about all other test configurations based upon my solitary setup would be unjustified and just plain silly.

I would hope you realize why. If not, I can't continue discussing this with you under the assumption you're arguing from a factual perspective.

And the reason can be found in exactly this design.

Just... no.

No argument will make ALSA any faster than how it is.

This is such an obvious observation. Here's another version of the above:

"No false conclusion about ALSA will make it any slower."

there is a fast and slow ALSA mode... <and>... usually the software decides which one to use. That's not a switch a user can turn on or off.

Um, yes it is. Linux apps that support using a variety of APIs (and the majority of music apps on linux will do so -- even many non-music apps support a choice of sound APIs) wll have a way for the user to choose. For example, my BackupBand program allows the user to choose either JACK, or ALSA MMAP for sound playback.

Most software will connect through Jack by default, or even require it.

This is factually incorrect. Jack is used almost exclusively by music apps. The vast majority of linux apps currently use PulseAudio (which can be "bridged" to output through JACK, but that's another, entirely separate discussion). And before you go there. let me point out that any implication, that PulseAudio affects the latency of programs that don'r use it, would be factually incorrect.

ASIO to Jack will most probably not work with ALSA directly

I should hope not, since there is no such thing as "ASIO to Jack" on linux. ASIO is available only on Windows and Mac operating systems.

My needed software is simply not (natively) available at Linux. End of road.

That's your prerogative to decide. But I don't see why you therefore need to further justify your decision with additional, factually incorrect conclusions.

Pipewire is in fact in a sad state. ,,, the bottleneck is also here ALSA.

Again, this is not correct. Pipewire's poorer latency than JACK is entirely due the fact that a major goal of JACK's design was low latency (although frankly I think that part of its design, namely process switching, defeats that goal), whereas that was not a goal of Pipewire. In fact, Pipewire's first release didn't even implement a pull (versus push) model of I/O, and had to be retrofit with that after musicians complained about the dreadful deterioration of latency under Pipewire's JACK emulation.

Pipewire's main goal is audio synchronization (especially with video), not low latency. And no amount of tweaking to its design is ever going to change that fundamental impediment to latency.

Again, I have to question the basis for conclusions you're making about linux (and windows) audio stacks, given the factual inconsistencies in your analysis.

I recommend you stick with simply "There isn't a Linux version of Kontakt, and because I require that specific application, I therefore cannot run linux". This is factually acceptable. The other stuff... well... run away from it.

I was just triggered by the claim that ALSA is faster than ASIO at Windows

It _can_ be. But that depends upon the particular hardware/software you're using. It can be slower. It can be faster. And/or the difference could be so negligible that you could consider it comparable. It depends.

which it can't be by design

Incorrect.

since ASIO operates a tad bit closer to the hardware.

Incorrect.

Facts are more important to me

Then you have a good reason for not continuing to arrive at false conclusions.

important to understand the limits of the system that you are using.

Absolutely.

But some of the "conclusions" you've stated are not factually correct.

Is there something in my reply which you can identify as factually incorrect?

If not, I recommend you reevaluate your conclusions.

[Scrubbing Monkeys]

Last night I was able to connect a Fender Mustang headphone sim as a usb interface and got 64 sample latency using Reaper native and Alsa without Jack or Pulse Audio. Freaking amazing.

[glokraw]

One of these, I suspect? Amazing tech for the budget these days!

https://www.sweetwater.com/store/detail ... lsrc=aw.ds

[glokraw]

ASIO is available only on Windows and Mac operating systems.

wineasio has been around linux in wine for 15 years or so, (a small niche vs the Steinberg hordes ) and if installed, and will show up as an option in asio driver selection dialogs in most software that has them. I've used it that long, with Reaper before their linux ports, with SampleTank and Kontakt standalones etc. A historic reference:

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

I still use wineasio in windows Reaper via wine-staging, when that works better than linux Reaper,
which isn't all that often, but a great option to have. To me, efficient use of cpu cores/threads in daws and executables is more important than latency, which has been a non-factor for guitars, since Amplitube 2 or so. Not that I know anything about how cores/threads spend their free time I appreciate your long detailed reply, with the credibility coming from someone who actually creates software and understands what's going on in linux audio.
Cheers

[j_e_g]

wineasio has been around linux in wine for 15 years

wineasio is _not_ an implementation of ASIO on linux (any moreso than WINE is an implementation of the Windows operating system running on linux).

wineasio is a translation layer that intercepts ASIO function calls and diverts them to ALSA.

And evaluation of the performance of wineasio is completely invalid if applied to ASIO itself.

Let's not muddy the waters here.

efficient use of cpu cores/threads in daws and executables is more important than latency

Right, There's very good reason why this could be so. Like I said, generic computer operating systems are complex entities with a lot of moving parts that affect each other.

There is definitely a lot more to affect performance than just latency.

[j_e_g]

got 64 sample latency using Reaper native and Alsa without Jack or Pulse Audio.

I'm not surprised. For years and years and years, I've been telling linux musicians to eschew JACK (and programs that can use only JACK), in favor of apps that use MMAP directly. I've also tried to champion the use of plugins as a way of extending the features of software, as opposed to wiring up bits and pieces of software via JACK.

And for _all that time_, I've almost universally gotten responses of "MMAP direct versus JACK makes no difference, and anyway, it's more useful to spend weeks figuring out how to connect things with a 'session manager' rather than spend seconds loading a plugin".

So what has happened during the course of those years? Well, linux music devs/consumers finally figured out what I had realized years before. Devs added MMAP direct mode to music apps, and started packaging their software in plugin format (mostly LV2), and consumers realized that it's far easier and more reliable to setup using MMAP direct and plugins, plus the performance can't be beat.

Now serious linux musicians use MMAP and plugins en masse. JACK is becoming irrelevant, like how I predicted it would years ago, and was hostiely demonized for that prediction.

If linux devs/consumers had followed my advice at the start, the linux audio support/market would be 2 to 3 times more advanced than it is now.

But that time wasn't wasted. I acquired a valuable skill -- the ability to predict the future. (It's all about being skeptical, applying logic to what you see/hear, and if something doesn't make sense, investigate it for yourself. When you continually do that, you develop what I call "the ability to recognize patterns of success and failure". And then you start looking at things and saying "I can see where this is going". And before long, you're predicting the future).

Yes I can predict the future, Here's a prediction:

Everyone reading this thread will die alone.

Now it's time to cash in on my ability, so I'm proud to announce my latest capitalistic exploitation, a psychic telephone hotline service designed for professional musicians called "Psychic Musician Buddy".

Call 1-666-666-6666 to talk to one of my "psychic buddies" (ie, all my nephews/neices working under sweatshop slave conditions, and reading from a script I provide to them). For $20 per minute, you can get answers to all your questions such as:

"Will CLAP be a successful audio plugin standard?"

"Will it be discovered that the AI Assistant in the next version of Microsoft Windows surreptitiously films me pleasuring myself to some porn website, and then uploads my video to every site I visited?"

"Will Apple continue stealing other peoples' ideas, repackaging those ideas in some visually attractive case, and then adding an exhorbitant price markup?"

Well ok, that last prediction _everyone_ should be able to make.

Call today. And if you're one of those .01 % of people who learned how to predict the future (and you know you're arrogant enough to assume that you are) and don't need the basic service, then you can ask for an alternate service. My nephews/neices will read from a second script I provide them. But _that_ service will cost you $500 per minute. That's still a bargain. Just ask Bill Clinton or Bill Gates. SPECIAL OFFER: Patrons named Bill can apply for a group discount.

P.S. If you want to investigate linux music apps, get a copy of AV Linux distro, and try BackupBand (https://sourceforge.net/projects/backupband/files). It's fun. It's free. And best of all, it contains no CIA-financed mind-control techniques designed to hypnotically "program" you to commit a political assassination. Probably.

[Tiles]

And now a quote battle? Really?

since ASIO operates a tad bit closer to the hardware.

Incorrect.

This alone lets me stop any further discussion. I told it before, i am not interested in ideology blah blah or propaganda lies. And this is one. There is simply no loophole through the extra software layer that you eagerly want to discuss away here. That's not how it works.

ALSA is speedwise comarable with Directsound if even. It is by classes and design slower than ASIO. ASIO is highly optimized to have low latency. ALSA not. It never was, it never will be. Jack was the one, but Jack sits on top of ALSA. Pipewire was the one, but also Pipewire sits on top of ALSA. Pulseaudio was another attempt, and guess what, it sits on top of ALSA. Now tell me how something can become fast when it sits on top of something slow? And brings its own latency too? That's what you try since several pages now.

ALSA did not magically upgrade in the last years from one of the slowest audio drivers to one of the fastest. Since the architecture is still the same, nothing has changed at the architecture and how it is used.

Interestingly nobody wants to do some tests and come up with facts. In fear that i could be right? You missed a chance here.

To let ChatGPT speak: In terms of latency, ALSA is generally slower than ASIO. You don't believe me anyways, so ask ChatGPT why. It can even explain you the finest details and reasons.

And for those who doesn't even know what ASIO is and what the fuzz is about: https://www.sweetwater.com/sweetcare/ar ... e-drivers/

Steinberg designed this format to improve latency performance and channel count compared to Windows Audio drivers. ASIO (Audio Stream Input Output) allows the software to bypass Windows Audio and gives direct communication to the hardware.

Direct is the key here. Compared to the already two software layers of Jack and ALSA. Whith ALSA having yet another compatibility layer underneath by design. I told it before, you can't outsmart physics. Not with all propaganda and quote battles in the world.

[dellboy]

Anyway, for the best usage (for me) it is on Mac, as when I switch to YouTube (for example), I can hear the sound normally, but in Linux (Alsa), I must quit Bitwig and in Windows the ASIO driver for Tascam is problematic in Bitwig especially (I must quit Bitwig and run Reaper (or other DAW) to free the sound driver!). Although, it doesn't happen with another two ASIO drivers for another Audio interfaces! I have another glitches with Tascam ASIO driver, but it doesn't occur all the times!

I have Mint Linux on an external drive,and had the same problem as you have, not being able to use Bitwig and listen to YouTube at the same time. I heard that the latest Mint Linux now has Pipewire, so I used the upgrade tool and installed version 22. I am now able to use Bitwig with decent latentcy,and listen to Youtube simultaneously. In fact, I can now play and listen to piano on my external keyboard, and use a midi controller to play a plugin, and listen to Youtube all at the same time through my headphones. Impressive.

[EnGee]

Anyway, for the best usage (for me) it is on Mac, as when I switch to YouTube (for example), I can hear the sound normally, but in Linux (Alsa), I must quit Bitwig and in Windows the ASIO driver for Tascam is problematic in Bitwig especially (I must quit Bitwig and run Reaper (or other DAW) to free the sound driver!). Although, it doesn't happen with another two ASIO drivers for another Audio interfaces! I have another glitches with Tascam ASIO driver, but it doesn't occur all the times!

I have Mint Linux on an external drive,and had the same problem as you have, not being able to use Bitwig and listen to YouTube at the same time. I heard that the latest Mint Linux now has Pipewire, so I used the upgrade tool and installed version 22. I am now able to use Bitwig with decent latentcy,and listen to Youtube simultaneously. In fact, I can now play and listen to piano on my external keyboard, and use a midi controller to play a plugin, and listen to Youtube all at the same time through my headphones. Impressive.

Your post is just in time! Thank you! Yesterday I downloaded version 22 and prepared a usb stick to boot it but then wasn't sure of upgrading my stable Mint/Alsa/Bitwig setup.

How did you upgrade? I read the quick guide and there wasn't a path for upgrading, just to delete what I have and install Mint 22 from scratch (i.e. no upgrade option if I boot the PC with the usb stick). So, do I need to install everything again after installing Mint 22 to the Mint 21 partition (Bitwig, u-he, TAL, ...etc)?

I'm also curios if Studio One Pro (beta) would install and function in Mint 22. For the current one I have, I couldn't install it because of some library lacking (dependency problem).

[Edit]
I found this video. I will give it a go tomorrow

[dellboy]

Your post is just in time! Thank you! Yesterday I downloaded version 22 and prepared a usb stick to boot it but then wasn't sure of upgrading my stable Mint/Alsa/Bitwig setup.

How did you upgrade? I read the quick guide and there wasn't a path for upgrading, just to delete what I have and install Mint 22 from scratch (i.e. no upgrade option if I boot the PC with the usb stick). So, do I need to install everything again after installing Mint 22 to the Mint 21 partition (Bitwig, u-he, TAL, ...etc)?

I'm also curios if Studio One Pro (beta) would install and function in Mint 22. For the current one I have, I couldn't install it because of some library lacking (dependency problem).

[Edit]
I found this video. I will give it a go tomorrow

I upgraded in place using the upgrade tool in that video. I was a bit worried that it would overwrite my Windows system partition,but all went well, and it upgraded nicely,no problems that I have yet to notice. I selected "Pipewire" in the Bitwig audio setup. I also installed "wireplumber",not sure if it was needed,but installed it anyway.

[FrettedSynth]

Oh Tiles you are a silly guy, can't read too well either. ALSA comparable to Windows Direct Sound LOL, Silly guy.

Take a good look at that picture you asked me to look at of ALSA, (which I was aware of many years ago). Can you see where ALSA resides? HINT Forget all you are seeing outside the kernel. ASIO and ALSA are technically the same. Give credits for trying though lol.