Linux Users, What's You Distro Experience?

[FrettedSynth]

And all of them are slower than ASIO. I talked about the extra software layer already, which does not exist at ASIO. It's the way the ALSA driver is written. You can't outsmart physics.

Extra layer huh? What do you think that ASIO driver is? Why don't all ASIO drivers preform the same in latency? Seems you read only what you wanted to see in j_e_g's post. It's no wonder why you have problems reading instruction for linux. You see only what you want.

Still on your quest I see Tiles

[Scrubbing Monkeys]

Using Mint 20 on a I5 2 core with native Reaper and Mulab through wine.

With Reaper I simply unpacked the tar file and am running it portable. I am using alsa.
It was a painless set up process. Generic kernel.
It performs about 85% as well as a similar spec windows setup. I think the difference is the win setup has an additional graphic gpu to help.
I was able to get 64 samples 3 periods with no glitches using a usb midi controller conntrolling TAL uno lx native. Unable to test audio at this point due to my interface not being class compliant.

All in all a very exciting endeavor.

Note I was able to set up the exact configuration with Reaper as my Win machine with simply importing my config file......Sweet. project and track templates are cross platform as long as plugins exist on both.

[Tiles]

And all of them are slower than ASIO. I talked about the extra software layer already, which does not exist at ASIO. It's the way the ALSA driver is written. You can't outsmart physics.

Extra layer huh? What do you think that ASIO driver is? Why don't all ASIO drivers preform the same in latency? Seems you read only what you wanted to see in j_e_g's post. It's no wonder why you have problems reading instruction for linux. You see only what you want.

Wow, so much wrong in so few words

Nope. I simply see more than the tip of the iceberg that you usually see. Google for the software architecture of ALSA. UNDERSTAND what you read. j_e_g gave already a hint what is waiting there. Then come back discussing.

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.

Still on your quest I see Tiles

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

[audiojunkie]

I use Alsa with very low latency (less than in Windows!)

This is technically not possible. At Windows ASIO drivers operates very close to the hardware in a way that is not possible for ALSA. ALSA has a software layer inbetween already. And is slower in any case. Everything on top of ALSA, Jack or Pipewire, adds even more latency.

The curious part is that ALSA with Jack can be faster than pure ALSA. But it cannot be faster than the fastest mode of ALSA plus the Latency that comes with Jack, which is in any case slower than ASIO.

Let's say it is enough for your needs

What “software layer inbetween” does ALSA have?

[audiojunkie]

Yes, ARM64.

I know what ARM is, but Arch is a distro. https://archlinux.org/

So, yeah, maybe i do mix things up. Especially since the official Arch packages are just optimized for the x86-64 architecture. So you tell me Arch is now ARM64 too? What a mess. As told, there is a reason why there is so few software for Linux available. When there is even a name clash ...

So, my post was deleted

Must have been for a reason. I try to stay friendly.

but I think that the idealism exists in you more than "the community."

No my friend. To quote myself:

Here i just answer the question why there is so few software for Linux available.

I am highly pragmatic. I use Windows AND Linux. I can compare. My first Linux was Suse back in 99. I would even use a Mac if i had one. Only reason is the money. I told it before, ideology does not fill my frigerator. I have a job to do. You can use whatever does the job for you.

Of course i have an opinion, but this was not the point here. I answered a question.

It's not our job either. You might get the impression that many users care about outsiders adopting Linux. I think glokraw does. I couldn't care less. When I'm using Linux, there's almost never a better choice, perhaps another free unix of some sort. I think that the vast majority of people who actually use Linux on a daily basis to get work done aren't a part of the distro-hopping "community.

Yeah, your job is clearly Linux. Mine is music and software development. I don't use Windows, or Mac or Linux, i use software

I’d be interested in hearing some of your music. Would you be willing to point a URL link to it?

[audiojunkie]

I don't complain. Well, i could, a little bit, since i would love to migrate, but cannot. Since my needed software is missing. And that's already end of road.

Here i just answer the question why there is so few software for Linux available. I explain why it is how it is, from the point of view of somebody who develops games and software since 25 years. And Linus backs me up here. He knows all the points too since a long time. What you talk about is idealism and enthusiasm again. Which is not my point.

