ALSA, JACK and other approaches (e.g. Windows Audio System)

[shebang]

Please excuse my poor english. I've been lurking here for a long time, and this thread finally compelled me to register. I think one of Jeffs best contributions to Linux audio are his tutorials on his website, they are the best and easiest to understand tutorials on Alsa anywhere on the internet, especially for a newbie programmer like myself who wants to contribute to Linux audio, but can't understand the awful documentation. Many thanks for that Jeff, I would have given up if not for your tutorials.

He also has a much broader understanding of audio, how can all of you be so sure that Linux audio is better than Windows when you have not even tried Windows audio? Linux is not more powerful than Windows for audio, you all seem to imply that Jack makes Linux capable of things that can't be done in Windows, which is a lie. Reaper and other Windows apps have more powerful internal routing than Jack, and do not need a session manager to recall the routings between sessions. Linux audio is not capable of better results than Windows, it is less stable, uses more CPU and usually makes worse results. Someone please show me some audio made in Linux that could not be made better and easier in Windows, if not, then maybe Jeff is right to imitate Windows. What are you so afraid of?

(removed unconstructive stuff --raboof)

[shebang]

Ask yourself: Why are you here? If Windows and all its proprietary software is so great, then use it. Have fun. That's who ever said Linux audio was supposed to be a clone of some windows shit?

This is why you have no users. I want to use LInux, but I will not let my music suffer because of it. I care more about my music, but I wish Linux was as good so I could stop using Windows, and that problem can only be solved by people like Jeff who admit there is problems.

Is it better to be a clone and as good, or different and worse? Or you just pretend that it's not worse for everybody use case? I make new and old styles of Indian music, Windows does all better, even if I love Linux.

(... --raboof)

[male]

Ask yourself: Why are you here? If Windows and all its proprietary software is so great, then use it. Have fun. That's who ever said Linux audio was supposed to be a clone of some windows shit?

This is why you have no users. I want to use LInux, but I will not let my music suffer because of it. I care more about my music, but I wish Linux was as good so I could stop using Windows, and that problem can only be solved by people like Jeff who admit there is problems.

Is it better to be a clone and as good, or different and worse? Or you just pretend that it's not worse for everybody use case? I make new and old styles of Indian music, Windows does all better, even if I love Linux.

I hardly worship JACK, friend. I have been quite vocal about the problems with JACK. *However* I do think it is a far better solution than the monolithic approach that has been around since the proverbial dinosaurs.

(edit: removed stuff --raboof)

[j_e_f_f_g]

what you're accustomed to on Windows is the way things should be.

I'm never accustomed to any one thing, not even on Windows. For example, I recently started programming Windows Audio System (WAS), Microsoft's answer to Steinberg's ASIO, which didn't even exist when I initiallly wrote any of my Windows software. I'm constantly reviewing, adapting to, adopting, and definitely rejecting where something doesn't work as I want, new technologies. JACK and Pulse Audio are examples of rejections. ASIO is another example of rejection. (The author violated a basic tenet of COM, which is that args are always passed on the stack. He instead used C++'s stdcall convention, in order to make a mac port easier. The result is an API that is perilious to use with other compilers besides Visual Studio, and apple's compiler, or with languages other than C++. Bad design.).

WAS Verdict: Minor quirks, but overall a very good API. COM (Common Object Model) done right. Proper software mixing transparent to apps, but also allows an app to directly access hardware buffers (like alsa's MMAP mode, but way, way, waaaaaaaaay easier to use than ALSA'S MMAP and more stable). It's vastly better than MME, and Wave API. It's better than DirectSound. It does all ASIO does, and more/better. Thumbs up to MS for this one. They got it right.

When I get time, I'm planning on writing a WAS programming tutorial. When done, I'll let you know so maybe you can learn about something other than the one and only thing you've ever gotten "accustomed" to. MME, Wave, DirectSound, WAS, ASIO, CoreAudio, OSC, AudioBus, etc? Why, you don't know nothing about anything except JACK. No wonder why you love it. It's the only lover you've ever had.

(edit: removed unconstructive bits --raboof)

[j_e_f_f_g]

