[LAD] [CFP] Linux Plumbers Conference CFP ends soon!

alex stone compose59 at gmail.com
Mon Jun 15 07:03:12 UTC 2009


On Mon, Jun 15, 2009 at 10:42 AM, Justin Smith<noisesmith at gmail.com> wrote:
> On Sun, Jun 14, 2009 at 11:27 PM, alex stone<compose59 at gmail.com> wrote:
>> On Mon, Jun 15, 2009 at 10:02 AM, Justin Smith<noisesmith at gmail.com> wrote:
>>> On Sun, Jun 14, 2009 at 3:53 PM, Lennart Poettering<mzynq at 0pointer.de> wrote:
>>>> On Mon, 15.06.09 00:01, Fons Adriaensen (fons at 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 at 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 at 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 at openoctave.org
>> development-subscribe at 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 at 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 at openoctave.org
development-subscribe at openoctave.org



More information about the Linux-audio-dev mailing list