My only comment as a user is that I have simply a job to do. And this job is either my music or as a developer my software project. Linux is not my job.

Linus just directs what gets merged into the kernel. He has done very little actual kernel development in the last decade. It is largely the work of companies’ developers that contribute actual code anymore. It has been this way for well over a decade.

The larger amount of actual development comes from Red Hat, Fedora, Cannonical, etc. There is so much more development going into Linux than just the kernel. It is quite erroneous to hold up Linus as the final and ultimate authority on all things Linux—despite all of his wonderful contributions to the kernel. Please, for the sakes of those of us who know and understand, discontinue the use of Linus as the ultimate and final authority on all things Linux.

I’ve mentioned the next generation of Linux OS development many times before, which has largely solved most of the problems you have mentioned. Cloud Native computing, utilizing immutability, sandboxing, and containerization is the future of Linux, and it ties the disparate OSes together in such a way that most anything can run most anything. It is unfortunate that you refuse to see this as a solution, because it is the next generation solution, whether you like it or not.

The one thing that I will agree with you on, is that there is more work and knowledge required to use Linux, than Mac or Windows. But that is a small price to pay for the increased freedom and flexibility the OS provides over Mac or Windows.

I have used this analogy many times before, but it fits very well: If one were to compare the three major OS types to synthesizers, you could easily say that MacOS is an extremely high quality, great sounding rompler. It has a ton of presets and they sound great, but you are limited to what sounds it contains and no more. Windows can be compared to a very high quality and feature full Synthesizer. You can do most things, and to most, this is sufficient. The amount of sounds it can create is much higher than a rompler. Linux is a never endingly expandable modular synth. There is no sound in the universe it can’t create. It can be patched to be any kind of synth you want it to be. It is extremely high quality in the sound it creates, but there is a much higher learning curve. All are useful and serve the purpose for the type of users choosing them. Some users just want to use presets and get on with the music making. Some want to create their own sounds, rather than using the limited sounds available in a rompler. Some want to delve into the universe of sound and want the freedom to explore and discover what is possible sonically—to create music that contains something new and never heard before. It all depends on the type of musician you are, or are willing to put effort into becoming.

So, yes—you have explained quite adequately why historically there hasn’t been much software that has been developed universally, with a binary for each and every Linux derivative. The part that you don’t accept, is that with next generation Cloud Native computing, you no longer have to compile a binary for each and every distro to be able to use all software available to the Linux universe. That is the beauty of it. The distros didn’t have to unify after all for a solution to come forth.

You develop for Ubuntu? I’ll be able to run it on my Fedora. Problem solved—even if it’s not the type of solution you want.

[j_e_g]

Google for the software architecture of ALSA.

There is in fact an extra software emulation layer under the ALSA driver that does not exist for ASIO or the solution at Mac.

What is this unidentified "extra software emulation" to which you refer?

You're not talking about ALSA's OSS (Open Sound Software) emulation, are you? OSS was the initial sound API for Linux, like how Wave API (waveOpen, playSound, etc) was Microsoft's initial audio API for Windows. ALSA completely replaces OSS, like how ASIO or WASAPI completely replace the old Wave API.

ALSA does offer a compatibility layer for OSS, so programs that use it can work with ALSA. This does add extra overhead to those old apps (what few that still exist. This is obsolete stuff you're citing). But that has no bearing whatsover upon apps that use ALSA (especially MMAP mode).

There is no other "emulation layer" in ALSA. I repeat, ALSA's MMAP mode does the same thing as ASIO or WASAPI direct mode (or the MAC's CoreAudio equivalent, Can't recall the name offhand. I write Windows and Linux music apps, but not Mac. I've studied CoreAudio, but not programmed for it).

So in theory, MMAP and ASIO are comparable in terms of performance. Does this mean that you're going to get identical performance from both, even on the same hardware? Of course not. Computer operating systems are complex software entities with a lot of "moving", interacting parts that all affect each other. For example, let's say your video card has a really bad graphics driver on linux (ie, NVidea) that does all kinds of stuff that squashes the performance of the computer. Unless your graphics card has an equally bad Windows driver, your music setup is probably going to perform better under Windows than linux on that computer.

