[gst-devel] JACK and GStreamer, from the horse's mouth
paul at linuxaudiosystems.com
Sat Nov 25 01:17:20 CET 2006
On Fri, 2006-11-24 at 15:08 +0100, Christian F.K. Schaller wrote:
> Well that is one way of approaching it, but from the discussions and
> conversations I had with the major distro's most of them are currently
> going for a solution around Pulse Audio instead.
right. when i was at OSDL's DAM-1 meeting, i urged several people to
forget about specific existing solutions (such as JACK, which several
attendees wanted to see adopted as "the sound server") and instead to
focus on programming APIs that were constructuted to facilitate using
any one of several sane backends. in short, a pull model that would
allow easy use of CoreAudio/JACK/WDM/ASIO/EASI and other similar styles
of audio programming.
i was invited to be at the UDS, and unfortunately could not be there due
to other prior arrangements.
> And so its said, I personally don't give a shit which solution is
> chosen, all I need is a system that mixes my sound before passing it to
> the shitty laptop soundcard which can only deal with one connection.
> Currently it is dmix giving me that, and it looks like it will be Pulse
> Audio in the next version of Fedora, but as long as it works I don't
> really care.
the problem is that this tends toward flying directly in the face of the
"single ecosystem model". luckily, pulseaudio itself has no inherent
mixing functionality. there is *no* way that any pro-audio users want
software mixing, software resampling or other similar functionality
happening under the hood. my impression is that pulseaudio is reasonably
designed in this respect. however, it continues to allow people to write
push-style applications, and i think that the lesson from CoreAudio is
that this is a mistake.
More information about the gstreamer-devel