[CFP] Linux Plumbers Conference CFP ends soon! - Linux-audio-dev

Jörn Nettingsmeier

14 Jun 14 Jun

6:38 p.m.

Lennart Poettering wrote:

Heya! The Linux Plumbers Conference 2009 CFP ends soon! If you are working on Linux audio infrastructure then make sure to submit a paper for the audio track! Do it now, it'll soon be too late, you have time until June 15th! Why attend or submit a paper? Because this is *the* conference where you can make yourself heard and influence the lower levels of our audio stacks. If you have some beef with or something to contribute to the lower level sound (and other) infrastructure of modern Linuxes, then *this* is where to go.

very true. are any jack people going to make it? might make a lot of sense, especially for some jack people with insight into kernel and rt issues... the plumbers conference is a really good idea imho, our problem is that (semi-)pro linux audio is under-represented. that said, lennart, any chance you could make it to a LAC anytime soon? pa has got some heat lately, some deserved imho, some not, but it definitely serves a very palpable demand. i believe that after some time it can be a real blessing for casual users without necessary having to become a PITA for pro audio users - but for that, it would be nice to discuss the mutual needs and wishes over pizza. best, jörn

Reply

Lennart Poettering

7:19 p.m.

On Sat, 13.06.09 12:16, Jörn Nettingsmeier (nettings(a)folkwang-hochschule.de) wrote:

...

The Linux Plumbers Conference 2009 CFP ends soon! If you are working on Linux audio infrastructure then make sure to submit a paper for the audio track! Do it now, it'll soon be too late, you have time until June 15th! Why attend or submit a paper? Because this is *the* conference where you can make yourself heard and influence the lower levels of our audio stacks. If you have some beef with or something to contribute to the lower level sound (and other) infrastructure of modern Linuxes, then *this* is where to go.

very true. are any jack people going to make it? might make a lot of sense, especially for some jack people with insight into kernel and rt issues... the plumbers conference is a really good idea imho, our problem is that (semi-)pro linux audio is under-represented.

Seems Paul will be attending, but so far he hasn't posted his proposal. Hey, Paul! Please submit your proposal! It just takes 10 min or so. Just a title and a short blurb, that's about it. No long papers. http://linuxplumbersconf.org/ocw/events/2009/proposals/new But of course, the more people we can get to attend the better. As a side note, since you are mentioning RT: the biggest RT-on-the-desktop issues will hopefully be going away pretty soon. My plans for Fedora 12 are that we ship with the missing bits of infrastructure so that we can enable RT user processes by default without nasty security implications. This will then be used by PA and will also be available for JACK. And I am pretty sure the other distros will then incorporate the same stuff into their distros pretty quickl, too. I'll be announcing that shortly in more detail. Stay tuned.

...

that said, lennart, any chance you could make it to a LAC anytime soon?

This year's LAC didn't really fit into my schedule. But yes, I hope to be able to attend LAC 2010. We'll have to see.

...

pa has got some heat lately, some deserved imho, some not, but it definitely serves a very palpable demand. i believe that after some time it can be a real blessing for casual users without necessary having to become a PITA for pro audio users - but for that, it would be nice to discuss the mutual needs and wishes over pizza.

The situation shouldn't be that bad anymore. PA and JACK2 cooperate in a more friendly fashion these days when accessing audio devices: when jack asks for it PA will release the audio device, and when jack goes away PA will try to take it back. But yes, there's certainly a lot left to discuss. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

Reply

Lennart Poettering

8:54 p.m.

On Mon, 15.06.09 00:01, Fons Adriaensen (fons(a)kokkinizita.net) wrote:

...

On Sat, Jun 13, 2009 at 12:16:22PM +0200, Jörn Nettingsmeier wrote:

that said, lennart, any chance you could make it to a LAC anytime soon? pa has got some heat lately, some deserved imho, some not, but it definitely serves a very palpable demand. i believe that after some time it can be a real blessing for casual users without necessary having to become a PITA for pro audio users - but for that, it would be nice to discuss the mutual needs and wishes over pizza. [2]

I agree. I'm not a PA user - I dislike 'desktop sounds' and any serious app I expect to use Jack. But if PA could provide an interface that would allow Jack (or other apps) to connect to it *without any loss of performamce* compared to direct access of an Alsa hw: device, [1] then I wouldn't mind having it installed and being used.

