LinuxMusicians

GMaq wrote: ↑Sun Mar 13, 2022 5:20 pm 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

Yes, Qtractor and MuSE are built as JACK-based apps. All their routing is done with it.
For me I prefer plain ALSA

Any chance that this could be made useful in modern distros?

http://pkl.net/~node/software/alsa-patch-bay/

Or is there some existing alsa patchbay app that functions
like qjackctl but for alsa connectivity?

I know aconnectgui exists, but is pretty limited.
Cheers

glowrak guy wrote: ↑Mon Mar 14, 2022 5:28 am Any chance that this could be made useful in modern distros?

http://pkl.net/~node/software/alsa-patch-bay/

Or is there some existing alsa patchbay app that functions
like qjackctl but for alsa connectivity?

I know aconnectgui exists, but is pretty limited.
Cheers

patchage https://github.com/drobilla/patchage

GMaq wrote:the big cross platform DAWs... connect to ALSA directly

Only if jack1, jack2, pulseaudio, and/or pipewire have not already grabbed a lock on the ALSA devices. If so, then the DAW will get a "Device busy" error return from snd_pcm_open and snd_rawmidi_open. That's the problem.

Now there are ways for an app to resolve the device busy error. This involves communicating with jack1, jack2, pulseaudio, or pipewire to ask them to release their lock on the device. The fact that each of them has a different way to do this is an additional problem.

In fact, pipewire doesn't yet have a method to release the lock. The developer is still working on that. Someone requested that he use the same protocol as pulseaudio. He replied that he "hasn't decided yet". If he comes up with yet another incompatible protocol, I will curse him to hell. I've already been through this nightmare 3 times with jack1, jack2, and pulse.

why would JACK/Pulse/Pipewire be scaring off potential developers?

Because of the above. When Acme Inc's typical enduser sees a "Device busy" error message, which of the following reactions is he likely to have:

1) Oh, device is busy means that some other user-space app has locked the device. Since I have no other audio-using app open, then it must be my sound server. I have pipewire running. Let me look for some pipewire configuration utility or command that lets me disable this locking. Oh here it is. Done.

2) It doesn't work. I better call Acme Inc tech support.

And that tech support is a business expense.

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

Thanks for the info! Qtractor won't work without Jack, if I'm not mistaken. But Jack uses Alsa Midi per default. The "Jack version of Midi" is only forced upon the user by Reaper if you use Jack in Reaper (you can choose to use Alsa in R. too). I see a lot of confusion about Alsa Midi and Jack Midi.

Rather than deal with the details of j_e_f_f_g's posts it would be simpler to undermine the arguments presented in them at root. In jeff's previous post we started with JACK taking over audio hardware, and ended up with the conclusion that tech support costs money. Thanks for that jeff, really insightful.

To join those two seemingly unrelated concepts we went via some stories jeff has made up about a hypothetical user. Jeff, you have presented absolutely no evidence that these stories you make up have anything to do with reality.

merlyn wrote: Rather than deal with the details of j_e_f_f_g's posts

Translation: He's discussing actual technical details that I know nothing about. Since I know nothing about these technical details, I can't counter his points. But I want to because I'm a linux fanboy. So I'll just summarily dismiss them by mere proclamation, make the accusation that his arguments are entirely without any substance, and hope that no one is smart enough to realize that I'm projecting, because my reply is entirely without any substance.

Where you're going wrong is that you've started with a conclusion. Your conclusion is that sound servers are too complicated and the solution is to use ALSA. You then fit your argument to that conclusion.

You could start with the data. Do you have any data? Like "98% of audio developers, who expressed a preference, were scared off by JACK"? Without data your arguments are speculation.

merlyn wrote: Your conclusion is that sound servers are too complicated

Incorrect. I could write a very simple sound server that only locked every pcm and midi device. And it would present the same problems that I detailed in my previous posts.

You're inventing your own strawman arguments because you lack the requisite knowledge to understand the technical details of this discussion. That has nothing to do with me.

You then fit your argument to that conclusion.

Those are your own strawman arguments/conclusions -- not mine.

Do you have any data? Like "98% of audio developers, who expressed a preference, were scared off by JACK"?

Preference to what? That implies a comparison, which in turn implies a relationship between 2 things. All you mention is jack.

Anyway, your question is non-sequitor since my position is certainly not that jack is the sole obstacle to linux audio development. And unlike you, I don't present vague strawman arguments. I've identified very specific issues. That those issues are too technical for you to understand is not my problem.

I'm posting to provide anyone reading this thread with a counterpoint to the sophistry present in your posts on this thread.

j_e_f_f_g -- turning features into bugs since 2002.

One thing to say is that, for many audio purposes, there are valid, even cross-platform abstractions over GNU/Linux audio. JUCE for example is widely used even outside FLOSS circles.

merlyn wrote:I... provide... a counterpoint

Yet another example of using assertion by mere proclamation, in lieu of reason, deduction, or any kind of logical argument.

Your "counterpoint" has no point.

You're obviously in way over your head. I'm sure you didn't even understand my discussion, as one example, of how alsa's protocol of passing values one at a time, versus passing them simultaneously in a struct, can result in a failure. (ie See my criticism that ALSA is too focused on an object-oriented design, which in this case is the wrong choice. The example I cite shows why).

If you're going to advocate for (or criticise) something, you had better know a lot about it. I did a month's long code review of both alsa and jack. I know how they work (or don't) under the hood. You on the other hand know next to nothing about them, which is why every one of your replies boils down to:

'You're wrong because... I say so."

Your kind of advocacy is counterproductive. It reveals that you don't even understand what you're advocating.

Basslint wrote: there are valid, even cross-platform abstractions over GNU/Linux audio.

I have no problem with abstractions (ie code that gets linked into your app, and affects only your app). For example, something like rtAudio is hunky dory.

I get annoyed when someone makes software that sucks up all the sound devices because the software wants to take over device management from the operating system. Because that usually affects my apps (which allow the operating system to do its job). And I typically have to add code to push the overreaching software out of the way. (Because the offending software never releases those devices until/unless your app tells it to.)

And I get really pissed off after a half dozen developers keep recreating this crap, all of it doing the same (wrong) thing in a different way (while claiming to be "compatible replacements" for the earlier crap), and requiring yet another incompatible method to push it aside.

Do any serious music enthusiasts use Linux?

Absolutely. It's just another platform and the underlying OS is rock solid. Is it mainstream, obviously not, but if you want to mix and master within Linux it is entirely possible as you can with any other OS. Can you make it sound like the songs you hear on the radio or a CD, no, not on Linux or another OS, those songs are mastered by sound engineers using equipment that none of us could afford in a studio built specifically for that purpose.

The issues Jeff pointed out are true, documentation is not always stellar and devs seem to keep reinventing the wheel rather than improving it. One thing I think was missed in his explanation though, is the ability to open and edit the underlying code. You cannot do this with closed source proprietary software as you can with Linux. If you can't code, and I can't, you can still further the cause by filing bug reports and writing documentation that is more clear and concise.

Just bridge Alsa to Jack and problem solved...