It has nothing whatsoever to do with some mythical "ALSA software emulation layer", but rather the total software stack, in its entirety, on your computer. In fact, it's entirely possible for a linux audio setup to yield lower latency than Windows on a given computer. I have proof. I use my own custom music app called "BackupBand" (a realtime audio accompaniment app). I have a windows version that uses wasapi direct mode, and a linux version that uses mmap. The linux version runs better. And this is due to:

1) MMAP mode offers latency comparable to WASAPI direct.

2) Because linux is open source, I was able to tweak the entire software setup to yield better performance than Windows (which can't be customized to the same degree since it's a shrink-wrapped product).

[FrettedSynth]

Wow, so much wrong in so few words

Nope. I simply see more than the tip of the iceberg that you usually see. Google for the software architecture of ALSA. UNDERSTAND what you read. j_e_g gave already a hint what is waiting there. Then come back discussing.

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.

ALSA is part of the Linux kernel yes it needs a "driver" to connect the sound device. Does the word "driver" sound familiar as in ASIO driver. You know that wormhole that connects the physical device to the system with ASIO.

[audiojunkie]

Google for the software architecture of ALSA.

There is in fact an extra software emulation layer under the ALSA driver that does not exist for ASIO or the solution at Mac.

What is this unidentified "extra software emulation" to which you refer?

You're not talking about ALSA's OSS (Open Sound Software) emulation, are you? OSS was the initial sound API for Linux, like how Wave API (waveOpen, playSound, etc) was Microsoft's initial audio API for Windows. ALSA completely replaces OSS, like how ASIO or WASAPI completely replace the old Wave API.

ALSA does offer a compatibility layer for OSS, so programs that use it can work with ALSA. This does add extra overhead to those old apps (what few that still exist. This is obsolete stuff you're citing). But that has no bearing whatsover upon apps that use ALSA (especially MMAP mode).

There is no other "emulation layer" in ALSA. I repeat, ALSA's MMAP mode does the same thing as ASIO or WASAPI direct mode (or the MAC's CoreAudio equivalent, Can't recall the name offhand. I write Windows and Linux music apps, but not Mac. I've studied CoreAudio, but not programmed for it).

So in theory, MMAP and ASIO are comparable in terms of performance. Does this mean that you're going to get identical performance from both, even on the same hardware? Of course not. Computer operating systems are complex software entities with a lot of "moving", interacting parts that all affect each other. For example, let's say your video card has a really bad graphics driver on linux (ie, NVidea) that does all kinds of stuff that squashes the performance of the computer. Unless your graphics card has an equally bad Windows driver, your music setup is probably going to perform better under Windows than linux on that computer.

It has nothing whatsoever to do with some mythical "ALSA software emulation layer", but rather the total software stack, in its entirety, on your computer. In fact, it's entirely possible for a linux audio setup to yield lower latency than Windows on a given computer. I have proof. I use my own custom music app called "BackupBand" (a realtime audio accompaniment app). I have a windows version that uses wasapi direct mode, and a linux version that uses mmap. The linux version runs better. And this is due to:

1) MMAP mode offers latency comparable to WASAPI direct.

2) Because linux is open source, I was able to tweak the entire software setup to yield better performance than Windows (which can't be customized to the same degree since it's a shrink-wrapped product).

Great explanation, Jeff! Hopefully Tiles will come to realize that things are much better now than they were when he last learned about Linux architecture.

[j_e_g]

things are much better now than they were when he last learned about Linux

