Linux/FreeBSD/Mac OS X etc sound

Found a bug? Please report it, but remember to follow the bug reporting guidelines.
Missing a sane feature? Let us know!
But please do NOT request ports to other systems.

Moderator: ZSNES Mods

Best audio API

SDL
10
20%
AO
10
20%
OpenAL
14
29%
Semi Portable OSS
6
12%
Non Portable ALSA
5
10%
Non Portable CoreAudio
1
2%
Other
3
6%
 
Total votes: 49

Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

PulseAudio is not the future, because that's not how these things work. Read: http://insanecoding.blogspot.com/2007/0 ... linux.html

But regardless of all that, libao does PulseAudio too, http://xiph.org/ao/
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

I think the SDL port will be using libao, and the windows port using XAudio and maybe DirectSound if Windows 2000 support is in demand. DOS doesn't exist anymore so that rules it out.
Watering ur plants.
LiquidAcid
Rookie
Posts: 20
Joined: Thu Mar 01, 2007 6:47 pm

Post by LiquidAcid »

Huh, wasn't there a plan to use audiere for sound output? Or was it dropped?

Oh yes, have you looked into portaudio v19? It does only audio I/O, so it's a lot more lightweight than audiere.
byuu

Post by byuu »

LiquidAcid wrote:Oh yes, have you looked into portaudio v19? It does only audio I/O, so it's a lot more lightweight than audiere.
Good lord, I need to hire PortAudio's marketing department. Seriously. Or better yet, 4Front needs to.

Trust me, you do not want to use a sound server to play streaming game audio. You may not be familiar with what latency means now, but I guarantee you would be if ZSNES implemented a PortAudio driver.

The whole point of a sound server is to act as a buffer between the sound card and the audio API, allowing for things like software mixing (something ALSA and OSS already do) and broadcasting sound over a network, among other nifty things. To do that requires its own latency that cannot be less than double what you'd get from going directly to ALSA or OSS.
LiquidAcid
Rookie
Posts: 20
Joined: Thu Mar 01, 2007 6:47 pm

Post by LiquidAcid »

byuu wrote:Good lord, I need to hire PortAudio's marketing department. Seriously. Or better yet, 4Front needs to.
???
byuu wrote:Trust me, you do not want to use a sound server to play streaming game audio.
OK, I didn't know portaudio did implement a full sound server. I had the impression it was more like libao. I'm also no fan of soundservers, but I'm using pulseaudio from time to time because of the network streaming capability (of course latency is irrelevant when playing back music).
byuu wrote:You may not be familiar with what latency means now, but I guarantee you would be if ZSNES implemented a PortAudio driver.
Hey sry, I was just asking if someone consired using this API. I have only worked with OpenAL and FMOD some time ago, so I'm a kind of newbie in this field.
byuu wrote:The whole point of a sound server is to act as a buffer between the sound card and the audio API, allowing for things like software mixing (something ALSA and OSS already do) and broadcasting sound over a network, among other nifty things.
I know that.
byuu wrote:To do that requires its own latency that cannot be less than double what you'd get from going directly to ALSA or OSS.
I wad wondering if JACK is an alternate solution to the current problem of high latency. If I'm informed correctly about the current development the ZSNES devs want to use libao for the unix world.

And still wondering where Audiere was dropped.... :-)
byuu

Post by byuu »

> ???

Everywhere Linux I go is talking about PortAudio these days ... despite the fact that it won't actually fix anything, it'll just add yet another API to the growing list.

> OK, I didn't know portaudio did implement a full sound server.

It is considered a drop-in replacement for esd. libao is quite an awful API as well -- it's far too limited. I suppose it's great if all you want to do is play WAV files, though. And yes, latency only matters when input is involved. You can delay video as well to compensate for audio, but if you have input it will be very noticeable.

> Hey sry, I was just asking if someone consired using this API. I have only worked with OpenAL and FMOD some time ago, so I'm a kind of newbie in this field.

Well, this was discussed a mere two posts before yours. Sorry if I'm a bad mood about it. The whole Linux sound thing really annoys me, the more I learn about it. My OS of choice has the video/audio/input equivalent of Windows for Workgroups.

> I wad wondering if JACK is an alternate solution to the current problem of high latency.

No, wrapper APIs that perform their own mixing won't decrease latency, quite the opposite in fact.
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

