Menu
▾
▴
[fuse-emulator-devel] [ fuse-emulator-Patches-1050780 ] libao sound output driver
|
From: SourceForge.net <no...@so...> - 2005-01-15 18:34:51
|
Patches item #1050780, was opened at 2004-10-20 14:50 Message generated for change (Comment added) made by pak21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=596650&aid=1050780&group_id=91293 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Gergely Szasz (szaszg) Assigned to: Philip Kendall (pak21) Summary: libao sound output driver Initial Comment: This patch add a libao output driver to sound section (aosound). This little cross platform audio library (made by vorbis people http://www.xiph.org/ao/) offer a simple interface to a lot of additional audio platform: alsa0.5, alsa0.9+, aix, irix, nas, esd, arts, and some audio file: au, wav, raw and have oss, sun, and a null output. If fuse compiled with the SDL GUI, never selected the AO driver, but if the libao present, the AO driver compiled. We determine the output of AO through the -d option, and we can add driver options. e.g.: fuse -d alsa09:use_mmap=1,buf_time=1500 where alsa09 is the AO driver name, first option is use_mmap, second is buf_time... There is a special option file or filename. For file outputs we can give a filename through this option. e.g.: fuse -d wav produce the fuse-sound.ao default file, but fuse -d:file=fuse.wav dump sound into fuse.wav. Gergely ---------------------------------------------------------------------- >Comment By: Philip Kendall (pak21) Date: 2005-01-15 18:34 Message: Logged In: YES user_id=29214 Documentation committed so closing the tracker item. Thanks for all this :-) ---------------------------------------------------------------------- Comment By: Gergely Szasz (szaszg) Date: 2005-01-03 14:17 Message: Logged In: YES user_id=57243 New patch for the updated cvs... ---------------------------------------------------------------------- Comment By: Gergely Szasz (szaszg) Date: 2005-01-02 23:08 Message: Logged In: YES user_id=57243 Here is a fixup and a documentation (included in fuse.1 manpage) for libao driver. Gergely P.s.: with the GTK UI libao file outputs (wav, au, raw) not work properly... Not record sound at all (but the file created). With the svga and the pure X UI everything is OK! ???? ---------------------------------------------------------------------- Comment By: Gergely Szasz (szaszg) Date: 2004-11-14 23:04 Message: Logged In: YES user_id=57243 Hi Philip! Here is a little correction on configure in (if you do not do already :-), to disable libao if we not need... here is the new configure.in part: dnl Check if a version of libao which supplies ao_open_live is available AC_MSG_CHECKING(whether libao requested) AC_ARG_WITH(libao, [ --without-libao don't use libao], if test "$withval" = no; then libao=no; else libao=yes; fi, libao=yes) AC_MSG_RESULT($libao) if test "$libao" = yes; then AC_CHECK_LIB( ao, ao_open_live, [AC_CHECK_HEADER( ao/ao.h, [AC_DEFINE([USE_LIBAO], 1, [Defined if we're going to be using the install [AC_MSG_WARN(ao/ao.h not found - no libao sound output)] )], [AC_MSG_WARN(ao_open_live not found - no libao sound output)] ) AC_SUBST(AO_LIBS) fi and I include a new patch. Gergely ---------------------------------------------------------------------- Comment By: Philip Kendall (pak21) Date: 2004-11-13 23:04 Message: Logged In: YES user_id=29214 Applied with cosmetic fixups by me. TODO: write documentation. ---------------------------------------------------------------------- Comment By: Gergely Szasz (szaszg) Date: 2004-10-31 11:17 Message: Logged In: YES user_id=57243 This is prevent the driver to hook in an endless loop. Ok. What is the problem? If fuse display a menu or a widget, close the sound system, and after close the menu (widget) initialize the sound system again. If we trigger a menu/widget from the sound initialization code (e.g. a warning), fuse close the sound, and after disappeare the widget initialize again the sound, so we trigger the same menu/widget and so on... The solution: we use the sound_lowlevel_init_in_progress static variable, to flag the sound initialization called during a previouse sound initialization. Ok if we first reach the sound initialization the value of the variable is 0. So, we set it to 1. If we print an error message during initialization, fuse initialize sound once again, but now the value of the variable is 1, so we return immediately from the code... Gergelt ---------------------------------------------------------------------- Comment By: Fredrick Meunier (fredm) Date: 2004-10-24 13:57 Message: Logged In: YES user_id=11017 Why do you need sound_lowlevel_init_in_progress? I don't like how complicated the new flag looks, is it possible to default sensibly? ---------------------------------------------------------------------- Comment By: Gergely Szasz (szaszg) Date: 2004-10-22 07:01 Message: Logged In: YES user_id=57243 This new patch I remove the fprintf calls, and replace by ui_error... (It will be better, if the enter on the menu system not close the sound system, just pause, or do nothing...) Gergely ---------------------------------------------------------------------- Comment By: Gergely Szasz (szaszg) Date: 2004-10-21 15:00 Message: Logged In: YES user_id=57243 This new patch I remove the fprintf calls, and replace by ui_error... (It will be better, if the enter on the menu system not close the sound system, just pause, or do nothing...) Gergely ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=596650&aid=1050780&group_id=91293 |
