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

[tux99]

hmm, so...

For all the problems JACK introduces (and I've been detailing) -- ... convoluted configuration

How exactly does JACK have a "convoluted configuration" ?
The 2 most used JACK configuration tools are pretty easy to use - qjackctl and Cadence. (are there any more?)

Come on be fair, even I find Jack still confusing despite having used it for years, a newbie would have no clue how to configure it. Jeff is right that Jack turns off many people from using Linux for audio production work.

You have written Cadence so of course you know Jack intimately and find it easy, but your point of view is not comparable with the average user.

[tux99]

hm, but that is the definition of a monolithic application.
Or if it's not, perhaps I need a new word...

I mean software like Ardour3. It does both audio and midi, it loads plugins to be used as synths and FX. You can do everything in a song only using Ardour3.
(Isn't that what we called monolithic?)

No, monolithic would be an application that you can't extend via plugins (or at best only with proprietary plugins).

[tux99]

Come on be fair, even I find Jack still confusing despite having used it for years, a newbie would have no clue how to configure it. Jeff is right that Jack turns off many people from using Linux for audio production work.

I completely disagree with you...

Of course you disagree but then I already said:
"You have written Cadence so of course you know Jack intimately and find it easy, but your point of view is not comparable with the average user."

It might well be that Jack is easier to use with Cadence than with Qjackctl, I can't try Cadence as it doesn't build on my distro (Centos 6.4) but you can't claim that Qjackctl is newbie friendly.

[tux99]

I'm open to suggestions on how to improve the jack-settings dialog.

I'd be very happy if Cadence would even build on Centos 6.4, but when I last tried some of the required dependencies were way too bleeding edge. I wish programmers would understand that not everyone runs bleeding edge distros and therefore write software that runs on more conservative distros too (actually many programmers do this, it's only some that feel they must be on the bleeding edge).

But this is off-topic here in this thread.

[ssj71]

Not to be disagreeable, but I agree and disagree with both of you. I think JACK is confusing to newbs (though a simpler setup than qjackctl offers will help), AND I think monolithic is an appropriate term for the style of DAW discussed. I don't think there's anything wrong with calling it that, because you are still subjected to its implementation of hosting. i.e. Ardour 3 doesn't currently have midi->midi plugins. It doesn't matter whose "fault" that is, and it will come but you are still subject to that limitation. On the other hand, anyone can make a JACK capable program that would do this right now. And either way the same tasks need to be performed, if the DAW isn't hosting it the OS is. Its just a question of what performs what tasks.

I'm totally on the fence about which way is better ATM. I lack sufficient information.

Jeff I'm still curious about my question above. Do you think SW audio routing should just not be done between programs?

[TheSafePlaces]

You have written Cadence so of course you know Jack intimately and find it easy, but your point of view is not comparable with the average user.

Wow. Wanna know what the average user thinks? I don't know how to code and all, and have been on KXStudio less than a year, I might qualify.

I set it up with my audio interfaces, had help from the community with setting up the period size/buffer length and other things...

...and never needed to touch it again. Cadence and all requisite bridges are is set to start up automatically on system startup, if anything goes wrong (like LinuxSampler - mine likes to make JACK crash on exit), I have cadence-session-start script on a keyboard shortcut, it fixes things and restarts JACK and the bridges in about 4 seconds. The number of times I actually had to open Cadence? Probably once...in the whole of last 6 months. Half the time I forget JACK exists at all. Hope that answers your question.

Can't do anything but fence sit, same as ssj71. But JACK never gave me any problems whatsoever, whether it was playing guitar using Rakarrack, recording that in qtractor, or what I'm doing now - sequencing (orchestral film scoring)...so that's JACK - 1 Anti-JACK - 0 already.

[male]

ITT: Claims without evidence, questions without answers.

JeffH/G completely ignores several factors when he claims that ALSA is 'better' than JACK.

The first is realtime performance. ALSA and ALSA programs were never meant to operate this way--it was designed as sound I/O systems have traditionally been designed--with the assumption that a large enough buffer will cover up any hiccups.

And yes, ALSA is a bit weird and has some kitchen sink features. But JACK doesn't use those. It just uses the base functionality which is little beyond than the actual device driver.

JeffH/G lacks the knowledge, experience and skill to write a realtime capable program. If one can't write RT safe code, then, yes, dealing with JACK would no doubt be frustrating. Reverting to ALSA doesn't fix anything. It just makes the problems less apparent (as would running JACK with a large period size and --sync and --softmode options). This is just covering up problems with either the system configuration or the client code.

His claims of lower latency with ALSA should be taken with a huge grain of salt. I don't see any evidence being presented, nor do I think any ever will be. Smug falsehoods, however, will continue to flow from his fingers.

Another thing being ignored is flexibility. One simply cannot do the same things with one program exclusively using the ALSA device that one can do with multiple programs connected via JACK. That is, unless that one program has infinite complexity and supports every possible feature the user could ever want. JACK is a way to deal with the undeniable reality that sometimes the user will want to do something that the author of MonolithicPythonSuperHost did not anticipate. In this case *even if* JACK actually had the problems JeffH/G claims it does (it does not), then it would still be a worthy compromise for the kind of flexibility it buys.

This is, after all, Linux. We have a long history of preferring small, sharp tools. It's part of the reason that all the big iron now runs Linux. It's also the best way to allow multiple, independent projects to exist and thrive and continue to offer users a plethora of options. That is what we all care about here, isn't it?

We already know what the monolithic/exclusive access systems that have been around since the dawn of digital audio are capable of. We're only just beginning to explore the new possibilities presented by JACK. I, for one, find it exciting to be riding the crest of this wave of progress and not cowering in fear of it or hiding behind a veil of misinformation.

[j_e_f_f_g]

As I understand, Jeff, your point is ALSA has some issues and should be replaced or fixed (which is difficult due to the poor documentation), and JACK is adding a broken front-end on top of a broken back-end.

Yes! I could kiss you! (Are you cute?) Finally someone taking time to read and respond to my points, rather than arbitrarily dismissing them and instead trying to impune something about my motives.

But how would you recommend app->app audio be mixed such as JACK allows?

Excellent question.

I would not recommend app->app audio... at all. The unix paradigm of piping data across discrete apps works well for a lot of tasks... except realtime tasks. Imagine how dogslow video playback would be if an app couldn't pass graphics data to an os function like XDrawBitmap which then wrote it to the video card (driver). Instead, the app had to connect to a "graphics server", and send/wait for "requests" to get anything done, and this involved crossing process boundaries.

OMG! I just described X Windows! (Never underestimate a unix programmer's ability to design a realtime system that ain't realtime). So we go over to Phorunix(?) and look at the video benchmarks of x versus win and mac, and say "This X kind of sucks.". If only we integrated things more to eliminate the unixisms, it could be faster, smoother, etc. Wayland to the rescue! Die X server die! Die jack server! Die Mir and Canonical! Ahem.

The thing is, not once have I ever heard a Win/Mac user say:

I got 40 eq effects, and 40 reverbs, and 40 compressors, and 40 of every other thing, all made by various folks. And all of them work with my DAW. And my seq. And everybody else's DAW and seq... except this Non thing. Etc, I just go to the app's Plug-in menu, and there they all are -- ready to be "inserted" wherever I want right within the app. Damn this inflexible monolithic system! I'd give it all up if only... to use this reverb with my daw I had to run them both as separate apps. And then I had to use a 3rd app to "connect" nebulously named ports together to get them to work (and I don't even know what a port is since it's an abstract software concept, and honestly I don't even know what this app is actually doing). And I want to need to do this each and every time I use them together, until I get so fed up I go out and get a 4th app that does it for me, whatever "it" is cuz I don't understand what this "session manager" does either... when it works. And I want this horrific mess so that when one of these many points of failure break, I have no freeking clue how to fix it. And then I can go on Linuxmusicians and say 'Help! Why is this so much harder than my supposedly-monolithic system, which btw has a vastly greater array of choices/suppliers?'. And they can say 'because it ain't that system. get lost.'"

