jdub: now, will polypaudio be back in ubuntu for edgy?

when i read the info on the polypaudio site, it seems to be almost exclusively about the OSS API. i haven’t used polypaudio because i don’t have any use for it, so i haven’t had a reason to go beyond the existing docs.

if application developers worry about using dumb system calls, why do they use X? its stable? well, true. but the ALSA lib API has actually been very stable for at least 2 years now. not as long as X, but suggestive that its settled down. and why would they switch from dumb system calls to an API that is likely to have to evolve if it is to satisfy *all* desktop needs? i could be talking about ALSA lib or polypaudio or gstreamer here.

the point is that apple did this with coreaudio by fiat - we just have nobody capable to telling programmers to get in line behind a single standard, so instead everybody argues over what the standard should be.

Could you post a link to the mailing list discussions for those who are not versed in the sound server problems (I’m aware of dmix, esd (and why it was bad for video) and the deprecation of artsd) but you are clearly saying that ALSA’s dmix isn’t the way to go. Also where do hardware mixing cards fit into this?

I’m not sure why this is relevant, however. Polypaudio has never exclusively supported OSS.

artsd has been officially terminated by its lead developer, and in his announcement about this he explained very lucidly and cogently why he now considers the design of artsd to be a mistake.

esd was never intended to have its own API at all, but was meant to silently interpose between apps using the OSS API (i.e. system calls) using an LD_PRELOAD hack. there are now (in the recent 2.6 kernels) cooler ways of doing what esd does without the LD_PRELOAD hack, but that doesn’t mean that continuing to promote the use of the OSS API is a good thing.

my point in listing this is to illustrate that the problem with all these APIs primarily comes from application developers who refuse (and yes, they do adamantly refuse) to move to the sanctioned audio driver API for linux, which is ALSA. we continue to have to provide stupid hacks and wrappers to allow skype, flash and many other things to be rerouted, all because their authors refuse to migrate. whose fault? not entirely the app developers fault, i will admit. however, the apps are the easiest place to fix, and it would help if everyone could encourage projects that continue to use OSS to switch.

The central issues with with audio on Linux arise from the fact that there is no central authority to impose a single style of API on applications. We therefore end up with two classes of applications: “desktop” apps of the style mentioned in most responses here and “pro-audio/music” apps. The latter category have all switched (more or less) to use the same kind of callback driven API found in CoreAudio (OS X), ASIO/WDM (Windows) and now JACK (Linux and OSX). The desktop app developers do not want to deal with this style of API (and I can’t say I blame them, entirely). As a result, some kind of “wrapper” around a callback driven API seems appropriate and from what I can see, GStreamer is the best fit for that role so far, especially since it offers many other possibilities for data processing within the application as well.

I eventually figured out that most apps could be induced to output to esd; therefore the venerable esd was the only sound server that could be relied on widely. (The inducing wasn’t easy — I had to patch the source code for KDE before I figured out another hack by adding artsd to the mix.)

Polypaudio at least takes the approach of using ESOUND’s protocol, so being protocol-compatible and hopefully compatible that way while we wait for direct support to filter through the layers of CVS to release to desktop packages to distro.

by the way I’m excited to read about polypaudio’s RTP support though. The esd network support is still awesomely cool, and provided me with a way to use my mythbox as a remote speaker system. RTP sounds even better.