LinuxMusicians

Posted: **Sat Mar 12, 2022 5:54 pm**

folderol wrote: ALSA is an incredibly complex piece of software because it has to be.

Of course. But then, so is WASAPI and CoreAudio, and just about every audio system on every OS.

It manages a vast range of completely different hardware interfaces and turns them into a consistent interface. Nothing else does that. Not Pulse Audio, not JACK, not PipeWire.

You meant to say "nothing else on linux does that". Of course, this is exactly what WASAPI and CoreAudio do. OTOH, OSS also does the same thing on BSD and Linux.

ALSA is everything you need for whatever quality of audio you want

RIght. Which is exactly why I say that, not only aren't JACK, Pulse Audio, Pipewire, etc, needed... they actually have made things worse by trying to take over the audio system.

the only thing I'd want to see improved is the documentation.

Well, that's a huge deficiency, but I'd also like to see other things simplified. For example, ALSA takes a very object-oriented approach where every parameter of a struct has to be read/written via an individual function. That's really a pain in the butt. I'd prefer to see application-side structs you filll in and pass to a single function that parses the data out to ALSA private structs. That's how most APIs do it, because it's so much more efficient, easy, and eliminates problems where you can't set one parameter a certain way, until you first set another parameter to a specific value. I've run into ALSA problems where I can't for example set the bit resolution before the sample rate. So if you do it the opposite order, it fails. If instead, you pass all the parameters at once (in a struct) the audio driver can resolve the correct order.

There is nothing like this on the other platforms. On these, just about everything needs its own driver - which may, or may not, work.

???? You realize that ALSA is made up of lots of drivers and "quirks" for various hardware, which may or may not work??? It's just that instead of manufacturers writing the drivers, it's the alsa devs reverse-engineering those companies' drivers on other platforms, and then doing the ALSA driver programming themselves.

Just out of curiosity, have you written software for other APIs like CoreAudio or WASAPI? I'm wondering, because it sounds like you have a very different idea of how they compare to ALSA.

Posted: **Sat Mar 12, 2022 6:47 pm**

j_e_f_f_g wrote: ↑Sat Mar 12, 2022 2:11 pm In my earlier post I wrote about what Linux audio needs to get done (ie, easier-to-use API, better documentation, stricter adherence to industry standards, abandonment of add-on "audio servers" like JACK, PulseAudio, Pipewire in favor of widespread use of ALSA exclusively).

I conclude that there isn't any movement toward those goals. But I didn't detail why I think that's so. I will now.

Torvalds runs a good, tight ship when it comes to subsystems that are important to servers. He's good at decapitating misguided developers who come up with "solutions" that are just a reinvention of the wheel. (Why do Linux devs constantly reinvent the wheel? Because OSS devs are notoriously bad at not commenting/documenting their code. So when another dev comes along to work on the code, he realizes that it will actually take him longer to come "up to speed" with someone's else's undocumented code, than if he just started from scratch. The latter is more appealing, so devs keep writing new code that does pretty much what the old code did, but in a different way. Then they fail to comment/document it, so the cycle keeps repeating. Torvalds is good at spotting, and discouraging that.)

