The Sound Of Linux 2007 (Linux Journal) [LWN.net]

Dave Phillips highlights the best Linux audio achievements of the year in the Linux Journal. "If I had to select one piece of software that I consider to be crucial to Linux audio development, it'd be JACK. Almost all the software mentioned above either requires it or performs best with it. Some of JACK's notable improvements in 2007 include direct support for MIDI, improved support for multi-processor systems, and a new version for Windows. Linux can claim a variety of excellent sound and music applications, but JACK truly holds the keys to the kingdom."

(Log in to post comments)

The Sound Of Linux 2007 (Linux Journal)

Posted Jan 1, 2008 2:00 UTC (Tue) by drag (subscriber, #31333) [Link]

Jack is very cool. It's what turns a Linux PC into a Digital Audio Workstation (DAW).

From what I understand people are typically use to dealing with monolythic aplications that
are do-all for Windows or OS X. Lots of them have ways to route midi and pcm, but they tend to
proprietary to one company or another. 

With Linux you have lots of smaller, fairly competent, programs. With Jack you can combine
them how you want and introduce lots of fairly interesting plugins and filters and all sorts
of fancy stuff.

The Sound Of Linux 2007 (Linux Journal)

Posted Jan 1, 2008 18:40 UTC (Tue) by beoba (guest, #16942) [Link]

There's actually a common system used by most applications, called ReWire. I do not know it's technical merits or limitations, but I've lately been getting into audio editing and have seen support for it on nearly every app examined.

At least with music apps, since they all tend to be dual-platform, they're more likely to be architectured such that they could easily support Linux. I'm a big fan of Ableton, but it's Win/Mac, using DirectX(?) on one and CoreAudio on the other.

The Sound Of Linux 2007 (Linux Journal)

Posted Jan 2, 2008 17:05 UTC (Wed) by drag (subscriber, #31333) [Link]

Ya. I know that other implimentations existed before. But I think the major difference is that
Jack is core and works with almost everything. 

There are only a couple popular audio apps that are missing Jack support. I know Audacity was
a long holdout, but it's audio library stuff, portaudio, now supports jack. Beast/BSE was
another one, again depending on the portaudio libs, but on their website they have a
jacksupport page and it seems to be buggy.

Other then that pretty much any audio open source production/creation app you'd care to run on
Linux supports it.

The Sound Of Linux 2007 (Linux Journal)

Posted Jan 2, 2008 23:25 UTC (Wed) by tetromino (subscriber, #33846) [Link]

pulseaudio is designed for desktop earcandy. You use it to play mp3s and sound effects, not for serious recording studio work. Basically:

Hardware -> Alsa -> JACK -> pro audio software
                      |
                      v
                    pulseaudio -> media players

The Sound Of Linux 2007 (Linux Journal)

Posted Jan 3, 2008 20:07 UTC (Thu) by lysse (subscriber, #3190) [Link]

Couldn't the jack api be directly implemented by the kernel, to avoid the extra layer of
indirection?

The Sound Of Linux 2007 (Linux Journal)

Posted Jan 3, 2008 20:10 UTC (Thu) by lysse (subscriber, #3190) [Link]

(Answering myself. *sigh*)

Probably not, actually; it's based on callbacks, and I understand that the last thing you'd
want to do is have the kernel calling random bits of user code...

Which raises the question: is there a safe, fast way to implement something equivalent to a
callback interface over a kernel/user barrier? If not, perhaps I've stumbled upon the
advantage of microkernels... :)

The Sound Of Linux 2007 (Linux Journal)

Posted Jan 4, 2008 0:41 UTC (Fri) by njs (subscriber, #40338) [Link]

>is there a safe, fast way to implement something equivalent to a callback interface over a
kernel/user barrier?

Sure, you just give userspace an fd that they can block on and read messages out of.
(Userspace has to do the dispatching of these messages into whatever callbacks it wants to call
itself, but that's easy.)  See articles in the last few months about signalfd and timerfd for
examples of this technique.

Or you can use signals; signal delivery literally consists of pausing a userspace process,
munging around a bit with its stack, and then making its instruction pointer jump to some
callback that the process previously registered (the "signal handler").  This is an awful API
though; fds are better.

That said, I don't know of any benefits to implementing jack in the kernel; kernel code is
harder to write and manage, and jack obviously can be made to work just fine in userspace.