I have written off linux as an OS I will personally support. I am using FreeBSD. Linux can't even recognize the raid on my standard Intel southbridge so fuck it. It corrupted my Vista install 3 times now and I am tired of reinstalling it. FreeBSD worked the first time. There are major issues with GRUB. So any *nix development I do now are on FreeBSD.
Watering ur plants.
CyberBotX
Lurker
Posts: 109
Joined: Sun Jan 30, 2005 10:06 pm
Location: Wouldn't you like to know?
Contact:

Post by CyberBotX »

Personally, I use FreeBSD as my main OS and Windows 2000 as a side OS (being that I use it on my laptop for school and in QEMU on my desktop), so it would be great to see sound work for both of those OSes. FreeBSD is really a great choice since they decided to stick with using an OSS-based backend for their audio drivers.
[url=http://www.cyberbotx.com/]SNES Sprite Animations[/url], made by an Insane Killer Robot.
I'm a computer programmer (in C++) and a future game designer.
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Here's the current situation besides custom implementations such as libao2 which wraps around everything except libao, whatever junk we throw in emulators, and newer stuff like Phonon.

Image

See: http://blogs.adobe.com/penguin.swf/2007 ... ungle.html
Make sure you read the comments.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Windows never had it this complicated.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
LiquidAcid
Rookie
Posts: 20
Joined: Thu Mar 01, 2007 6:47 pm

Post by LiquidAcid »

byuu wrote:Everywhere Linux I go is talking about PortAudio these days ... despite the fact that it won't actually fix anything, it'll just add yet another API to the growing list.
I'm frequently reading in the gentoo forums but I didn't encounter a massive wave of portaudio discussion.
byuu wrote:It is considered a drop-in replacement for esd.
Uhm, are you sure you're not talking about pulseaudio? I skimmed through the portaudio docs and don't find anything about audio server implementation. Maybe you can direct me to the part where they say so.
IIRC the line "... is a drop-in replacement for esd" is found somewhere on the pulseaudio wiki.
byuu wrote:libao is quite an awful API as well -- it's far too limited.
Then I don't know why you're complaining about another API like portaudio. I don't think libao can fix these fundamental problems without rewritting the entire API. So libao is going to stay this way, even if it has issues with streaming audio. So you either have the choice to avoid the problems (by some dirty hacks) or using another API.
byuu wrote:I suppose it's great if all you want to do is play WAV files, though. And yes, latency only matters when input is involved. You can delay video as well to compensate for audio, but if you have input it will be very noticeable.
So the problem is that there is no abstracting API that provides low latency, right?
libao does not, SDL does not, etc.
byuu wrote:Well, this was discussed a mere two posts before yours. Sorry if I'm a bad mood about it. The whole Linux sound thing really annoys me, the more I learn about it. My OS of choice has the video/audio/input equivalent of Windows for Workgroups.
When I had Windows for Workgroups on my computer I didn't even have a soundcard but only this tiny PC speaker :D
byuu wrote:No, wrapper APIs that perform their own mixing won't decrease latency, quite the opposite in fact.
According to the JACK FAQ (http://www.jackaudio.org/faq) it adds no additional latency to the stream. So either they are lying or we're wrong about the wrapper APIs (because I also had the impression that wrapping had to add additional latency?!).

I proposed JACK because it has OSS, ALSA and MacOS backends, AND because of the low latency claim (I read about low latency first, not about zero like in the FAQ). This way you have audio on all major unix operating systems.
DataPath
Lurker
Posts: 128
Joined: Wed Jul 28, 2004 1:35 am
Contact:

Post by DataPath »

Nach wrote:Here's the current situation besides custom implementations such as libao2 which wraps around everything except libao, whatever junk we throw in emulators, and newer stuff like Phonon.

Image

See: http://blogs.adobe.com/penguin.swf/2007 ... ungle.html
Make sure you read the comments.
It's not exactly accurate, since PulseAudio doesn't use ESD, it is (or rather implements the interface of) ESD.

It also has some kind of network transparency, and I don't think it's NAS, but I could be wrong.

Also, a large number of those are meant to also be cross-platform abstractions (especially Allegro, SDL, and NAS, but also GStreamer) - which means there's not really a decent comparison with with what's available on other platforms.
byuu

Post by byuu »

Uhm, are you sure you're not talking about pulseaudio?
Oh, good lord ... there's another one? Does it ever end?? My apologies, then. Yes, I was referring to pulseaudio.
Then I don't know why you're complaining about another API like portaudio.
On the contrary, I think they're all equally awful. My ideal API would be one that accessed the hardware directly, and was implemented natively on as many platforms as possible. None of that libao -> aRts -> ALSA -> soundcard stuff. OpenAL is the closest thing we have to this, but you're pretty much limited to Creative if you want the hardware drivers, so it's not really a viable solution, either.
According to the JACK FAQ (http://www.jackaudio.org/faq) it adds no additional latency to the stream. So either they are lying or we're wrong about the wrapper APIs (because I also had the impression that wrapping had to add additional latency?!).
If it transmits through ALSA, then it's a flat out lie that it adds no latency. And in fact, it makes their low latency claim pointless, since it can never be less than ALSA's latency already.

However, I believe I read that JACK has the ability to utilize the ALSA drivers directly, which bypasses the userland ALSA programming API. If true, that's actually pretty cool. I could see JACK having a lower latency than the ALSA lib in this case. But you're still limited by the fact that the ALSA drivers themselves are, in most cases, subpar to other drivers such as OSS'.
LiquidAcid
Rookie
Posts: 20
Joined: Thu Mar 01, 2007 6:47 pm

Post by LiquidAcid »

DataPath wrote:It's not exactly accurate, since PulseAudio doesn't use ESD, it is (or rather implements the interface of) ESD.
Yep, that's what byuu already mentioned. And I must say that I'm quite happy with pulseaudio, something I way never when using ESD.
DataPath wrote:It also has some kind of network transparency, and I don't think it's NAS, but I could be wrong.
It's not fully transparent because you have to specify the server where the audio data gets sent to. You can elimate this problem by setting up multiple virtual ALSA devices which encapsulate the different setups. Works without major problems.
I think there was some discussion about implementation of a NAS plugin, but I don't know anything specific. At least I don't remember seeing such a thing in the latest release.
DataPath wrote:Also, a large number of those are meant to also be cross-platform abstractions (especially Allegro, SDL, and NAS, but also GStreamer) - which means there's not really a decent comparison with with what's available on other platforms.
We should also keep in mind that SDL and Allegro abstract a lot more than just the audio device. They're very different to libao and portaudio which only implement audio i/o and nothing more.
LiquidAcid
Rookie
Posts: 20
Joined: Thu Mar 01, 2007 6:47 pm

Post by LiquidAcid »

byuu wrote:Oh, good lord ... there's another one? Does it ever end?? My apologies, then. Yes, I was referring to pulseaudio.
I'd like to hear what you think about the portaudio API. Especially since it's not a soundserver implementation.
byuu wrote:On the contrary, I think they're all equally awful. My ideal API would be one that accessed the hardware directly, and was implemented natively on as many platforms as possible. None of that libao -> aRts -> ALSA -> soundcard stuff. OpenAL is the closest thing we have to this, but you're pretty much limited to Creative if you want the hardware drivers, so it's not really a viable solution, either.
I'd like to see the master of accurate SNES emulation becoming the master of low-latency audio streaming :D
byuu, writing such an API is the perfect job for you (after finishing bsnes) ;-)
byuu wrote:If it transmits through ALSA, then it's a flat out lie that it adds no latency. And in fact, it makes their low latency claim pointless, since it can never be less than ALSA's latency already.
That's what confused me at first.
byuu wrote:However, I believe I read that JACK has the ability to utilize the ALSA drivers directly, which bypasses the userland ALSA programming API. If true, that's actually pretty cool. I could see JACK having a lower latency than the ALSA lib in this case. But you're still limited by the fact that the ALSA drivers themselves are, in most cases, subpar to other drivers such as OSS'.
Any proof for these claims? I must say that I started linux audio with OSS drivers and had a lot of trouble getting these to work back then. Then, after quite a long time Windows-only, I came back to linux and started using ALSA. I'm currently driving a emu10k1 (desktop machine), hda-intel (crappy onboard codec in my laptop I'm writing this post from), usb-audio (external DIY DAC) and various old creative labs cards with ALSA.

The only two problems I had:
1) hda-intel produced lower volume than when using Windows: later it became evident that the increased volume in Windows was the real problem (lot of clipping which ruined the sound). I can do the same amplification trick with ALSA but it's not worth the trouble because it doesn't make the sound better.
2) USB bus disconnect problem with the DAC, that revealed to be a user problem (always be careful when soldering sensitive electronics)