The part about "without any loss of perfomance" is the big problem. Of course the latency increases each time you add an indirection. There is no way around this. A corollary of that is that PA and JACK need to have the same "distance" from the low-level device. The only way I see how that could work in an intregrated solution is if JACK and PA would merge in some way. While that might be a nice idea (which I certainly don't oppose) I don't see that coming in any way. It's simply that the playback models of PA and JACK are simply too different. PA uses very large hw buffers (2s), rewinding, timer-based audio scheduling (which allows us to adjust the wake up intervals dynamically to what the clients request), zero-copy IO, non-float sample types, and so on. That's all very useful for normal desktop use and for minimizing wakeups/power usage/CPU load. OTOH JACK's primary objective is low latencies, and power usage or non-floats, ... don't matter at all. Which effectively means sound card IRQ based scheduling and short buffers make much more sense. A hybrid engine that could do all of this and switch between timer-based scheduling and sound card IRQ based scheduling in one would probably be exceptionally complex, and I see noone who would be willing and have the time to work on that. [1] The only other way I see to give PA and JACK the same "distance" from the device is if PA goes out of the way when JACK runs. Which is basically what JACK2 and PA do now. It's a however only a pragmatic compromise, not more. Not many people work full-time on audio for Linux. Given that this is how it is pragmatic comprimises are probably what we have to work with.

...

Pizza ? In Holland ? More likely a 'broodje kroket'.

So I read from that that LAC 2010 happens in .nl? Lennart [1] Canonical appears to be looking for someone to hack on PA full time. So if someone wants to attack this issue, he might even get some funding for it if he does so under the PA umbrella. http://webapps.ubuntu.com/employment/canonical_DASE/ -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

Reply

alex stone

4:27 a.m.

On Mon, Jun 15, 2009 at 10:02 AM, Justin Smith<noisesmith(a)gmail.com> wrote:

...

On Sun, Jun 14, 2009 at 3:53 PM, Lennart Poettering<mzynq(a)0pointer.de> wrote:

On Mon, 15.06.09 00:01, Fons Adriaensen (fons(a)kokkinizita.net) wrote:

On Sat, Jun 13, 2009 at 12:16:22PM +0200, Jörn Nettingsmeier wrote:

that said, lennart, any chance you could make it to a LAC anytime soon? pa has got some heat lately, some deserved imho, some not, but it definitely serves a very palpable demand. i believe that after some time it can be a real blessing for casual users without necessary having to become a PITA for pro audio users - but for that, it would be nice to discuss the mutual needs and wishes over pizza. [2]

I agree. I'm not a PA user - I dislike 'desktop sounds' and any serious app I expect to use Jack. But if PA could provide an interface that would allow Jack (or other apps) to connect to it *without any loss of performamce* compared to direct access of an Alsa hw: device, [1] then I wouldn't mind having it installed and being used.

The part about "without any loss of perfomance" is the big problem. Of course the latency increases each time you add an indirection. There is no way around this. A corollary of that is that PA and JACK need to have the same "distance" from the low-level device. The only way I see how that could work in an intregrated solution is if JACK and PA would merge in some way. While that might be a nice idea (which I certainly don't oppose) I don't see that coming in any way. It's simply that the playback models of PA and JACK are simply too different. PA uses very large hw buffers (2s), rewinding, timer-based audio scheduling (which allows us to adjust the wake up intervals dynamically to what the clients request), zero-copy IO, non-float sample types, and so on. That's all very useful for normal desktop use and for minimizing wakeups/power usage/CPU load. OTOH JACK's primary objective is low latencies, and power usage or non-floats, ... don't matter at all. Which effectively means sound card IRQ based scheduling and short buffers make much more sense. A hybrid engine that could do all of this and switch between timer-based scheduling and sound card IRQ based scheduling in one would probably be exceptionally complex, and I see noone who would be willing and have the time to work on that. [1] The only other way I see to give PA and JACK the same "distance" from the device is if PA goes out of the way when JACK runs. Which is basically what JACK2 and PA do now. It's a however only a pragmatic compromise, not more. Not many people work full-time on audio for Linux. Given that this is how it is pragmatic comprimises are probably what we have to work with.

Pizza ? In Holland ? More likely a 'broodje kroket'.

So I read from that that LAC 2010 happens in .nl? Lennart [1] Canonical appears to be looking for someone to hack on PA full time. So if someone wants to attack this issue, he might even get some funding for it if he does so under the PA umbrella. http://webapps.ubuntu.com/employment/canonical_DASE/ -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

What about piggybacking pulseaudio on jack as default behavior if jack is running (without autoconnect to ports, preferably). You can figure that if someone has jack running they can handle doing a manual port connect, and with the kind of buffer sizes pulse likes, it would hardly be hampered by a jack backend, right? For a while I was using the pulseaudio jack-sink module as the default pulse output, and it worked nicely, then it just stopped working (this is debian lenny, PA version 0.9.10-3 with the goto10 and debian-multimedia.org lenny repositories). Pulse just gives a "Module load failed." when I try to load module-jack-sink in pacmd). _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

I would strongly argue against any attempt to "merge" jack and pulseaudio. That would add in my view an unwanted level of complexity that doesn't need to be there in the first place, in favour of 'domestic' use. And those compromises, including the perennial latency challenge, that is introduced by default by PA, in its design, would render "Pulsejack" obsolete and useless for serious and/or fulltime audio users. Windows did precisely this in it's early days, and despite a clamour from many, who wanted a decent sound system framework for fulltime work, MS decided they'd play to the majority, and give domestic users the priority over those who wanted to use the os for serious work. That's the reason ASIO was invented in the first place, to make up for the inadequacies in the core sound framework. It almost seems like a flagwaving parade for "all hail pulseaudio" at the moment. I have no problem with that in a domestic computer environment, but tinkering with jack, just to suit the domestic market, seems like an exercise in trying to kill off any kind of chance for serious audio users to enjoy what they've already had, and instills an unacceptable limitation, just like windows, reducing serious audio user to once again having to "beg" for tools they already have in the current form. I respectfully urge all involved to take a step back here, draw in a deep breath, and think about the massive advantage we would lose in linux audio, for the sake of the relentless surge towards a "windows" like linux environment, just to suit......" youtubers, and gamers". Only. Alex. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

Reply

alex stone

5:03 a.m.

On Mon, Jun 15, 2009 at 10:42 AM, Justin Smith<noisesmith(a)gmail.com> wrote:

...

On Sun, Jun 14, 2009 at 11:27 PM, alex stone<compose59(a)gmail.com> wrote:

On Mon, Jun 15, 2009 at 10:02 AM, Justin Smith<noisesmith(a)gmail.com> wrote:

On Sun, Jun 14, 2009 at 3:53 PM, Lennart Poettering<mzynq(a)0pointer.de> wrote:

On Mon, 15.06.09 00:01, Fons Adriaensen (fons(a)kokkinizita.net) wrote: > > On Sat, Jun 13, 2009 at 12:16:22PM +0200, Jörn Nettingsmeier wrote: > > > that said, lennart, any chance you could make it to a LAC anytime soon? > > pa has got some heat lately, some deserved imho, some not, but it > > definitely serves a very palpable demand. > > i believe that after some time it can be a real blessing for casual > > users without necessary having to become a PITA for pro audio users - > > but for that, it would be nice to discuss the mutual needs and wishes > > over pizza. [2] > > I agree. I'm not a PA user - I dislike 'desktop sounds' and any > serious app I expect to use Jack. But if PA could provide an > interface that would allow Jack (or other apps) to connect to it > *without any loss of performamce* compared to direct access of > an Alsa hw: device, [1] then I wouldn't mind having it installed > and being used. The part about "without any loss of perfomance" is the big problem. Of course the latency increases each time you add an indirection. There is no way around this. A corollary of that is that PA and JACK need to have the same "distance" from the low-level device. The only way I see how that could work in an intregrated solution is if JACK and PA would merge in some way. While that might be a nice idea (which I certainly don't oppose) I don't see that coming in any way. It's simply that the playback models of PA and JACK are simply too different. PA uses very large hw buffers (2s), rewinding, timer-based audio scheduling (which allows us to adjust the wake up intervals dynamically to what the clients request), zero-copy IO, non-float sample types, and so on. That's all very useful for normal desktop use and for minimizing wakeups/power usage/CPU load. OTOH JACK's primary objective is low latencies, and power usage or non-floats, ... don't matter at all. Which effectively means sound card IRQ based scheduling and short buffers make much more sense. A hybrid engine that could do all of this and switch between timer-based scheduling and sound card IRQ based scheduling in one would probably be exceptionally complex, and I see noone who would be willing and have the time to work on that. [1] The only other way I see to give PA and JACK the same "distance" from the device is if PA goes out of the way when JACK runs. Which is basically what JACK2 and PA do now. It's a however only a pragmatic compromise, not more. Not many people work full-time on audio for Linux. Given that this is how it is pragmatic comprimises are probably what we have to work with. > Pizza ? In Holland ? More likely a 'broodje kroket'. So I read from that that LAC 2010 happens in .nl? Lennart [1] Canonical appears to be looking for someone to hack on PA full time. So if someone wants to attack this issue, he might even get some funding for it if he does so under the PA umbrella. http://webapps.ubuntu.com/employment/canonical_DASE/ -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

What about piggybacking pulseaudio on jack as default behavior if jack is running (without autoconnect to ports, preferably). You can figure that if someone has jack running they can handle doing a manual port connect, and with the kind of buffer sizes pulse likes, it would hardly be hampered by a jack backend, right? For a while I was using the pulseaudio jack-sink module as the default pulse output, and it worked nicely, then it just stopped working (this is debian lenny, PA version 0.9.10-3 with the goto10 and debian-multimedia.org lenny repositories). Pulse just gives a "Module load failed." when I try to load module-jack-sink in pacmd). _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

I would strongly argue against any attempt to "merge" jack and pulseaudio. That would add in my view an unwanted level of complexity that doesn't need to be there in the first place, in favour of 'domestic' use. And those compromises, including the perennial latency challenge, that is introduced by default by PA, in its design, would render "Pulsejack" obsolete and useless for serious and/or fulltime audio users. Windows did precisely this in it's early days, and despite a clamour from many, who wanted a decent sound system framework for fulltime work, MS decided they'd play to the majority, and give domestic users the priority over those who wanted to use the os for serious work. That's the reason ASIO was invented in the first place, to make up for the inadequacies in the core sound framework. It almost seems like a flagwaving parade for "all hail pulseaudio" at the moment. I have no problem with that in a domestic computer environment, but tinkering with jack, just to suit the domestic market, seems like an exercise in trying to kill off any kind of chance for serious audio users to enjoy what they've already had, and instills an unacceptable limitation, just like windows, reducing serious audio user to once again having to "beg" for tools they already have in the current form. I respectfully urge all involved to take a step back here, draw in a deep breath, and think about the massive advantage we would lose in linux audio, for the sake of the relentless surge towards a "windows" like linux environment, just to suit......" youtubers, and gamers". Only. Alex. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

Alex, if you were replying to what I said, nothing I wrote recommended any change whatsoever to jack. What I was suggesting was having pulseadio use the existing jack backend and not autoconnect to any ports if jack is running when it starts up. Pulse already is capable of doing this in distros that are not broken, I was just recommending a default behavior that would save a bit of annoyance for us users who don't want to have to hand configure pulse audio, but do occasionally use non pro-audio software that should make sound. Sometimes I like to take a break from editing audio and watch a youtube video, for example, that can't be so rare. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Justin, I wasn't replying to you specifically. I guess you could say having been through all this with windows and mac, i'm leery of any push to "consolidate" linux audio in the same way, because I think the results will be the same. A compromise that seems to suit domestic users far more than it does serious users. If this were to take place, i'd use the last version of Jack possible without any PA intervention, and just keep it running for as long as i could, even if that meant no longer updating audio apps, because they required some form of new hybrid. But hey, i'm just a fulltime audio and midi user, and not a coder. So my opinion is going to mean little at the end of the day, if the quest for "potential" happens to take a turn i don't agree with. Life goes on. :) Alex. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

Reply

Fons Adriaensen

8:02 p.m.

On Mon, Jun 15, 2009 at 12:53:54AM +0200, Lennart Poettering wrote:

...

The part about "without any loss of perfomance" is the big problem. Of course the latency increases each time you add an indirection.

It shouldn't. When a Jack client connects to HW ports provided by the ALSA backend it gets exactly the same latency and data (only converted to/from float) as it would by using the ALSA device directly with the same HW params. There is no big mistery about how this is done, it's quite straightforward. The lowest level PA interface could just do the same. This would allow Jack to use it as a backend without any loss of performance, even allowing other PA clients at the same time. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

Reply