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

Programming applications for making music on Linux.

Moderators: MattKingUSA, khz

male
Established Member
Posts: 232
Joined: Tue May 22, 2012 5:45 pm

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by 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.
Image
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by j_e_f_f_g »

ssj71 wrote: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.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

tux99
Established Member
Posts: 346
Joined: Fri Sep 28, 2012 10:42 am
Contact:

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by 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.
male wrote: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
Established Member
Posts: 232
Joined: Tue May 22, 2012 5:45 pm

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by male »

tux99 wrote:@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.
tux99 wrote:
male wrote: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?
tux99 wrote:
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.
tux99 wrote:
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.
Image
tux99
Established Member
Posts: 346
Joined: Fri Sep 28, 2012 10:42 am
Contact:

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by tux99 »

male wrote: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.
male wrote: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.
male wrote: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?
tux99 wrote: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. :roll:
ssj71
Established Member
Posts: 1294
Joined: Tue Sep 25, 2012 6:36 pm
Has thanked: 1 time

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by 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.
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.
_ssj71

music: https://soundcloud.com/ssj71
My plugins are Infamous! http://ssj71.github.io/infamousPlugins
I just want to get back to making music!
tux99
Established Member
Posts: 346
Joined: Fri Sep 28, 2012 10:42 am
Contact:

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by tux99 »

ssj71 wrote: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
Established Member
Posts: 1294
Joined: Tue Sep 25, 2012 6:36 pm
Has thanked: 1 time

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by 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.
_ssj71

music: https://soundcloud.com/ssj71
My plugins are Infamous! http://ssj71.github.io/infamousPlugins
I just want to get back to making music!
tux99
Established Member
Posts: 346
Joined: Fri Sep 28, 2012 10:42 am
Contact:

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by tux99 »

j_e_f_f_g wrote: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: :wink:
http://www.linuxmusicians.com/viewtopic ... 24&t=10412
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by j_e_f_f_g »

I haven't forgotten you, Bruce!
bruce wrote: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?
My view here is ambivalent. I disagree that ALSA rawmidi is "far easier to use" than Windows MIDI API. The quick take -- they're more or less comparable, with each API having certain advantages/disadvantages.

Now the gory details. Some clever guy at MS noticed that all MIDI msgs except SysEx are 3 bytes or less. The clever part is that, since Win386 ran exclusively on a 32-bit Intel CPUs, 32-bit registers are guaranteed, and he therefore thought "Why not bit-pack the entire msg in one register, and pass it from userspace to kernel space that way. Since no buffer is involved, no virtual to physical address translation is needed.". Very clever. So we have midiOutShort(). It's a marvel of efficiency (for a single message).

Contrast this with alsa's midi out which always requires data in a buffer, and therefore the address translation. Less efficient for a single msg.

But now we get to sysex, and here's where midiOutShort can't help. With alsa, you use the same rawmidi write to output sysex, the same way as everything else. Consistent. Simple. With Win, you use midiOutLong. Not only do you pass the data in a buffer, but one you need to "prepare" (once only), and wrap it in a MIDIHDR struct. What's all that then? It's your app saying to the MIDI driver:

Here's my buffer in userspace (ie my virtual address). I'm going to be filling it with data, and passing it to you again and again. You know you need to map it to a physical address to use it in kernel space (ring 0). Let's save time and do that once (and just this once) now. Here's this MIDIHDR that goes with it. There are lots of fields for your use only. Use them to store whatever you need, such that everytime I give you this MIDIHDR/buffer, you retrieve what you stored instead of doing a redundant, costly address translation.

With alsa, the address translation is done everytime, even if you pass the same buffer over and over. As you wind your way down rawmidi write and eventually get into the driver, you'll see:

to_ptr()

There it is. Innocent and demure, yes? Those are ones you have to watch out for.

Windows is going for performance, and exposes a slight bit of added "preparation" work on the programmer's part to get that (but only if dealing with the edge case of sysex. The vast majority of midi data occurs with midiOutShort, which is a breeze. Sysex is used primarily only with "patch editor" software. Just out of curiosity, did your use of MIDI involve that?).

ALSA is going more for the simplicity/consistency of the unix device read() paradigm.

Call it a wash there.

Now MIDI input is where things start to change. You're still dealing with the same disparate paradigms. Windows goes for performance again by bit-packing and passing you each midi msg in a cpu register (well, glue code pushes it on the stack)... except for sysex which is handled via the prepared MIDIHDR.

ALSA goes for unix write() consistency.

But Win does 2 really nice things:

1) It resolves running status for you.
2) It doesn't interspere realtime messages within other msgs. Each midi msg is input intact.

ALSA does neither. Resolving run stat is a PITA, so much so that, for the USBMIDI spec, it was mandated that run stat is no longer used. But what if your alsa app must support non-usb devices (like the midi jacks on an PCI card)? Then you must resolve it. The Win version of MidiView handles input with about 10 lines. The ALSA version is... what 30/40 lines? (You expect me to know my own code??) The vast majority of extra code is for resolving run stat.

But we get to sysex. Most drivers internally buffer input such that you can get away with one MIDIHDR. But there's that cheesy driver that doesn't so to be safe you need 2 MIDIHDRs, and do something called "double-buffering". That's a PITA. If you're writing a patch editor, I can see why you'd prefer alsa's handling of sysex.

Double-buf? Running stat? Which is the bigger PITA? Again, sysex is the edge case. The majority of midi traffic is msgs where you have to resolve run stat. So I should say Win wins.

But both are a freeking PITA, so I'm gonna call another draw.

Ok, Bruce?

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by j_e_f_f_g »

bruce wrote:I do some programming too:


Patch editor!