I have read the post on the insane coding blog, but I only see ALSA bashing there and no real proof why OSS is so much better than ALSA. At least I think that it's great to have such a flexible API like ALSA.

I'm not saying that OSS is a bad thing. We will see in the future. It's always good to have two (or more) different projects competing with each other. If OSS is really so nice and easy to work with people are going to use it more, putting more pressure on the ALSA developers and ultimately making drivers on both sides better.

What I don't like at all are projects that open-source their product just because they're hoping to increase money flow (and let the community fix their bugs) and then complain about dropping sales...
byuu

Post by byuu »

byuu, writing such an API is the perfect job for you (after finishing bsnes)
The solution isn't to create yet another API. Instead, we should be improving what we already have and eliminate the older cruft.
I have read the post on the insane coding blog, but I only see ALSA bashing there and no real proof why OSS is so much better than ALSA. At least I think that it's great to have such a flexible API like ALSA.
My only experience has been using them. Sure, in applications that don't require much latency, everything is fine. When using libao in ALSA mode, I received terrible latency, >100ms. With OSS through aoss, it had severe problems with blocking, and crackled constantly. With OpenAL through ALSA, bsnes' framerate counter fluctuated between 58-62fps, with crackling the whole time.

The only thing I haven't added was a native ALSA driver. The ALSA API is way too complex for me, it has literally thousands of functions, and the documentation for it is absolutely terrible.