First of all, Shebang, glad you found my website useful.

Secondly, don't worry about anyone "attacking" me, nor failing to "defend" me. I feel confident in my own convictions, and in my own abilities to handle any "attack", plus I'm a staunch supporter of minimal censorship, and believe that dissent is valuable and needed. Nothing in this thread has either upset me, nor changed my views.

I wish Linux was as good so I could stop using Windows

Here's the bottom line from my perspective, and should be useful to you as obviously we've made similiar observations/evaluations.

ALSA: Not a great API. Not a useless one either. It has solid, consistent, error-checking. (Pulse Audio and FFADO do not). It is actually capable of very low latency... when you use software that talks directly to alsa, and uses certain techniques (ie MMAP). It can give you better latency than windows, but not when you use software like JACK or Pulse Audio, with data crossing process boundaries and deamons doing software mixing and rate conversion, and maintanence of "connections" and "sessions". You kill performance, and make app config more difficult. See the dramatic latency differences between an alsa app and JACK apps, measured by a guy in the eDrummer thread. I happen to author eDrummer, but he was ruthlessly unbiased in his measurement.

Now ALSA has its problems, for example no bluetooth nor firewire support, and dodgy sync issues. it's over-engineered in some places (for example, the amount of data abstraction is absurd), and under-engineered in others. (For example too primitive an interface between drivers and userspace. Linux drivers have a fraction of interfaces as Windows drivers. The ALSA author did this because he wanted to make alsa drivers easy to write. Having written both Windows and linux audio drivers, the alsa driver is much easier. But that doesn't do endusers any good when infrastructure is missing. For example, a windows driver can tell an app "this here output is a headphone out, this one is line level, and this one is digital SPDIF out". That same hardware under linux can tell an app only "I have 3 outputs. Let's have fun and make the musician guess what is what").

These things could, and should, be fixed. But there's another big alsa problem. This over-engineered codebase is large, and horrendously underdocumented. It should never have been allowed in the kernel. I understand the political (and some technical) reasons for kicking OSS out. But you don't replace an entire subsystem with a large, inadequately documented codebase. The author shouid have been required to properly document the code (which still has not been done) before it ever replaced OSS. You can't get people to fix/improve such a codebase. It justs gets minimal maintenance from a few longtime contributors, and otherwise rots and falls behind the competition.

So instead of fixing alsa, new programmers decided to write their own sound servers. Sure things today would be so much better for linux audio if they had instead fixed alsa. But who wants to work with a large, inadequately documented codebase? Nobody. Don't blame them there. But here's where these guys made things go from bad to worse. Instead of writing a sound server that replaces alsa (the way alsa replaced oss), they just wrote abstraction layers that sit on top of alsa. We get all the same underlying limitations/problems and codebase issues, plus increased complexity in setup, and more points of failure. And now all these make-matters-worse abstraction layers are entrenched. It's a nightmare. If Microsoft had said "Our Wave APi is limited and in dire need of retooling. So let's write our new WAS API to run on top of Wave API."... then WAS would be crap. They didn't. It isn't. WAS will give ALSA a run for the money in its latency, which is/was alsa's one bulletpoint.

It's not that I relish telling "I love JACK" folks what things the competition is doing. But really if you're going to give advice to Windows/Mac musicians like shebang, who arrive to investigate the possibility of using linux, you ought to know a hell of a lot more about other things than the one thing you're "comfortable" with -- JACK. These musicians do. There's a reason why Linux is a hardsell on KVR forums, even though those forums are owned by Muse Research -- you know, the company whose product runs on linux. (Let the irony sink in). And it's because of the really inept, misguided advocacy like what i've witnessed, such as telling some power user he needs to adapt to new things, from people who are woefully lacking in knowledge, as well as hands-on experience, with anything beyond yet another daemon running atop alsa. That's what a troll is -- not someone who is going to give detailed analysis about actual choices in use.

So shebang, here's my advice if you want to use linux for audio:

1) Get into the audio/MIDI setup screen of the Linux app. If it lists, and allows you to use, alsa in/outs directly, use that. If it uses jack only (or pulse audio, or anything other than alsa), discard that app. Yes, this will limit your choice of linux apps... to ones that are easy to setup, and have the lowest latency.

