15 Jun
2009
15 Jun
'09
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:
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
On Mon, 15.06.09 00:01, Fons Adriaensen
(fons(a)kokkinizita.net) wrote:
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
On Sat, Jun 13, 2009 at 12:16:22PM +0200, Jörn Nettingsmeier wrote:
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.
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. 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