API target [LWN.net]

API target

Posted Oct 7, 2009 20:02 UTC (Wed) by ncm (guest, #165)
In reply to: API target by drag
Parent article: LPC: The past, present, and future of Linux audio

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.

to post comments

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.