Nope. Never heard a Win/Mac user say that. Reckon I never will.

In conclusion, we don't want app->app->app audio. We want app->plugin->plugin audio, where plugin is a standard that all apps support.

If I want edrummer to send drums to an FX program is this possible using ALSA and if not, how should this be architectured? A change in ALSA or something added on top?

[/quote]

Another excellent one. Kiss me. No tongue.

Let's make the example really specific -- you want to use edrummer with zita reverb. First you go to the zeta author and say "your app is an ideal candidate for plugin format. Please make it an lv2.". And he says "No" because he's Hans. But it doesn't matter because some ass butchers his code into lv2 anyway.

Then you go to the edrummer author and say "I want to use this plugin. Please add lv2 support." And he says either "Sure I'm not some guy clinging to the LADSPA past", or "No way. You're that amphibian music guy, and you want me to do your work for you.".

But it doesn't matter because GMaq does all the tedious work I refuse to do, and he modifies edrum, makes a desktop launcher for it, packages it, and bakes cookies for the first 50 people who download it. so you load up zeta in edrum with nary a qjackctl in sight, and make your ambulance music. or something.

Fun questions.

[tux99]

@male: Why the heck are you mixing up Jeff G with the author of PyDAW all the time?
Are you claiming they are the same person?
I don't have the impression they are the same person at all in fact it's quite clear to me that they are two separate people who have nothing to do with each other (just look at their respective web sites and research their names) so please explain where you get this absurd idea from.

This is, after all, Linux. We have a long history of preferring small, sharp tools.

Small sharp tools make sense on the CLI where you can easily combine and script them but this doesn't apply to interactive GUI apps.

It's also the best way to allow multiple, independent projects to exist and thrive and continue to offer users a plethora of options. That is what we all care about here, isn't it?

A well though out standardised plugin system allows exactly the same.

We're only just beginning to explore the new possibilities presented by JACK. I, for one, find it exciting to be riding the crest of this wave of progress and not cowering in fear of it or hiding behind a veil of misinformation.