2) Uninstall Pulse Audio. Uninstall JACK. If you see anything describing itself as a "bridge" or "session manager", drive a stake through its heart and dose it with holy water.

3) Don't try to run windows music software under linux. (No WINE). Run Windows software under windows.

4) Filter "advice" from people who obviously don't keep up with developments in the industry as a whole, especially when these one-trick ponies tell you your problem is all because you haven't given their pet product enough time/effort/chance. They'll steer you wrong.

(you guessed it, more 'censorship' --raboof)

[StudioDave]

[ALSA]... is actually capable of very low latency... See the dramatic latency differences between an alsa app and JACK apps, measured by a guy in the eDrummer thread. I happen to author eDrummer, but he was ruthlessly unbiased in his measurement.

You're both late for the party:

http://www.onlamp.com/pub/a/linux/2000/ ... tml?page=1

Best,

dp

[raboof]

See the dramatic latency differences between an alsa app and JACK apps, measured by a guy in the eDrummer thread.

I assume you mean the thread at http://www.linuxmusicians.com/viewtopic ... 24&t=11024 . Which measurements are you referring to specifically?

[j_e_f_f_g]

I don't like windows "promiscuity" or user applications that talk directly to hardware.

Win apps never directly talk to hardware. What we're talking about is "buffer sharing". The hardware's DMA buffer (not hardware) is mapped into the app's virtual address space. So the app can put the audio data directly into the hardware's buffer. The app doesn't need to first put data into its own buffer, then call an API function to give its buffer to the driver (which entails a costly ring 0 transition on protected mem CPUs like Intel/AMD), and then have the driver copy the app's buffer to the hardware buffer (which entails another costly operation -- a virtual to physical address translation on the app buffer).

This technique is not exclusive to Windows (ie, not just used for WAS Exclusive mode). This technique is also used in Apple's CoreAudio, and ALSA's MMAP mode, for example. In fact, JACK uses MMAP mode when it can. But 2 things:

1) If you've written apps that use WAS versus ALSA MMAP, you quickly realize what a much better implementation of this technique WAS has. It takes about 6 lines of WAS calls to do what an entire page full of ALSA calls do. And then the state of alsa drivers is so hit-and-miss (because alsa is so poorly documented that various driver authors do things differently, or not at all because they don't know how), that your WAS app is more likely to work and perform well than your alsa app. Not only does Microsoft better document their APIs (well, not as well as they used to, but still...), MS actually tells hardware manufacturers "This is how you should design your hardware so that it works best with WAS.". Yes, they really go to those lengths. It all makes a difference.

2) JACK design makes the unwise decision that interoperability in a realtime system is best achieved not via a well-designed, shared memory, tightly integrated plugin system, but rather via userspace code (ie daemon) running in a separate address space as the app. So now you need all these unnecessary "connections" to handle crossing process boundaries (and worse yet, actually force endusers to visualize this mess via horrible creatures like qjackctl), and by nature of the design, you inflict virtual address translations anyway, for example. Then you run this on top of alsa so you get all the old limitations/flakiness anyway, but with a whole bunch more complexity and points of failure.

No, JACK is not something you want to "show off" to WAS and CoreAudio developers/users. It's something you want to hide in the closet and whisper "We don't mention Uncle Jack. He's not quite right.".

midiview doesn't create alsa MIDI ports

You mean ALSA sequencer ports? No, MidiView uses the lowest level alsa midi api, called "rawmidi". Alsa's sequencer api is another one of those "mistakes" that never should have happened. MS dabbled briefly in a similiar vein with their "midi stream" api, but had the sense to not pitch it for pro audio work, and quickly buried it when they realized that it just muddied the water for developers, and offered no serious usage scenario.

Anyway, I admire FLOSS developers a lot. A bit of competition is good but it saddens me when you start calling names. You both have strong points and I think you would learn from each other if you met in person, with open views.[/quote]

[raboof]

JACK design makes the unwise decision that interoperability in a realtime system is best achieved not via a well-designed, shared memory, tightly integrated plugin system, but rather via userspace code (ie daemon) running in a separate address space as the app.

