On Mon, Apr 14, 2008 at 6:04 PM, Arnold Krille <arnold(a)arnoldarts.de> wrote:
Where does PulseAudio come into that picture? - When the gnome-guys realized
that esd is out of date and they want a new api/lib. Unfortunately they
decided to a) write their own and not adopt what is there and b) to go
audio-only which means no chance of KDE adopting it (apart from the fact that
kde already has Phonon). So PulseAudio is by design not _the_ solution for
sound on the desktop. It is just another middle-layer for sound. And why
should a desktop-app-dev adopt PulseAudio when he would have to use another
api/lib for video? Isn't it better to use one api/lib that has both and even
does them in sync?
Isn't comparing Phonon and PulseAudio apples and oranges though? If I
understand the situation correctly Phonon is just an abstraction layer
that interfaces with various multimedia frameworks, whereas PulseAudio
is an actual sound server. Even if the gnome guys had adopted Phonon
that wouldn't have fixed the esd situation (old, unmaintained sound
server). PulseAudio is a drop in replacement for esd and if you want
to use Phonon you could (I assume at least in theory) use PulseAudio
as a backend for it (or PulseAudio via gstreamer or xinelib or
whatever).
And PulseAudio claims to unify both desktop-needs and
pro-audio-needs. Another
place it will fail big time. Because it will never be good enough to have
ardour use PulseAudio. (Hint: Jack was designed for ardour...)
Are there fundamental design decisions in PulseAudio that would make
this impossible, as opposed to just difficult or a lot of work?
(sincere question, I have no idea)
As cool as Jack is surely it would be nice to have a sound
architecture on linux that seamlessly supported pro-needs as well as
typical desktop needs?
Cheers....Steve