Patrick Shirkey wrote:
>
> I wouldn't go that far. Lennart has proven to be open to our
> suggestions in the past and is prepared to work with everyone round
> here on the matter of desktop integration and to a degree system design.
>
I hope so. As I read this thread I'm further convinced that the
requirements for normal desktop audio and pro-audio are dissimilar
enough to demand very close inspection of any system sound component
added to a distribution or even to the kernel itself, especially any
component with the capability of wrecking the low-latency soft realtime
performance we've become accustomed to for serious recording on Linux. I
do not say that PulseAudio is a culprit here, I'm only emphasizing the
need for healthy vigilance regarding additions that have implication for
the existing working systems for serious recordists (i.e. JACK and ALSA).
> IMO what is missing at the moment is a unified plan from the LAD
> community for desktop integration that is compatible with the unified
> plan from the freedesktop community et al.
>
Ah, cat-herding. I agree with you, Patrick, I'm just not sure how easily
it'll get done, if at all.
> What I see is that Lennart and the others who have worked on
> pulseaudio have done such a good job at making the platform accessible
> to the desktop community that it has now become the defacto standard
> for Linux Audio.
>
> This was certainly helped by the insistence (for good reasons) that
> JACK is not designed for normal users or non realtime desktop apps and
> the lack of effort contributed to tackling the inherent issues.
>
> However we do have a problem now that needs to be sorted with
> integrating pa and jack in a way that is easy for everyone to work with.
>
Do they need integrated at all ?
I'm currently writing an article that asks that question (among others
re: the default Linux sound server). Frankly, I stand on the side of
those users who want *nothing* between JACK and ALSA, so whatever
solution finally presents itself, for me it must include the provision
for completely eliminating it, with no ill effects upon the rest of the
non-audio parts of the system. However, I also recognize the need for a
solution a la PulseAudio for the normal user.
I'm becoming further convinced that serious Linux audio production is
simply not going to be an out-of-the-box experience for users, that it
will always require intervention on the user's part, and that that
intervention will discourage some (many?) users from trying a Linux
system for creative audio work. We represent a very thin slice of the
Linux user pie, and our concerns don't appear to be priority concerns
for mainstream distro maintainers. And maybe that's not a bad thing.
> Clearly Lennart has found that PA needs to be able to handle realtime
> usage cases and is attempting in his best way to deal with those
> problems. However there is soooo much cross over here that it is
> becoming a dictatorial situation for those of us who are not
> intrinsically tied too the pulse audio system.
>
> Hence it is in everyones best interests to make sure this issue is
> resolved or else we will have another alsa vs oss situation on our
> hands for the foreseeable future.
Ah, but what does PulseAudio have to contend with ? Where is its
opposition ? Is there any other serious contender for the crown of the
default Linux sound server ? Lennart seems happiest about PulseAudio's
wide acceptance, which is fine, and I am glad to see him here trying to
make the system work to everyone's satisfaction. It remains to see
whether that's possible, but as long as PulseAudio can be easily and
fully removed, uninstalled, or toggled off, without damage or hindrance
to the rest of the system then I'm not sure if a real problem exists.
*How* PulseAudio can be removed etc is perhaps a problem best resolved
by the distro maintainers.
>
> By itself that is not a problem as that is the beauty of open source,
> but for the average user it is a real headache.
>
Perhaps we should require that the kernel developers and mainstream
distribution maintainers all run Ardour for three weeks and attempt at
least two multitrack/multichannel recordings. At least by then they'd
maybe have a better notion of what defines a system for serious
recording. ;)
For my purposes the entire discussion boils down to this: Will
PulseAudio negatively impact the excellent performance offered by 64
Studio, Planet CCRMA, JAD, or any other audio-optimized distribution ?
It appears that Lennart wants to make PulseAudio as transparent as
possible to the end user, but when I need to see it, I want to see it
all and I want to be able to control it completely, right down to
eliminating any trace of it, if that's what I desire. Again I say, I
have nothing against PulseAudio. I simply want a guarantee that its
existence does not threaten the continued excellent performance I've
come to expect from the kernels prepared for the audio-optimized
distributions. If that scenario can be warrantied then I'm a happy camper.
Okay, I've rambled enough. Better minds are making better points, but I
wanted to add my POV. Btw, I won't pretend to have followed this
discussion in all its technicalities, but as a user the topic is a
priority interest.
Best,
dp
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 23 16:15:05 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 16:15:05 EEST