API target [LWN.net]

API target

Posted Oct 7, 2009 18:40 UTC (Wed) by ncm (guest, #165)
Parent article: LPC: The past, present, and future of Linux audio

Last time I read about this, the major gap was that application coders had no correct, stable, portable API to code against. Has there been any progress on that? Is ALSA (or some subset or future version) supposed to be that API now? What should somebody writing, e.g., a VoIP phone code against for maximum portability and minimum fuss?

to post comments

API target

Posted Oct 7, 2009 19:33 UTC (Wed) by drag (guest, #31333) [Link] (11 responses)

> What should somebody writing, e.g., a VoIP phone code against for maximum portability and minimum fuss?

The Maemo 5 folks and Palm WebOS folks seem to prefer to just write directly against PulseAudio for their audio needs.

Although for cross-platform compatibility your best bet would be to target Gstreamer since that runs on Alsa/PA/OSS/Windows/OSX/etc.

API target

Posted Oct 7, 2009 20:02 UTC (Wed) by ncm (guest, #165) [Link] (10 responses)

Thanks, drag, I suppose there really is an interpretation of "portability" that applies to Maemo and Palm targets, but it's not the one I meant.

API target

Posted Oct 7, 2009 21:12 UTC (Wed) by drag (guest, #31333) [Link] (8 responses)

I was just giving it as a example.

PulseAudio is portable also. It runs on Alsa/OSS/Windows/OSX/ blah blah blah. But I think for what your asking you'd have better luck with Gstreamer.

If you target Alsa then you can use the 'safe' subset that is supported by PulseAudio then you might be fine. It's possible to port the 'safe' parts of the libasound to other platforms, but what a pain.

You could target SDL and get cross platform compatibility, but that is mostly for game makers.

If you target full Alsa then that is Linux-only. If you OSS then that means it's only useful on some of the BSDs and possibly Solaris.

API target

Posted Oct 7, 2009 21:31 UTC (Wed) by ncm (guest, #165) [Link] (1 responses)

Thanks, I had not got that PA itself had been ported to all these platforms. That seems to change everything.

API target

Posted Oct 8, 2009 12:25 UTC (Thu) by nye (guest, #51576) [Link]

>Thanks, I had not got that PA itself had been ported to all these platforms. That seems to change everything.

Not so much - because it's only technically true (in other words, it's lies). A couple of years ago they managed to build it on a selection of platforms so they could claim 'portability' as a ticklist item.

Try building PulseAudio for Windows. When you've given up, try installing the binary package that is usually mentioned whenever this discussion comes up - it's two years old and I couldn't get it to work *at all* with a few hours' hair-pulling.

I don't know where the OS X idea came from - PA doesn't even *claim* to work there, and according to the PA website, the last time it was tested on anything other than Linux was 2007.

API target

Posted Oct 7, 2009 22:10 UTC (Wed) by ncm (guest, #165) [Link] (1 responses)

Do I understand correctly, that if I write directly to PA, then a PA server needs to be running alongside my program, but if I write to Gstreamer, then I might actually be talking to PA, or to ALSA, or to Apple's or MS's services, and most of my code needn't know which? I expect discovering microphones and headsets, and volume controls for them, will be a nuisance no matter what.

API target

Posted Oct 7, 2009 22:43 UTC (Wed) by drag (guest, #31333) [Link]

Yes. I think that is right. I never actually programmed anything dealing with
sound and expected it to work in windows (myself being limited to relatively
low-complexity python programs), but I expect that with Gstreamer you'll have
to depend on the platform to setup everything like that for you to use. So
it seems most appropriate for a standalone application you want to integrate
into the OS its running in.

API target

Posted Oct 8, 2009 12:09 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, some of those PA ports are very old. The last time PA was ported to Windows was so long ago that it predates glitch-free (which means years ago).

API target

Posted Oct 14, 2009 12:15 UTC (Wed) by pharm (guest, #22305) [Link] (2 responses)

If you target Alsa then you can use the 'safe' subset that is supported by PulseAudio then you might be fine.

The (slightly abrasive, but ultimately useful) discussion on the Braid blog about audio support under Linux eventually revealed that the safe Alsa subset isn't really a great deal of use, because you can't guarantee to get your hands on the audio ring buffer & rewrite the parts that haven't been played yet on the fly: The alsa mmap functions that let you do this aren't part of the safe core :(

The *biggest* issue that arose from that discussion was that it's well nigh on impossible for a developer to work out what they're expected to use if they need more than the basic SDL sound API (which can't do a great deal more than 'play this sound now please'). The safe ALSA subset plus the mmap alsa functions (since most hardware can expose those in reality) is probably it, but that isn't exactly well-advertised.

API target

Posted Oct 20, 2009 9:32 UTC (Tue) by njs (subscriber, #40338) [Link] (1 responses)

But, uh, the mmap functions can't possibly be supported over an emulated-in-userspace sound device, i.e., what we're all using now that our "alsa" output is going to pulseaudio?

A better API is clearly needed, but I don't think it involves mmap.

API target

Posted Oct 20, 2009 10:57 UTC (Tue) by cladisch (✭ supporter ✭, #50193) [Link]

> But, uh, the mmap functions can't possibly be supported over an emulated-in-userspace sound device

Classic mmap() can't. However, the ALSA API requires that the applications tells when and where it wants to access the buffer, and when it is done, so it is possible to emulate mmap on top on devices without a memory buffer. (In that case, the extra buffer adds latency, of course.)

> A better API is clearly needed

ALSA has snd_pcm_forward/rewind functions to move around in the buffer. However, these functions are optional, and the PulseAudio plugin does not implement them.

Gstreamer and codecs

Posted Oct 7, 2009 21:19 UTC (Wed) by dmarti (subscriber, #11625) [Link]

Gstreamer gives you much more than just a basic audio API. It also lets you easily use codecs that the user might have decided to install but that you don't want to distribute for whatever reason. The user can play MP3s or SID files, even if you just had FLAC and Ogg on your machine when you built the application.

API target

Posted Oct 9, 2009 5:44 UTC (Fri) by magnus (subscriber, #34778) [Link] (2 responses)

It's not my favorite API, but for a cross-platform (incl Windows) VoIP app, I probably would go with Portaudio.

SDL has a nice and friendly audio API, is cross-platform and has worked very well in my experience but it doesn't do recording.

The PulseAudio API is OK to work with as well. It probably would be my choice for a VoIP app if I didn't have to care about portability.

GStreamer is extremely focused on media-player like applications, and all API documentation is built around the assumption that data comes from somewhere else and you're just building a pipeline. Using an application as the data source seems so to be rare and it's not obvious how to do it.

API target

Posted Oct 15, 2009 10:12 UTC (Thu) by Uraeus (guest, #33755) [Link] (1 responses)

GStreamer is not focused on 'media player' type applications at all, GStreamer was designed from the very beginning to have a much wider use area. There is a large host of applications using GStreamer which are not media player style applications like Buzztard, Jokosher, PiTiVi, Arista, Transmageddon, Empathy and so on.

As for using an application for the data, that has been addressed quite some time ago and there are now two GStreamer elements called appsrc and appsink which specfically targets getting or sending data to an application.

API target

Posted Oct 17, 2009 21:21 UTC (Sat) by magnus (subscriber, #34778) [Link]

OK. I was speaking from my own experience from a couple of years ago, and I don't recall that appsrc/appsink existed at that time.

Still, I don't think that it is obvious how one should port an audio app using another audio API (ALSA for example) to use GStreamer for output. GStreamer seems to be designed more like a toolkit which you have to design your app around (like GTK for graphics) rather than just the audio bottom layer that most other API:s provide.