1. I don’t really get why GNOME still needs an audio server. Doesn’t ALSA with dmix solve all problems for 99% of all people?

    If your sound card doesn’t work with ALSA+dmix, it seems that it would make more sense to put effort into quashing the driver bugs, rather than adding an extra layer for everyone.

    I could also imagine that you might want an audio server if you need network-transparent sound, but that again seems like a corner case.

  2. Because ALSA and dmix are wild and ornery, and the less we have to deal with them, the better. :-) Basically, we’re never going to get the kind of control out of ALSA that we can get out of a sound daemon like polypaudio.

  3. The amount of dmix bugs which the ALSA guys been ironing out during the last few years, I’d be very cautious about disregarding their experience and work like that.

  4. you are talking about advanced sound server controls, while all you need is a playfile API?

  5. Polypaudio uses an audio API that has been deprecated on the kernel side for 2 to 3 years. Widespread adoption of this would be a backwards step for Linux audio in general. Please focus on systems like gstreamer which provide many facilities for internal application design, but are generally neutral about how and where audio goes to and comes from outside of the application.

    Sending audio to or from a hardware audio interface is only part of the picture of what you want from an audio system these days, and Polypaudio doesn’t address other situations in a way that is useful across a broad range of applications.

  6. Paul, Polypaudio is highly pluggable, and already ships plugins for OSS, ALSA, etc. It always has! GStreamer is great, but it doesn’t perform the same function as an audio server. In fact, with the latest Polypaudio release and its improved GStreamer plugins, they’re a fantastic combination.

  7. I agree that GStreamer or ARTS are terrible — they’ve been the bane of the past 4 years of my linux-desktop-user life! GStreamer in particular has been over-engineered, and fundamentally very little help for the simple task of viewing a Flash presentation while playing an MP3 file in JuK.

    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.

  8. Justin, GStreamer plays no role in audio mixing, so please don’t judge it on those terms. Blame OSS, ALSA, esd and aRTS for being differently problematic, and pity the poor application developers who can’t keep them in line.

  9. I think it would be great if people wanting low-latency audio for recording/music applications could just step into that world without jumping through hoops on at least one OS.
    I think JACK would be an awesome sound server for the GNOME desktop. It would open a new eorld of possibilities for users (how easy is it currently to get the right side of a beatles record in both speakers .. or pipe your CD through a reverb while you’re playing a software synth along to it?).
    Some kind of Patchage (http://om-synth.nongnu.org/patchage.html) applet would be a really cool way of presenting the possibilities to the user.
    I think Bio2Jack could be set up by distros to cater for apps that aren’t yet jackified, and gstreamer-jack looks like it wouldn’t take long to get working properly.
    So whaddaya think? Has anyone really considered Jack (http://jackaudio.org/) as a desktop sound server?

  10. Justin: gstreamer is emphatically not terrible, although its not the best model for what it does IMHO.

    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.

  11. jdub: OSS and arts are officially deprecated. the OSS kernel drivers were deprecated more than 2 years ago, but ALSA provides the same (emulated) API in order to support apps that refuse to migrate. OSS is deeply problematic because with using LD_PRELOAD hacks, there is no way to interpose any code – the entire API is built on system calls and hence all of OSS is destined to live in the kernel. since there are rather strict rules about what can be in the kernel, this places many limitations on extending the functionality associated with 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.

  12. Paul, I’m well aware of how all of this fits together. I’m also painfully aware of how undesireable the ALSA API is, how it doesn’t solve enough of the problems in the desktop space (in particular mixing) and the concerns that application developers have about targeting it directly (unstable LGPL library vs. dumb syscalls). I’d be very happy if we never had to expose anyone to ALSA, thus my interest in GStreamer, Polypaudio and JACK. We talked about this at length during DAM 1.

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

  13. Hi jdub,

    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?

  14. jdub, sorry not sure who i am talking to.

    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.

  15. Paul, from what I understand the release notes of the new polypaudio release talk about a new utility that allows old-fashioned programs written for OSS to use polypaudio instead; it (partially) emulates /dev/dsp and re-routes everything sent to it through polypaudio (which probably uses ALSA on linux, and something else on other operating systems).

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

Comments are closed.

  • Related Content by Tag