'splains your view vis a vis ALSA versus Win MIDI.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

tux99
Established Member
Posts: 346
Joined: Fri Sep 28, 2012 10:42 am
Contact:

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by tux99 »

j_e_f_f_g wrote:
bruce wrote: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?
[...]
Sysex is used primarily only with "patch editor" software. Just out of curiosity, did your use of MIDI involve that?).
[...]
But both are a freeking PITA, so I'm gonna call another draw.

Ok, Bruce?
Thanks for the interesting reply.
Yes my experience with both ALSA MIDI API and Windows MIDI API is based on writing a patch editor, so predominantly sysex.

Here is why I say ALSA MIDI is a lot easier (from a programmer point of view):

Sending a sysex dump to a synth (code snippet from my RM50 Manager program that supports both Linux and Windows):

Code: Select all

    if ($LINUX) {
        MIDI::ALSA::output( MIDI::ALSA::sysex( $dev_nr-1, $ddata, 0 ) );
        MIDI::ALSA::syncoutput();
    } elsif ($WINDOWS) {
        # fixme: for some weird reason $ddata doesn't work, substr($ddata) is needed
        my $buf="\xF0". substr($ddata,0,length($ddata)) ."\xF7";
        my $midihdr = pack ("PLLLLPLL", $buf, length $buf, 0, 0, 0, undef, 0, 0);
        my $lpMidiOutHdr = unpack('L!', pack('P', $midihdr));
        $midiOut->PrepareHeader($lpMidiOutHdr);
        $midiOut->LongMsg($lpMidiOutHdr);
        $midiOut->UnprepareHeader($lpMidiOutHdr);
    }
While the Linux code is nice and easy, the Windows code is far more long-winded.


Receiving a sysex dump:
The Linux code is straight forward, but I didn't implement it on Windows as I simply couldn't figure it out!

Code: Select all

    if ($LINUX) {
        MIDI::ALSA::output(MIDI::ALSA::sysex($dev_nr-1, $req_strg[$type][0], 0));
        while (1) {
            # read next ALSA input event
            my @alsaevent=MIDI::ALSA::input();
            # if the input connection has disappeared then exit
            if ( $alsaevent[0] == SND_SEQ_EVENT_PORT_UNSUBSCRIBED() ) {
                Error(\$mw,"Error: MIDI connection dropped.");
                return '';
            }
            # if we have received a sysex input event then do this
            elsif ( $alsaevent[0] == SND_SEQ_EVENT_SYSEX() ) {
                # save event data array
                my @data=@{$alsaevent[7]};
                # append sysex data chunk to $sysex_dump
                $tmp_dump=$tmp_dump.$data[0];
                # if last byte is F7 then sysex dump is complete
                if ( substr($data[0],-1) eq chr(247) ) {
                    last;
                }
            }
        }
    } elsif ($WINDOWS) {
        # add Windows specific code here
    }
Of course I'm not claiming that my code is optimized... patches are always welcome! :wink:
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by j_e_f_f_g »

Is that Perl?? Oh man, if you just done Python, i could have written you 2 py extension libs -- one for linux, one for win, to do the low level midi i/o.

I don't do Perl. It's the only thing with dollar signs I won't touch.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

tux99
Established Member
Posts: 346
Joined: Fri Sep 28, 2012 10:42 am
Contact:

Re: ALSA, JACK and other approaches (e.g. Windows Audio Syst

Post by tux99 »

j_e_f_f_g wrote:I don't do Perl. It's the only thing with dollar signs I won't touch.
Actually the Perl MIDI libraries for ALSA and Windows are 1:1 implementations of their C equivalents so it shouldn't look too unfamiliar to someone who knows C.

I tried Python once, but it felt like a straight-jacket compared to Perl. :wink:
User avatar
wrl
Established Member
Posts: 48
Joined: Wed Nov 03, 2010 12:46 am
Been thanked: 2 times

Re: MIDI View

Post by wrl »

raboof wrote:
j_e_f_f_g wrote:"Thanks.", sighs alsa. "Oh and while you were d**king around, I had 12 xruns. Better increase your latency buffer another 512 frames".
I think these are key comments. You (quite dramatically) describe how JACK introduces overhead. This is no surprise to anyone: after all, JACK uses ALSA as a back-end, so *anything* it does will be overhead compared to talking directly to ALSA.

However, 'overhead' and 'latency' are very different (though obviously related) things. If JACK is configured to use equivalent period sizes and buffer sizes compared to an ALSA application, it will have exactly the same latency.

So the real question here, where your second quote touches upon, is this one: is the overhead introduced by JACK (on a correctly configured system) so big that it forces you to use a larger buffer (because of missed deadlines aka xruns)? Or is the difference generally eclipsed by the processing needed to, well, do the actual audio processing (which you'll have to do regardless of whether you're doing it through JACK or through ALSA directly)? These are not rhetorical questions, they need to be backed up with data for the use case you're interested in.
j_e_f_f_g wrote:due to dealing with virtual address spaces
I'm still confused what the performance impact of virtual address spaces would be.
j_e_f_f_g wrote:Do I really need to explain how someone went from a jack app with 10 ms latency, to ed with a 4 frame buffer (surprised me) and 2 ms latency?
It's not clear to me whether this difference is caused by the JACK overhead, or by the fact that perhaps ed was simply coded more efficiently compared to the JACK app tested.
this post seems to have just been passed over, but raises several important counter-points to j_e_f_f_g's claims of JACK inefficiency.

in particular:
raboof wrote:is the overhead introduced by JACK (on a correctly configured system) so big that it forces you to use a larger buffer (because of missed deadlines aka xruns)?
j_e_f_f_g, what's your take on this?
Post Reply