Indeed most of the JACKd address space is seperate from the client app's space. Where it counts, however, which is for the audio buffers, JACK uses shared memory (shm/mmap), right? So I don't really see the problem here.

by nature of the design, you inflict virtual address translations anyway, for example.

I don't understand this part of your argument. Can you elaborate?

[tux99]

Since this thread has now become about WIndows vs. Linux audio/midi programming I might as well add my little experience too.

I only have experience with MIDI programming (not Audio), and the two APIs I have worked with are the ALSA MIDI API and the Windows MIDI API.
Between the two the ALSA MIDI API is far easier and more logical to use compared to the Windows MIDI API. The Windows MIDI API is especially awkward to work with when it comes to receiving MIDI data, but even for sending MIDI data it's a lot more convoluted than the ALSA MIDI API.

So at least when it come to MIDI programming ALSA beats Windows very clearly.

[raboof]

Now ALSA has its problems, for example no bluetooth

Actually http://www.alsa-project.org/main/index. ... ule-bt-sco

[autostatic]

ALSA: Not a great API. Not a useless one either. It has solid, consistent, error-checking. (Pulse Audio and FFADO do not). It is actually capable of very low latency... when you use software that talks directly to alsa, and uses certain techniques (ie MMAP). It can give you better latency than windows, but not when you use software like JACK or Pulse Audio, ...

JACK doesn't add any latency.

...with data crossing process boundaries and deamons doing software mixing and rate conversion, and maintanence of "connections" and "sessions". You kill performance, and make app config more difficult. See the dramatic latency differences between an alsa app and JACK apps, measured by a guy in the eDrummer thread. I happen to author eDrummer, but he was ruthlessly unbiased in his measurement.

JACK doesn't maintain any connections or sessions. It does mixing but the mixing being done is really minimal, JACK actually only adds streams together.

[male]

I appreciate the situation you're in, raboof, but I have to say I'd rather have the thread deleted entirely than have the posts be redacted. When people can still browse these forums and find (both) Jeffs' misleading and incorrect statements left apparently uncontested--then the forum is doing a disservice to those who seek knowledge.

[tux99]

When people can still browse these forums and find (both) Jeffs' misleading and incorrect statements left apparently uncontested--then the forum is doing a disservice to those who seek knowledge.

Nobody prevents you from correcting Jeffs' statements as long as you stay on the subject rather than attacking him (or anybody else) personally. In fact I'm very much interested in reading your point of view on the subject, that's what the forum is for.

Edit to add: Jeff, I would also be interested in reading your view to my earlier post about ALSA MIDI API vs. the Windows MIDI API, do you agree with me that the ALSA MIDI API is far easier to use from a programmer point of view than the Windows MIDI API? And if not why not?

[male]

When people can still browse these forums and find (both) Jeffs' misleading and incorrect statements left apparently uncontested--then the forum is doing a disservice to those who seek knowledge.

Nobody prevents you from correcting Jeffs' statements as long as you stay on the subject rather than attacking him (or anybody else) personally. In fact I'm very much interested in reading your point of view on the subject, that's what the forum is for.

Unfortunately, there's not much more to say than that he hasn't uttered a single accurate word. JACK may have problems, but Jeff doesn't know what they are because he doesn't actually know anything about JACK. He only knows that he doesn't like it. That's fine. However, spreading lies and misinformation is not OK, and I'm afraid I can't avoid calling the man an idiot and a liar when that's what he clearly intends to present himself as. This post will probably be edited severely, as will anything else I post now in this thread. I'm sure you wouldn't like having a hand placed over your mouth any more than I do. So, for now I'll leave it at that. Believe me, I'm sure there will be another opportunity in the future for Jeff to make some blatantly false claim about how things actually work on Linux. And I'll be there to set the record straight for a few hours until the thread gets 'cleaned up'.

In the meantime, I'll continue happily making music in a very stable, very flexible, very low latency, modular environment on Linux while Jeff & Jeff enjoy the CPU melting, xrun causing, glitchtastic sounds of PyDAW OS.