But the audio system is irrelevant to servers. (In fact, it's one of the first things that gets removed from a server). Torvalds seems to not be interested in it. So he leaves its development almost entirely to the whims of ALSA's primary developers. It was started by Jaroslav Kysela, who set out to create software to load samples into his Gravis Ultrasound, which is a gamer's card, and not at all what a musician would have used at that time. Later on, a SUSE dev named Takashi Iwai took the lead, because he wanted to load samples into his Creative Lab's card, also not musician quality.

I don't know these guys personally, but based upon what I've seen, they don't appear to be musicians, nor familiar with the sorts of tools pro musicians use. That's a problem in getting ALSA geared for pro music use and support. Iwai is good at adding support for new motherboard chipsets, but that's not at all relevant to the music market. I can't say that I have ever seen anything developed by the likes of Iwai, Pottering, etc, that has been applicable beyond generic run-of-the-mill audio use. It's stuff that you want/need when playing back YouTube videos, but has no relevance to musicians. So, my conclusion is that ALSA is not going to make any progress in appealing to music manufacturers/devs until/unless Iwai turns over the lead role to someone whose vision for the API is a lot more ambitious. And hopefully someone who is much better at documenting code than the current ALSA guys. Of all the audio APIs I've looked at, ALSA has the most functions. In fact, it has an extreme amount of functions compared to most APIs. And yet it also is one of the least documented. That's a big problem.

WTF are you talking about...?

Nobody approaching making music seriously on any platform uses onboard soundcards.. Serious consumers and entry level Pros were using Firewire devices and now USB Interfaces, I've owned several of these by Mackie, Tascam, Focusrite, Presonus and Zoom and all of them worked OOTB on Linux (usually in class-compliant mode). In some cases (Presonus) onboard DSP features are only available through proprietary drivers but you can Plug them in and pick your bit depth and sample rate and go to work just like you can on any Platform. It's true that Linux lags and lacks support with Network Audio type stuff currently but as always that will come in time.

I'm as serious as a heart attack about producing Music on Linux and I've never picked one piece of different hardware than I would have picked for any other Platform.. As far as Audio servers most of the cross-platform monolithic DAWS for Linux the the so-called Pros would use on other Platforms simply connect to ALSA now and work wonderfully. No need for JACK/Pulse/Pipewire to get to work on producing. Windows is MORE convoluted by far... Buy your device... Install it's Driver and pray it has an ASIO Driver.... if not go find ASIO4all and then find the Audio Driver Dialog in Your DAW. In Linux with most common supported devices, plug in the device, open DAW and select ALSA...DONE!

These 'do serious people use Linux' questions are such troll bait. It's all Streaming Audio from an interface with a Graphical environment to write WAV files to a Hard Drive... EVERY platform is doing the same thing exactly pick the lipstick you want to put on the pig controlling the process. The operating system deserves little credit really, the Preamps in the hardware control the signal/noise ratio, the ADC/DAC chipsets control the Analog to Digital conversions and the Hard Disk controllers controls the Data integrity it's mostly about the hardware and it doesn't give a damn about the OS so why do we so much...

I record, mix, master and share content on all major streaming services (as do many of you) what is different about what we're doing than what the 'Pros' are doing...? Have you listened to the top 20 on Spotify or Apple music these days...? I don't want anything to do with what the Pros are doing thanks very much!

Posted: **Sat Mar 12, 2022 7:47 pm**

Yes, the whole thread is kind of insulting. I hope it doesn't discourage new users from asking any questions.

Posted: **Sat Mar 12, 2022 8:28 pm**

I'm not a serious music enthusiast. I'm just an amateur hack that practices clarinet and saxophone, pretends to play piano, develops reverb plugins, builds condenser mics, sometimes does jazz jams with other musicians, and occasionally talks his wife into recording vocal tracks.

Posted: **Sat Mar 12, 2022 9:24 pm**

GMaq wrote:Nobody approaching making music seriously on any platform uses onboard soundcards.

Exactly. But if you check Iwai's contributions over the course of the past few years, it's all centered around motherboard/consumer audio. There's a reason why people are creating "audio servers" that try to take over the entire audio system, even going so far as to intercept/reroute software that wants to use ALSA directly. It's because they're not getting any innovation from ALSA. They're just getting audio support for new motherboard chips shoe-horned into the same API. Why do things like JACK exist? Because ALSA hasn't delivered a more focused API, adequate documentation, or features geared for pro-use. So devs keep making new "audio APIs" with entirely different functions to do the same things ALSA does, and keep trying to take the management of audio devices away from ALSA, and pretty much hide ALSA from user space apps.

I've just dealt with this again. I went to open a rawmidi device with ALSA's snd_rawmidi_open(), which used to open fine before pipewire appeared on my system. And now I get a "device is busy" error that I can't programmably work around. There's no way for my program to get this "I know better than ALSA, so I'm not gonna let ALSA do its job" crap to get its grubby hands off of stuff it shouldn't be hoarding. It's supposed to be ALSA's job to manage the allocation of audio resources. If not, then what the hell is the purpose of ALSA???

And I had to do the same thing with digital audio I/O. Jack1 was preventing ALSA's snd_pcm_open() from allocating hardware, because JACK grabs up all audio resources from ALSA in an attempt to become the new system audio manager -- a task it should not be doing. So I had to dig through the JACK sources to see how I could get Jack to release its death grip on the audio system. I discovered that this could be done by writing to a particular file handle. So now I was able to restore sanity back to my system, and get snd_pcm_open to work. That lasted until Jack2 came along, and then I got the "device busy" error again. Turns out Jack2 does the same thing as Jack1, but of course, in a different way. This time I had to use DBus messages to restore ALSA to working state. This worked until PulseAudio came along, and there's "device busy" again. Turns out PulseAudio does the same thing as Jack2 and Jack1, but of course, uses a different DBus protocol to restore ALSA to working state. Now Pipewire comes along and none of those methods work to restore ALSA. Mind you, my app doesn't use Jack1, Jack2, PulseAudio, nor Pipewire, and yet I have to deal with all of them.

I'm sick of this crap. And you folks wonder why commercial devs aren't jumping at the opportunity to increase their marketshare by a miniscule amount, while increasing their tech support calls dramatically?

Posted: **Sat Mar 12, 2022 11:33 pm**

bluzee wrote: ↑Sat Mar 12, 2022 7:47 pm Yes, the whole thread is kind of insulting. I hope it doesn't discourage new users from asking any questions.

Maybe it should ?

When I uploaded my first track, people asked me if I was tone deaf.
That did not stop me, and my type of tone deaf was simply fixed by training.

My point is, I had not come were I am now, if people had spared my feelings.

Reading this topic also makes me very happy to use LMMS with pulse audio.
Staring Linux users should probably ignore Jack exists in the first place, and just start by using pulse audio.

I am still hoping pulse audio will make all easier.
Read something about a gui for pulse-wire coming.

Posted: **Sun Mar 13, 2022 4:50 am**

In my use, I at times need to connect and record various combos of

usb guitar amp
hardware synths
Hydrogen drum machine
Audacity
Reaper daw
standalone linux synths
standalone linux effects
recording tool

I use qjackctl to connect the parts, and jackd Timemachine to record the results. I have not seen any gui for straight alsa that allows such hardware and software routing and interconnectability. And I've no time to figure it out via commands, if such were even possible.

I also don't need to browse the web, or watch/hear media content when I'm producing music, so I have no problem with jackd taking over alsa when I want it to. (I do enjoy jamming with media content for practice and fun and have guitar-rakarrack-spotify connected for when I'm done here)

Reaper or other daw using just alsa is fine, if at that moment, you can do all you want to do in a daw. But again, being able to connect Reaper output elswhere, while playing existing results, and using standalone effects/instruments, while recording the whole, is quite liberating for me. Ideas and experiments can abound, when there are fewer limits.

As it is, I can install AVLinux or Ubuntu Studio, and have a functioning studio ready to add my personal favorites and commercial products to. And repository based distros can be customized for audio once some basics are learned.

Is alsa open-source enough for some coder(s) to apply Jeff's patches and make an alternate alsa version for a suitable kernel? (I'm not a coder, so I don't comprehend any needed logistics to modify alsa in a distro release.)
Don't let that record button assume room temperature, especially on the weekend.

Posted: **Sun Mar 13, 2022 6:13 am**

j_e_f_f_g wrote: ↑Sat Mar 12, 2022 9:24 pm And you folks wonder why commercial devs aren't jumping at the opportunity to increase their marketshare by a miniscule amount, while increasing their tech support calls dramatically?

A miniscule amount of users, by definition, won't "dramatically" increase anything. U-he being the prime example, they put the linux section at the top of their forum at

https://www.kvraudio.com/forum/viewforum.php?f=31

Of 954 posts in four years, that's less than 1 per day. Many posts are thankyou messages, and a lot of the support issues are solved in short order by linux users and U-he staff. Others are sent to Alexander Bique, who did the linux ports, and still helps out, and he is a core developer of the new CLAP plugin format.

https://www.kvraudio.com/forum/viewtopic.php?t=574861

The things about linux and linux audio that I am sick of, are fewer every year. Never used win 8, 10, or 11, or a mac.
So I clearly don't know what I'm missing

Cheers

Posted: **Sun Mar 13, 2022 6:16 am**

j_e_f_f_g wrote: ↑Sat Mar 12, 2022 9:24 pm
GMaq wrote:Nobody approaching making music seriously on any platform uses onboard soundcards.
Exactly. But if you check Iwai's contributions over the course of the past few years, it's all centered around motherboard/consumer audio. There's a reason why people are creating "audio servers" that try to take over the entire audio system, even going so far as to intercept/reroute software that wants to use ALSA directly. It's because they're not getting any innovation from ALSA. They're just getting audio support for new motherboard chips shoe-horned into the same API. Why do things like JACK exist? Because ALSA hasn't delivered a more focused API, adequate documentation, or features geared for pro-use. So devs keep making new "audio APIs" with entirely different functions to do the same things ALSA does, and keep trying to take the management of audio devices away from ALSA, and pretty much hide ALSA from user space apps.

I've just dealt with this again. I went to open a rawmidi device with ALSA's snd_rawmidi_open(), which used to open fine before pipewire appeared on my system. And now I get a "device is busy" error that I can't programmably work around. There's no way for my program to get this "I know better than ALSA, so I'm not gonna let ALSA do its job" crap to get its grubby hands off of stuff it shouldn't be hoarding. It's supposed to be ALSA's job to manage the allocation of audio resources. If not, then what the hell is the purpose of ALSA???

And I had to do the same thing with digital audio I/O. Jack1 was preventing ALSA's snd_pcm_open() from allocating hardware, because JACK grabs up all audio resources from ALSA in an attempt to become the new system audio manager -- a task it should not be doing. So I had to dig through the JACK sources to see how I could get Jack to release its death grip on the audio system. I discovered that this could be done by writing to a particular file handle. So now I was able to restore sanity back to my system, and get snd_pcm_open to work. That lasted until Jack2 came along, and then I got the "device busy" error again. Turns out Jack2 does the same thing as Jack1, but of course, in a different way. This time I had to use DBus messages to restore ALSA to working state. This worked until PulseAudio came along, and there's "device busy" again. Turns out PulseAudio does the same thing as Jack2 and Jack1, but of course, uses a different DBus protocol to restore ALSA to working state. Now Pipewire comes along and none of those methods work to restore ALSA. Mind you, my app doesn't use Jack1, Jack2, PulseAudio, nor Pipewire, and yet I have to deal with all of them.

I'm sick of this crap. And you folks wonder why commercial devs aren't jumping at the opportunity to increase their marketshare by a miniscule amount, while increasing their tech support calls dramatically?

My point is Jeff that in the case of most of the big cross platform DAWs (Reaper, Ardour, Harrison Mixbus, (probably Bitwig) connect to ALSA directly... So why would JACK/Pulse/Pipewire be scaring off potential developers? If they take the time to really look into Linux they would be working toward connecting to ALSA directly and understand that the wheel reinventers with their various Audio servers on top of that are really of little consequence once the DAW has it's talons wrapped around ALSA.

JACK is a different case, it was intended to be a combo of ASIO and Rewire and when it was originally developed there were no monolithic DAWs available for Linux and if you were serious about doing Audio and MIDI together you had to have the modular facilities of JACK to sync up Ardour and Rosegarden or Ardour and Hydrogen so JACK served an important need but is no longer really required unless you are nuts about modular workflows. Even Paul Davis has been backing away from JACK for years now and he was the original developer! I don't think any forward looking Linux Audio project whether it is Backup Band or a DAW needs to really be too fixated on working with JACK nowadays so that crosses one server off your hit list. As far as PulseAudio I really can't fathom what all the bitching is about and what is so dire about it that Pipewire has to succeed it. In AV Linux ALSA/Pulse/JACK have worked seamlessly together for years with the ability route anything to anywhere so I'm quite puzzled about what needs fixing so badly and why people are so giddy about Pipewire when it seems to have issues and latency hurdles of it's own for serious Audio work but then again I'm old and irrelevant..

Posted: **Sun Mar 13, 2022 11:50 am**

GMaq wrote: ↑Sat Mar 12, 2022 6:47 pm [..]
These 'do serious people use Linux' questions are such troll bait. [...]

Good point. Maybe my question should have been "Do experienced musicians come to this forum?" or "Why do I see so many general music questions that do not belong in these forums?"

j_e_f_f_g wrote: ↑Sat Mar 12, 2022 9:24 pm [...]
And I had to do the same thing with digital audio I/O. Jack1 was preventing ALSA's snd_pcm_open() from allocating hardware, because JACK grabs up all audio resources from ALSA in an attempt to become the new system audio manager -- a task it should not be doing. So I had to dig through the JACK sources to see how I could get Jack to release its death grip on the audio system. I discovered that this could be done by writing to a particular file handle. So now I was able to restore sanity back to my system, and get snd_pcm_open to work. That lasted until Jack2 came along, and then I got the "device busy" error again. Turns out Jack2 does the same thing as Jack1, but of course, in a different way. This time I had to use DBus messages to restore ALSA to working state. This worked until PulseAudio came along, and there's "device busy" again. Turns out PulseAudio does the same thing as Jack2 and Jack1, but of course, uses a different DBus protocol to restore ALSA to working state. Now Pipewire comes along and none of those methods work to restore ALSA. Mind you, my app doesn't use Jack1, Jack2, PulseAudio, nor Pipewire, and yet I have to deal with all of them.

I'm sick of this crap. And you folks wonder why commercial devs aren't jumping at the opportunity to increase their marketshare by a miniscule amount, while increasing their tech support calls dramatically?

I know that I'm not going to make any friends here with what I'm going to say and I know it's semi off topic. But I think that you have good point there. Even though ASIO on Windows is a SnAFU too, what you describe might just be one of the reasons that serious people, who simply want to enjoy making or producing music, skip Linux. Which might be a reason that, in my subjective opinion, I see non-Linux related music questions here.

GMaq wrote: ↑Sun Mar 13, 2022 6:16 am My point is Jeff that in the case of most of the big cross platform DAWs (Reaper, Ardour, Harrison Mixbus, (probably Bitwig) connect to ALSA directly... So why would JACK/Pulse/Pipewire be scaring off potential developers?

Good point. However, I do not know how to achieve anything in a DAW without JackAudio. I connect midi keyboards to VST's etc., etc. in QJackCtl. Maybe audio and midi connections can be done with Alsa on the command line but I wouldn't know how... Maybe that's because the first thing that Linuxers advice you to do is to ... use Jack.

Posted: **Sun Mar 13, 2022 5:20 pm**

Linuxmusician01 wrote: ↑Sun Mar 13, 2022 11:50 am
Good point. However, I do not know how to achieve anything in a DAW without JackAudio. I connect midi keyboards to VST's etc., etc. in QJackCtl. Maybe audio and midi connections can be done with Alsa on the command line but I wouldn't know how... Maybe that's because the first thing that Linuxers advice you to do is to ... use Jack.

In the case of Ardour you merely select ALSA in the Audio/MIDI setup window and select your MIDI device by clicking on the MIDI symbol at the top of the track/channel strip you want to record on, no need for JACK or JACK MIDI all. In fact JACK MIDI is inferior and has jitter issues that ALSA MIDI doesn't.

Harrison Mixbus and Reaper should be the same, use the ALSA driver which supports any ALSA supported Audio and MIDI devices on your system, it's actually far easier and more direct. Now in the case of Qtractor or MuSE I don't know..? if they only work with JACK then you'll need JACK and JACK MIDI

Posted: **Sun Mar 13, 2022 5:37 pm**

GMaq wrote: ↑Sun Mar 13, 2022 5:20 pm
Linuxmusician01 wrote: ↑Sun Mar 13, 2022 11:50 am
Good point. However, I do not know how to achieve anything in a DAW without JackAudio. I connect midi keyboards to VST's etc., etc. in QJackCtl. Maybe audio and midi connections can be done with Alsa on the command line but I wouldn't know how... Maybe that's because the first thing that Linuxers advice you to do is to ... use Jack.
In the case of Ardour you merely select ALSA in the Audio/MIDI setup window and select your MIDI device by clicking on the MIDI symbol at the top of the track/channel strip you want to record on, no need for JACK or JACK MIDI all. In fact JACK MIDI is inferior and has jitter issues that ALSA MIDI doesn't.

Harrison Mixbus and Reaper should be the same, use the ALSA driver which supports any ALSA supported Audio and MIDI devices on your system, it's actually far easier and more direct. Now in the case of Qtractor or MuSE I don't know..? if they only work with JACK then you'll need JACK and JACK MIDI

Yep, I use Reaper and it couldn't be simpler. Select Alsa, select your interface, and on your way. I was using Muse recently however, and could not find a way to avoid Jack. Both worked fine (once I figured out the connections in Jack, with considerable help from Oscillator). But I prefer Reaper, as its notation feature is better.

Posted: **Sun Mar 13, 2022 5:45 pm**

Linuxmusician01 wrote: ↑Sun Mar 13, 2022 11:50 amwhat you describe might just be one of the reasons that serious people, who simply want to enjoy making or producing music, skip Linux.

Let's be honest, most people who want to make music probably don't even know that Linux exists, let alone JACK and ALSA. They didn't make a decision to skip Linux, because it doesn't even exist in their universe of possibilities.

Any time somebody asks me what DAW I use, I say Ardour and they either give me a blank stare or say, "I've never heard of that one before." The idea of using open software for ideological reasons is completely alien to most folks, and it's not uncommon for people to assume that their tools are superior because they cost big money and have a big brand name attached.

Posted: **Sun Mar 13, 2022 8:25 pm**

Michael Willis wrote: ↑Sun Mar 13, 2022 5:45 pm
Linuxmusician01 wrote: ↑Sun Mar 13, 2022 11:50 amwhat you describe might just be one of the reasons that serious people, who simply want to enjoy making or producing music, skip Linux.
Let's be honest, most people who want to make music probably don't even know that Linux exists, let alone JACK and ALSA. They didn't make a decision to skip Linux, because it doesn't even exist in their universe of possibilities.

Any time somebody asks me what DAW I use, I say Ardour and they either give me a blank stare or say, "I've never heard of that one before." The idea of using open software for ideological reasons is completely alien to most folks, and it's not uncommon for people to assume that their tools are superior because they cost big money and have a big brand name attached.

Yes, most Windows and Mac users are fairly oblivious to Linux. If they know about it, their tendency is to ridicule it: "Linux? Who uses that?" Ah, the great brainwashed masses....

People are herd animals. Mostly. Linux is for the few, the proud, the....well, let's not get carried away....

Posted: **Sun Mar 13, 2022 10:16 pm**

GMaq wrote: ↑Sun Mar 13, 2022 5:20 pm
Linuxmusician01 wrote: ↑Sun Mar 13, 2022 11:50 am
Good point. However, I do not know how to achieve anything in a DAW without JackAudio. I connect midi keyboards to VST's etc., etc. in QJackCtl. Maybe audio and midi connections can be done with Alsa on the command line but I wouldn't know how... Maybe that's because the first thing that Linuxers advice you to do is to ... use Jack.
In the case of Ardour you merely select ALSA in the Audio/MIDI setup window and select your MIDI device by clicking on the MIDI symbol at the top of the track/channel strip you want to record on, no need for JACK or JACK MIDI all. In fact JACK MIDI is inferior and has jitter issues that ALSA MIDI doesn't.

Harrison Mixbus and Reaper should be the same, use the ALSA driver which supports any ALSA supported Audio and MIDI devices on your system, it's actually far easier and more direct. Now in the case of Qtractor or MuSE I don't know..? if they only work with JACK then you'll need JACK and JACK MIDI

Good point, we the user should not have to deal with jack or what ever is happening on the background.

LinuxMusicians

Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?

Re: Do any serious music enthusiasts use Linux?