Now, when I loaded OSS4, the OSS driver had the lowest latency I've ever seen, and was smooth as glass. The OpenAL driver had slightly higher latency, but the API is much more developer friendly since you can pull off more tricks with a buffer+polling approach. Puts you more in control of blocking that way. I will say that libao still has bad latency, but it appears to be much better, something like ~60-80ms, but my measurements are obviously highly subjective. It could just be placebo.

Aside from that, the hissing I got when my volume was maxed was gone. And I was also able to get rid of more interference by muting the other inputs on my card, which I also tried with alsasmixer. I have much clearer audio now. The only things that broke from installing OSS4 were ALSA-only apps. Most just took some configuring to fix.

Now of course, your mileage may vary. Perhaps ALSA will work better for you. I have an HDA sound"card" myself.
I'm not saying that OSS is a bad thing. We will see in the future. It's always good to have two (or more) different projects competing with each other. If OSS is really so nice and easy to work with people are going to use it more, putting more pressure on the ALSA developers and ultimately making drivers on both sides better.
Well, let's hope. It seems few people even know about OSS vs ALSA. But yes, I agree that competition is humanity's best motivator. Friendly or otherwise.
What I don't like at all are projects that open-source their product just because they're hoping to increase money flow (and let the community fix their bugs) and then complain about dropping sales...
Amen to that. I completely agree with you about this. To be honest, I'm afraid the author will try and close up his OSS4 stuff again in the future to try and make more money. I also hate that his binary installer loads a time-restricted shareware application onto your machine. You have to download the source and build from that to avoid the time limit.

However, the code itself is GPL. Just as OSS3 continued even after the author closed it. I see no reason not to upgrade to OSS4 now that it's out, at least on the BSD platforms.

Ultimately, free / open source or not, I typically use the best tool for the job. Eg I use the nvidia binary, because nv is only a marginal improvement upon the vesa driver. Not much of an OSS idealist, I guess :/
kick
Trooper
Posts: 550
Joined: Wed Mar 01, 2006 8:47 pm

Post by kick »

Slightly offtopic: is there *any* Live BSD distro so I can try BSD and OSS4 without installing it to a hard drive?

OpenAL and the improved (multithreaded) version of Jack are the only candidates for now (both having low latency,great sound quality and versatility)
Jack tramples OpenAL when it comes to low latency.
It's not just the 'direct' access to drivers,there's also optimized threading,forced realtime operation and many other clever tricks involved which make Jack achieve its very low latency.By really low I mean something in the range of 10ms is standard fare for Jack on a very old single-core box. Not bad...at all :)
Even WINE now uses Jack as an option for sound output.

If Jack was a Windows API,it could be best described as something better than WDM Kernel Streaming but worse than native ASIO.
[i]Have a nice kick in da nutz[/i] @~@* c//
CyberBotX
Lurker
Posts: 109
Joined: Sun Jan 30, 2005 10:06 pm
Location: Wouldn't you like to know?
Contact:

Post by CyberBotX »

To answer your question, kick, you might want to try looking into FreeSBIE, it's a FreeBSD-based LiveCD.