Sometimes it gets better, Sometimes it gets worse. This is because open source developers far-too-often "reinvent the wheel". This can be a counterproductive thing. But what makes it especially bad is the explicable tendency to _NOT_ learn from history (other peoples' mistakes). These devs are constantly throwing away stuff that works, replacing it with stuff that does pretty much the same thing the discarded stuff did (yet requiring a pointlessly different setup), and perpetuating the same bad decisions/mistakes of the old stuff.

The latest example: "Pipewire" replacing "Jack". My tests have confirmed that Pipewire can't manage as low a latency as JACK without increased underruns. Pipewire needs more buffering. And given that it replaces Jack, that's a step backward (given that the #1 reason for using jack is for low latency audio i/o).

If Tiles were to say, "Linux's audio system has increased in latency due to Pipewire replacing Jack", not only wouldn't I be able to contest such a statement -- I'd be forced to agree.

P.S. I've also found Pipewire to be less stable. I'm getting weird audio behavior such as audio continuing to play for several seconds after I've closed down a video player, or audio seeming to lock-up my computer hard enough that I've had to reboot.

[uOpt]

You can run Pipewire on top of Jack. In that role it should actually do a bit better than pulseaudio.

[j_e_g]

You can run Pipewire on top of Jack. In that role it should actually do a bit better than pulseaudio.

Why would you run Pipewire on Jack? Pipewire can use MMAP mode directly, which is already better than using Jack.

As for Pipewire being an "improvement" upon PulseAudio, that's not really relevant here. We're all talking about low latency audio, and one would never use PulseAudio for that purpose anyway.

[Tiles]

Google for the software architecture of ALSA.

There is in fact an extra software emulation layer under the ALSA driver that does not exist for ASIO or the solution at Mac.

What is this unidentified "extra software emulation" to which you refer?

You're not talking about ALSA's OSS (Open Sound Software) emulation, are you?

Yes i do. We talk about the OSS Emulation module here. Where we disagree is if this plays a significant role. But as tests from EnGee has shown, ALSA is as a matter of fact simply slower than ASIO. And the reason can be found in exactly this design. And that was my point. Thanks for your explanations by the way, you are better in that than me. We just differ in the one or another conclusion.

No argument will make ALSA any faster than how it is. The user doesn't have a big choice anyways. It does not help him to know that there is a fast and slow ALSA mode, since usually the software decides which one to use. That's not a switch a user can turn on or off. Or that ALSA can be faster than the combination of Jack / ALSA when you use it directly. Most software will connect through Jack by default, or even require it. For example ASIO to Jack will most probably not work with ALSA directly, and so on. And in most cases Jack will be faster anyways since pure ALSA tends to use the slow mode.

It's fewer than i would have expected by the way. So i learned something here, which i love. Thanks again for the tests EnGee. And at most modern pc's it might even not play a big role anymore. For me it still does. Most of my projects uses resource hogs like Ozone or Kontakt instruments. But that's unfortunately just a theoretical idea anyways. My needed software is simply not (natively) available at Linux. End of road.

If Tiles were to say, "Linux's audio system has increased in latency due to Pipewire replacing Jack", not only wouldn't I be able to contest such a statement -- I'd be forced to agree.

I didn't want to make up this barrel too. Pipewire is in fact in a sad state, given the ambitions with which it was started. I had some hopes here. As a sidenote, the bottleneck is also here ALSA. So i am not sure if i want to blame Pipewire. The developer did for sure the best he can. With both hands tied behind the back ...

I was just triggered by the claim that ALSA is faster than ASIO at Windows, which it can't be by design since ASIO operates a tad bit closer to the hardware. And this point is at least for me cleared. Facts are more important to me than the unhappy bunnies that i have produced here.

I find it important to understand the limits of the system that you are using. That's the starting point for optimizations. That's the starting point of how to get out the most of ALSA and Jack then. That's where i would be happy to continue the discussion. This would be in the spirit of the topic.

The ongoing flaming and personal attacks because of hurt feelings here is nothing that i am willing to discuss though.

[EnGee]

Google for the software architecture of ALSA.

There is in fact an extra software emulation layer under the ALSA driver that does not exist for ASIO or the solution at Mac.

What is this unidentified "extra software emulation" to which you refer?

You're not talking about ALSA's OSS (Open Sound Software) emulation, are you?

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

It is the same exactly not lower latency but not more. I tried to match the samples in Linux this time, sorry about the previous image:

Bitwig - Linux 128 samples.png

Anyway, I remember very well that there are different results between ASIO in Windows and CoreAudio latency with the same audio interface in software like Ableton Live. I remember that in Mac it was much better latency (lower). It is not related to Linux, however, it is telling me it depends on the hardware drivers quality more than anything else. I'll switch the OS now to Windows then to Mac to take screenshots (as a reference for maybe Ableton Live under wine in Linux!).

[EnGee]

This is the screenshots of Ableton Live 12 in both OSes:

Ableton Live 12 - Windows 11.png

Ableton Live 12 - Mac OS Sonoma 14.5.png