[MPlayer-dev-eng] extracting libao2
Youness Alaoui
kakaroto at kakaroto.homelinux.net
Sun Mar 16 19:42:12 CET 2008
Hi,
I'm an aMSN developer and I'm currently working on voice conferencing for aMSN. For that, we need a good audio output
library, and while trying to find a good solution for us, I found libao (from xiph.org) which worked just fine and I
was happy with it apart from the following limitations :
1 - it doesn't support mixing (get/set volume)
2 - it seems to be unmaintained for years
3 - no dsound driver for windows, only winmm which didn't seem to work for me
So, I've been looking around again and saw an article about mplayer having forked libao and made it into libao2,
improved it, added a few more drivers support for it (for example, dsound) and it much more stable. So I gave it a
try, downloaded mplayer snapshot and looked at the libao2 code...
Here are my new disappointments :
1 - the API is not as great as libao, you get a functions structure and you call the functions from there.
2 - it uses global variables everywhere, so you can only 'open' once the device, instead of being able to open it
multiple times (if possible like alsa+dmix).
2 - It's not plugin-able, so if you compile with alsa/oss/arts/esd, if you try to launch it on a system without arts
library for example, then the whole libao2 can't be loaded (missing symbol).
3 - it's hooked to mplayer, as it uses a lot of mp_msg(...) and one exit_player() call.
4 - Not much documentation, so I don't really know what some new API functions are for..
I think that's about it..
But the great advantage that libao2 has, is that it is maintained and stable and has support for more drivers, and has
mixing support for getting/setting the volume.
Now, my current plan is to take libao and merge it with libao2. I suppose libao2 is a fork of libao when it was still
immature that's why it doesn't have the same API. I want to make libao2 use a plugins system like libao (a .so per
driver and have libao2 dynamically load the drivers, so you can ship a binary with all the drivers compiled and only
the ones with their dependant libs installed will be able to load). I also plan on making it use an API that looks
like libao's API, in other words, have a : ao_open, ao_play, ao_control, ao_close, etc.. which will use an ao_device
structure returned by ao_open (so we can open multiple times and play multiple streams and have it mixed by
arts/esd/alsa/oss). This also means that all global variables will be removed and made into a private structure for
the ao_device. And of course, remove all the references to mplayer (includes, mp_msg, exit_player)
Now, my question to you is : Would you be interested in sharing the effort for this project and help me make this
library as a standalone library. It is probably the best audio output library out there, so it's really a shame that
it's not standalone, so other projects could benefit from it.
The important thing here is to avoid having yet another fork, so if we could work on a design that we would both agree
on, so that this new libao2 can be put into mplayer and have mplayer use it, to ease any backporting of bugfixes,
etc..
Can you please tell me what you'd like (maybe a 'ao_set_log_function' API for mp_msg?) to make sure my changes will
get accepted and committed in your repository.
I'd also like to know if anyone would be interested in helping me do this, as my current free time is pretty limited.
Thank you!
KaKaRoTo
More information about the MPlayer-dev-eng
mailing list