Jack has been around for many years already now, with not much to show when considering how long it has been around.
Even now new audio apps don't always support it, which means Jack is still struggling to convince developers of it's usefulness.

[male]

@male: Why the heck are you mixing up Jeff G with the author of PyDAW all the time?
Are you claiming they are the same person?
I don't have the impression they are the same person at all in fact it's quite clear to me that they are two separate people who have nothing to do with each other (just look at their respective web sites and research their names) so please explain where you get this absurd idea from.

The statements apply equally to both Jeffs because, even if they are not the same individual, they have made the same statements to a T with one minor difference (apparently on some days Jeff likes LV2 and on others he hates it). They also have the same general attitude and nostalgia about Windows.

This is, after all, Linux. We have a long history of preferring small, sharp tools.

Small sharp tools make sense on the CLI where you can easily combine and script them but this doesn't apply to interactive GUI apps.

Who said it doesn't apply? Why shouldn't it? Can you articulate any good reason?

It's also the best way to allow multiple, independent projects to exist and thrive and continue to offer users a plethora of options. That is what we all care about here, isn't it?

A well though out standardised plugin system allows exactly the same.

Such a plugin system doesn't exist. And who is going to tell all the would-be application developers that they have been relegated to being mere plugin designers? Your argument is a cop-out. It's equivalent to saying, "IPC is hard, screw it, I'll just run everything in one process". That's not how good design decisions are made. One bug in one plugin crashing the whole system. It's a house of cards.

We're only just beginning to explore the new possibilities presented by JACK. I, for one, find it exciting to be riding the crest of this wave of progress and not cowering in fear of it or hiding behind a veil of misinformation.

Jack has been around for many years already now, with not much to show when considering how long it has been around.
Even now new audio apps don't always support it, which means Jack is still struggling to convince developers of it's usefulness.

Perhaps you don't have anything to show for it, but I do, and I believe most users of this forum do as well. Perhaps JACK is not the problem.

[tux99]

The statements apply equally to both Jeffs because, even if they are not the same individual, they have made the same statements to a T with one minor difference (apparently on some days Jeff likes LV2 and on others he hates it). They also have the same general attitude and nostalgia about Windows.

Sorry but that's not true at all, you clearly only skim read other peoples' posts. Jeff_G seems a nice chap to me (even if I don't agree with everything he says), while the author of PyDAW had quite an arrogant attitude.
Neither of them seem to have a nostalgia of Windows at all, only of how some Windows applications work.

Just because the OS sucks, that doesn't mean that all applications for it suck too.

Who said it doesn't apply? Why shouldn't it? Can you articulate any good reason?

As I already mentioned (please don't skim read if you reply to my posts) the fundamental difference is scripting versus interactive use.

Such a plugin system doesn't exist.

VST seems quite well thought out and supported to me and LV2 doesn't seem bad to me either, so claiming that it doesn't exist is nonsense.

And who is going to tell all the would-be application developers that they have been relegated to being mere plugin designers?

This is the weirdest reason I have heard so far. What's the difference between writing a softsynth as LV2 plugin with GUI or as Jack app? Why do you consider writing a plugin inferior to writing a Jack app?

Perhaps you don't have anything to show for it, but I do, and I believe most users of this forum do as well. Perhaps JACK is not the problem.

Huh? What do I have to do with this? I'm talking about Linux apps written for Jack, not people.

[ssj71]

tux99, there are issues with LV2. They only released version 1.0 a few months ago. The issues aren't very apparent to an end user though. I don't know all the issues, but I think male is right that no perfect plugin api exists. LinuxDSP develops both VST and LV2 apps and says they're about the same, and neither is perfect.

http://libregraphicsworld.org/blog/entr ... standpoint

But they are working on it actively.

Jeffg, please don't kiss me. Isn't implementing plugin hosting going to significantly increase the complexity of your program? How will it affect maintenance as LV2 is still young and changing?

male, please don't mix up Jeffs.

All in all this is a VERY fascinating discussion to me.

[tux99]

tux99, there are issues with LV2. They only released version 1.0 a few months ago. The issues aren't very apparent to an end user though. I don't know all the issues, but I think male is right that no perfect plugin api exists. LinuxDSP develops both VST and LV2 apps and says they're about the same, and neither is perfect.

Sure, I didn't mean VST and LV2 are perfect (does a perfect software or API even exist?), just that they are good enough to be usable. Jack is far from perfect itself, too.

[ssj71]

Sure, I didn't mean VST and LV2 are perfect (does a perfect software or API even exist?), just that they are good enough to be usable. Jack is far from perfect itself, too.

Yes.

[tux99]

All programmers are arrogant. If we make it through java with our sanity intact, we know we're invincible. Learn your place, you expendable enduser! Wait, you maintain a repo, Bruce. Let me check the LSB... Yep, according to the official hierarchy, you're one level above enduser. You puny packager.

Actually I do some programming too:
http://www.linuxmusicians.com/viewtopic ... 24&t=10412