A Guide Through The Linux Sound API Jungle [LWN.net]

A Guide Through The Linux Sound API Jungle

Posted Sep 27, 2008 23:32 UTC (Sat) by obi (guest, #5784)
In reply to: A Guide Through The Linux Sound API Jungle by quintesse
Parent article: A Guide Through The Linux Sound API Jungle

As for hindsight - of course; when KDE adopted aRts the multimedia world was a very different place. I don't think they could have foreseen that. But we've come a long way in the mean time, and I think it should've been possible to have a better idea of where things were going in 2006. Yes, you ran the risk of getting burnt again, but the chances were smaller.

I'd also forgotten KDE 3.xx was out for over 6 years. But still, see my reply to pynm0001 - I think that maintaining gst 0.10 would not have been an impossible task; at least the odds you'd get outside help would be bigger - I imagine there's more people familiar with gstreamer's codebase than Phonon's.

to post comments

A Guide Through The Linux Sound API Jungle

Posted Sep 28, 2008 13:00 UTC (Sun) by quintesse (guest, #14569) [Link] (3 responses)

I don't know Obi, why on earth do you care so much that KDE has made a small, thin wrapper layer around existing audio frameworks?

Because it's obvious in your reply to pynm0001 where you say "weighing the work required to create Phonon and its backend vs the potential work needed to maintain gst 0.10 for a while on your own" that you seem to think these are somehow related jobs in terms of time, effort and knowledge needed to be actually able to do it. They're not! Phonon is a pretty thin layer, no extensive knowledge of audio frameworks is needed neither to maintain it nor to make the backend "drivers", so the KDE devs are pretty confident that this time around, come hell or high water, they WILL be able to take KDE into the future.

Now if you can somehow come up with a reason why NOT using GStreamer directly is a huge mistake there would be something worth talking about, but right now we're just wasting our time.

A Guide Through The Linux Sound API Jungle

Posted Sep 28, 2008 14:25 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

obi's argument appears to be that maintaining phonon is wasted effort
because you have to adapt to changes in gstreamer's API anyway.

But this is erroneous, because if you have to maintain gstreamer yourself,
even if you don't add any features it's like maintaining a hundred
phonons: all those plugins then need to be maintained, and each of *those*
requires tracking changes in the downstream APIs... much more work.

A Guide Through The Linux Sound API Jungle

Posted Sep 28, 2008 23:50 UTC (Sun) by obi (guest, #5784) [Link] (1 responses)

Actually my argument was more along the line of: "I'd rather have a lot of people help maintain one framework (albeit an old branch), than have several libraries maintained by just a a few people each"; However if Phonon really is as thin as you guys say, and maintaining a stable gst 0.10 really would be like a hundred phonons - then I guess I'm just wrong. The point is moot especially considering Phonon is out there; sorry for wasting your time.

A Guide Through The Linux Sound API Jungle

Posted Sep 29, 2008 0:02 UTC (Mon) by nix (subscriber, #2304) [Link]

gstreamer basically consists of two pieces: the core, which provides
plumbing to connect together plugins, and the plugins. The majority of
those plugins are interfaces to other audio/video libraries (everything
from monsters like ffmpeg to little things like libogg or libmad). As
such, gstreamer has to track changes to the APIs of the libraries used by
all those plugins. (Thankfully, most are quite stable, but not all:
pulseaudio has bumped API in the last couple of years, and ffmpeg hardly
ever stops changing...)