I'm just hoping that whatever comes out of all this for sound, that it's as cross-platform as possible. It's good that current versions of ZSNES already work in FreeBSD as well as Linux, and I would hate to see it go down a path where it works with Linux only. (Excluding Windows, obviously)
[url=http://www.cyberbotx.com/]SNES Sprite Animations[/url], made by an Insane Killer Robot.
I'm a computer programmer (in C++) and a future game designer.
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

FreeBSD will always be supported as linux doesn't run properly with my system config. As well as I am getting fed up with GNU people and probably will propose we change our license soon.
Watering ur plants.
_willow_
Hazed
Posts: 51
Joined: Mon Dec 24, 2007 2:03 am
Location: Russia
Contact:

Post by _willow_ »

You can't have mixer and bit perfect transaction the same time. The sound should be distorted for the common sake, but only once, in system mixer, in single API.

Just look the sound stack for Windows Vista. Every sound bit got mixed through the single API. The same API can provide bit perfect copy of the single stream while blocking other streams. Indeed, very cool! Ether you remix you data yourself or every other application gets blocked. Your application can be banned too if the hardware already busy. I hope all OSes will get the same goodness.
[url=http://quake2xp.quakedev.com]quake2xp[/url] audio engineer
byuu

Post by byuu »

FreeBSD will always be supported as linux doesn't run properly with my system config. As well as I am getting fed up with GNU people and probably will propose we change our license soon.
Good to hear for FreeBSD support, and good luck changing your license. They'll fork it the second you try, and the 0.65% of your userbase (and coincidentally 75% of those who complain publicly) will switch over to the fork, even though it's just stagnated and gained no features since no experienced SNES devs are working on it. But it's free.
pagefault
ZSNES Developer
ZSNES Developer
Posts: 812
Joined: Tue Aug 17, 2004 5:24 am
Location: In your garden

Post by pagefault »

Their fork won't have any updated code in it, they can have 1.51. That's fine with me but I would prefer to have the latest bug free code.
Watering ur plants.
DataPath
Lurker
Posts: 128
Joined: Wed Jul 28, 2004 1:35 am
Contact:

Post by DataPath »

byuu wrote:
FreeBSD will always be supported as linux doesn't run properly with my system config. As well as I am getting fed up with GNU people and probably will propose we change our license soon.
Good to hear for FreeBSD support, and good luck changing your license. They'll fork it the second you try, and the 0.65% of your userbase (and coincidentally 75% of those who complain publicly) will switch over to the fork, even though it's just stagnated and gained no features since no experienced SNES devs are working on it. But it's free.
I know it certainly SEEMS that way, but I think it's generally mostly just a couple of squeaky wheels. I think most users of emulation software have more loyalty to the project than to some ideology or license.

Besides, if you really want to give them a taste of their own medicine, release a last GPLed version, but without the IPLROM.
byuu

Post by byuu »

I know it certainly SEEMS that way, but I think it's generally mostly
just a couple of squeaky wheels. I think most users of emulation software have more loyalty to the project than to some ideology or license.
Yeah, I was kind of hinting at that. The ones that get so vocal really only make up a fraction of a percentage, but they make more noise than everyone else combined about their ideals and such.

A real shame. I agree with them in general that code I can see and/or modify is ideal compared to closed source apps -- especially for emulators, but with the way they treat people who don't drink their Kool-Aid does much to harm their cause. I actually avoid the GPLv2 for my own software because of them.
Besides, if you really want to give them a taste of their own medicine, release a last GPLed version, but without the IPLROM.
Hahah, I like that idea. Make sure to mention in the code that it's not there because it violates the GPL :)

Another good idea would be to make the external IPLROM as difficult to load into the emulator as it is in MESS, bonus points for also requiring the DSP-N data ROMs to play non-DSP games (hi, Arbee ;)
That'll make 95% of users give up trying within the first half hour :)
kick
Trooper
Posts: 550
Joined: Wed Mar 01, 2006 8:47 pm

Post by kick »

pagefault wrote:FreeBSD will always be supported as linux doesn't run properly with my system config.
On the contrary,I have a similar experience with the much praised BSD: How come common hardware (such as Audigy2 ZS soundcards or ATI graphics cards) doesn't work or doesn't initialize properly in BSD? It seems to work only for those with onboard sound and Intel/NVIDIA graphics while others are SOL :(
Any OS,no matter how secure it may be is useless (as a desktop OS) without sound and hardware graphics acceleration.
Even the dreadful Ubuntu has more hardware support than all of the BSD distros combined.

I even tried the latest release of DesktopBSD,but no luck.

On the other hand,any live linux distro (Knoppix,Ubuntu,Fedora,Freespire,Puppy Linux,...) I put in my drive initializes the hardware correctly and works out of the box.

Is there any other live BSD distro I can try besides FreeSBIE and DesktopBSD?
Last edited by kick on Fri Jan 11, 2008 11:47 pm, edited 1 time in total.
[i]Have a nice kick in da nutz[/i] @~@* c//
Post Reply