Which Sound Library To Use?

[sinoth]

Heya all, I'm putting together a framework for game programming on Pandora. So far I'm using C++ with OpenGL, with the glfw library taking care of initialization and input. In the past I've used fmod for sound, but I'm not sure that will be easily portable.

Does anyone have any other suggestions for a lightweight sound library, or whether or not fmod will be easy to port? I know SDL has a basic sound library but I'd rather steer clear of it for now. Thanks!

EDIT: Just did some poking around the fmod forums and it looks like they have no planned ARM support. So still looking for a good lightweight alternative

 

[Pickle]

OSS?

 

[Julius]

OpenAL?

Not sure if this is also an option:
http://audiere.sourceforge.net/

and
http://www.portaudio.com/

 

[samuraicrow]

If you're going to use a verison of OpenAL for Linux, be sure it is OpenAL-Soft. The regular versions really stink.

 

[sindbad]

OpenAL is used by many games, either directly or through another layer of indirection and it will work.
NEVER use OSS directly. In a worst case scenario, use ALSA or Pulseaudio.
I've used portaudio from python a bit and it's quite comfortable to use.
Audiere is old.

If you don't like SDL, take a look at SFML.

 

[Spirit]

NEVER use OSS directly.

Why not? ALSA and Pulseaudio don't seem too nice.
I switched from ALSA to OSS after reading this and my whole experience with sound on Linux has went straight up into the heavens of happiness.

I guess it would be best to base this choice on the Pandora's hardware and default configuration anyways.

edit: I am really interested in the arguments against OSS, not trolling!

 

[sindbad]

OSS has some advantages: it's ubiquitous in the unix world, has a simpler API than ALSA and is in general much simpler.

The biggest problem is that OSS (on most linux boxes at least) doesn't support mixing. ALSA has dmix to easily solve this and sound servers (like pulseaudio) have even more sophisticated solutions. There is a wrapper to use the OSS API on ALSA, but it's not quite reliable.

It's an unfortunate situation, but there's not much to do other than use another abstraction layer like Phonon or OpenAL (which come with additional features).

 

[Spirit]

Oh, that is not true anymore. Actually the biggest reason for me to switch to OSS was that ALSA had lots of trouble with mixing for me. Now with OSS it just works.
I am rather new with Linux, but it seems OSS improved a lot lately plus they released it under free licenses again.

 

[TomCooksey]

It's quite nice to see OSS making a comeback.

Having said that, I know there's been a lot of work put into ALSA SoC to make ALSA a bit more power-efficient:

http://opensource.wolfsonmicro.com/node/6

I think it does nice things like turning the audio amps off when there's no audio being sent to the speakers, that kind of thing. Not sure if OSS does that level of fine-grained power management? Although I also don't think the Pandora is using the ASoC driver either?

 

[Svartalf]

edit: I am really interested in the arguments against OSS, not trolling!

1) The odds are VERY good that ASoC is what's going to be the sound layer interface on the SOC (Since the Davinci DSP drivers are one of the actual supported edges...).

2) OSS is only used by LGP to ensure full compatibility with *BSD and Solaris X86 systems (They can run Linux binaries if the driver edges, etc. are the same ones used on those systems...)- and this usage is through SDL or OpenAL when we do it. Of late, this sole support is causing issues with PulseAudio and some ALSA configurations because the OSS support's "good" but not quite good enough. Bandits: Phoenix Rising has been further delayed (than it already has...) because I'm having to rework portions of the sound system setup on the game to fix these problems.

3) Most people don't do direct to sound driver layer programming because it's clumsy. Most people use SDL, Portaudio, FMOD, OpenAL, etc. And those relatively thin abstraction layers handle things like callbacks for when you need to feed more sound to the driver layer for playback. No such thing exists and you typically have to roll something to sync things yourself if you don't use one of these other libraries.

I think it does nice things like turning the audio amps off when there's no audio being sent to the speakers, that kind of thing. Not sure if OSS does that level of fine-grained power management? Although I also don't think the Pandora is using the ASoC driver either?

That remains to be seen. The DSP is a DaVinci derivative- that may be what gets used. I can tell you that it's unlikely (There's a hint there... ) we'll have OSS drivers for the device. If the work's already been mostly done in ALSA, it'd be silly to come up with an OSS driver. And, it's my understanding that the OSS drivers don't have that level of power management because they've not had to do things like that.

 

[yosh64]

hey

I would have to recommend SDL_mixer, although I haven't done too much with it, nor have I tried anything else. Anyhows you can easily play common sound and music formats with it, see http://www.libsdl.org/projects/SDL_mixer/.

I'm actually looking forward to when there is a linux port of BASSMIDI, see http://www.un4seen.com. Although I don't think this is opensource, so ya probably won't see it on the pandora, hehe. But yea, the MIDI plugin for xmplay on windows is just great, it's like it's own softsynth that supports soundfont2's .

Well I use SDL and SDL_mixer for the graphics/audio and what not of my 2d graphics/game lib, and I use SDL+OpenGL and SDL_mixer for my 3d graphics/game lib .

edit
If ya really eager you could make your own soundserver . I have actually made my own mod music player that is independent of the soundserver , ya just pass a buffer to mix into and then you could pass it onto the soundserver to be played. Anyhows my mod music player isn't quite up to scratch yet, but nevermind.

cyas

 

[Gammenon]

I would use SFML, it has everything you would need

 

[Svartalf]

I would use SFML, it has everything you would need

Why not use OpenAL-Soft, which SFML wraps, then?

While SFML claims to be modular, it does add on TOP of OpenAL-Soft. It's more bulk in your code and if you're only doing it for sound purposes, then something lighter weight would probably do better for them.

 

[cosam]

OSS?

Is OSS working on the Pandora already? I have a project which uses the API directly, so I'd like be able to make use of the existing code if possible.

 

[sindbad]

I suggest you try your project with alsa-oss and see if it works, only alsa is guaranteed to be there.

 

[sinoth]

I've experimented with some of the suggestions in the thread, and so far I like OpenAL-soft the best. As long as the port isn't too terrible, I think its a good choice for the Pandora. If OpenAL isn't available for some reason, I think my second choice would be interfacing with ALSA directly. It doesn't seem -too- bad.

 

[Svartalf]

I've experimented with some of the suggestions in the thread, and so far I like OpenAL-soft the best. As long as the port isn't too terrible, I think its a good choice for the Pandora. If OpenAL isn't available for some reason, I think my second choice would be interfacing with ALSA directly. It doesn't seem -too- bad.

I strongly suspect that OpenAL-Soft will be there. If someone hasn't already done it by the time I'm off of doing firmware work and on to doing the actual game porting, I'll make it happen. I kind of NEED it for at least a couple of the games I'm porting over.

You honestly want to use a bit of an abstraction layer. Direct ALSA coding is...painful. You'd be better off with SDL or OpenAL-Soft. Honest.