libao issueshttps://gitlab.xiph.org/xiph/libao/-/issues2006-12-11T00:43:14Zhttps://gitlab.xiph.org/xiph/libao/-/issues/1086ao/ao.h contains invalid C prototype2006-12-11T00:43:14ZGitlab Botao/ao.h contains invalid C prototypeThe `ao/ao.h` header file contains an invalid C prototype for the function `ao_default_driver_id`. The keyword `void` should be added between the parentheses.
When compiling an application with GCC, using `-Wall -Werror -Wmissing-protot...The `ao/ao.h` header file contains an invalid C prototype for the function `ao_default_driver_id`. The keyword `void` should be added between the parentheses.
When compiling an application with GCC, using `-Wall -Werror -Wmissing-prototypes -Wstring-prototypes`, compilation fails.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1006enhacements for libao 0.8.62012-08-09T16:15:37Zrodrivgenhacements for libao 0.8.6it is mentioned in the TODO file of libao 0.8.6-1 (from debian sarge) that it is a "TODO" that libao do on the fly sample rate conversion.
it would be nice that converted to 2 channels if number of channels is not supported by the sound ...it is mentioned in the TODO file of libao 0.8.6-1 (from debian sarge) that it is a "TODO" that libao do on the fly sample rate conversion.
it would be nice that converted to 2 channels if number of channels is not supported by the sound card (e.g. my i810 only supports 2 channels)
it would be useful that ao_open_live returned a detailed description of the error when failing, since now it only returns NULL and sends things like "libao - OSS cannot set channels to 1" to stderr.
and also it would be nice a uniform method for selecting which sound card to use. say, sound card number n, with 0<=n. currently oss and alsa09 have different options for selecting sound card number and it needs a device name.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1005enhacements for libao 0.8.62006-07-19T08:07:47ZGitlab Botenhacements for libao 0.8.6it is mentioned in the TODO file of libao 0.8.6-1 (from debian sarge) that it is a "TODO" that libao do on the fly sample rate conversion.
it would be nice that converted to 2 channels if number of channels is not supported by the sound ...it is mentioned in the TODO file of libao 0.8.6-1 (from debian sarge) that it is a "TODO" that libao do on the fly sample rate conversion.
it would be nice that converted to 2 channels if number of channels is not supported by the sound card (e.g. my i810 only supports 2 channels)
it would be useful that ao_open_live returned a detailed description of the error when failing, since now it only returns NULL and sends things like "libao - OSS cannot set channels to 1" to stderr.
and also it would be nice a uniform method for selecting which sound card to use. say, sound card number n, with 0<=n. currently oss and alsa09 have different options for selecting sound card number and it needs a device name.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/940[PATCH] update libao-polyp to 0.9.02006-07-18T23:06:01ZGitlab Bot[PATCH] update libao-polyp to 0.9.0please update the polypaudio plugin to version 0.9.0.
http://0pointer.de/lennart/projects/libao-polyp/
please update the polypaudio plugin to version 0.9.0.
http://0pointer.de/lennart/projects/libao-polyp/
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/909libao does not detect alsa 1.0.11 and try to use artsd ?2006-05-12T09:58:57Zzebul666libao does not detect alsa 1.0.11 and try to use artsd ?hi.
i was in a console the other day. kde was not running and i decided to listen to some music.
i run mpg321 somefile.mp3
and got that error
Creating link /home/stef/.kde/socket-titan.
can't create mcop directory
i tried with ogg...hi.
i was in a console the other day. kde was not running and i decided to listen to some music.
i run mpg321 somefile.mp3
and got that error
Creating link /home/stef/.kde/socket-titan.
can't create mcop directory
i tried with ogg123 someogg.ogg
and the same !!
i wonder wtf ! a console app bugs me with kde (that i like by the way)
so i filled a bug to alsa because it happens when i upgraded from alsa 1.0.10 to 1.0.11rc3
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1950 (it seems you need a login)
and got no help
i found the solution in the libao doc.
it seems libao do not detect alsa
and falls back to arts ?
so if i make a /etc/libao.conf with
default_driver=alsa09
i got no error
i use libao 0.8.6 Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/904configure: error: No 16 bit type found on this platform!2010-01-29T10:32:12Zbobconfigure: error: No 16 bit type found on this platform!During configure --prefix=/opt
checking for short... no
checking size of short... 0
checking for int... no
checking size of int... 0
checking for long... no
checking size of long... 0
configure: error: No 16 bit type found on this platf...During configure --prefix=/opt
checking for short... no
checking size of short... 0
checking for int... no
checking size of int... 0
checking for long... no
checking size of long... 0
configure: error: No 16 bit type found on this platform!
An amazing problem. I have compiled tons of open source stuff on this system. This is the first time I have ever seen a configure failure like this. I'm completely stumped.
System and compiler info
SunOS arrow 5.8 Generic_117350-05 sun4u sparc SUNW,UltraSPARC-IIi-Engine
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../configure --prefix=/opt
Thread model: posix
gcc version 4.0.2
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/885ao Makefile does not honor "mandir"2017-03-30T06:28:45Zreedao Makefile does not honor "mandir"The ./configure allows using --mandir.
But it also overrides in Makefile.am using MANDIR (instead of @mandir@).
Please use @mandir@ instead. Please remove your MANDIR from configure
and Makefile.am. Just use the normal defaults.
The pr...The ./configure allows using --mandir.
But it also overrides in Makefile.am using MANDIR (instead of @mandir@).
Please use @mandir@ instead. Please remove your MANDIR from configure
and Makefile.am. Just use the normal defaults.
The problem is you use --mandir and then it does not work like
is expected.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/825Fix build under MacOSX and add buffer_time2006-02-01T10:07:45ZmikeFix build under MacOSX and add buffer_timeThis patch fixes two problems I found while trying out the library with OSX and adds one enhancement
Correctly link under darwin (taken from the fink port). This is the same problem as mentioned #727, I just put it here for completeness...This patch fixes two problems I found while trying out the library with OSX and adds one enhancement
Correctly link under darwin (taken from the fink port). This is the same problem as mentioned #727, I just put it here for completeness.
Fix a lockup if a program is calling ao_close() in an atexit. Coreaudio has its own atexit handler so the HAL has already been taken down by Coreaudio itself. I do not know if this is the best solution but it works.
Add a buffer_time property that allows to set the buffering in the driver. With this property an application can define the buffer_time it wants in ms.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/822Tick noise following a sound clip2010-01-28T11:55:48ZGitlab BotTick noise following a sound clipI'm using an SB Live! (emu10k1) sound card w/ the ALSA drivers that are built into 2.6 kernel. When using the Gaim application with the "Sound Method" set to "Automatic" and a sound is played from Gaim, there is a tick noise right befor...I'm using an SB Live! (emu10k1) sound card w/ the ALSA drivers that are built into 2.6 kernel. When using the Gaim application with the "Sound Method" set to "Automatic" and a sound is played from Gaim, there is a tick noise right before the sound finishes. When I have the "Sound Method" set to "Command " and I use "aplay %s", the sound is smooth and never ticks. I've seen this behaviour in every Gaim version I've tried, but the version I'm using right now is 1.5.0 using libao version 0.8.5.
I have already posted this bug on Gaim's bug tracker and I was referred here.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/814[PATCH] libao-0.8.6 alsa driver buffer_time option is broken2007-11-15T08:46:42Zheikki.orsila[PATCH] libao-0.8.6 alsa driver buffer_time option is brokenlibao-0.8.6 alsa driver has a bug in handling buffer_time option. The API is documented to accept buffer_time in milliseconds, but ALSA driver stores buffer_time internally in microseconds but fails to convert the user input. Also, the d...libao-0.8.6 alsa driver has a bug in handling buffer_time option. The API is documented to accept buffer_time in milliseconds, but ALSA driver stores buffer_time internally in microseconds but fails to convert the user input. Also, the driver code has an untrue comment about ALSA api (claims that alsa API is given the buffer time in milliseconds but it's really in microseconds).
I will attach the patch soon.
Regards, Heikki Orsila
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/795libao error in gaim-lib on FC42010-01-30T14:03:54ZGitlab Botlibao error in gaim-lib on FC4Gaim uses libao but crashes as soon a sound is displayed.
For details on this bug, see http://sourceforge.net/tracker/index.php?func=detail&aid=1385138&group_id=235&atid=100235
as it was first published within bugtracker of gaim project....Gaim uses libao but crashes as soon a sound is displayed.
For details on this bug, see http://sourceforge.net/tracker/index.php?func=detail&aid=1385138&group_id=235&atid=100235
as it was first published within bugtracker of gaim project.
important: happens on FC 4 since install of kernel 2.6.14-1.1653_FC4Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/727[PATCH] libao not linking right in MacOSX 10.42010-03-23T05:51:02Zs355248[PATCH] libao not linking right in MacOSX 10.4In MacOS 10.4 one will find problems about missing symbols namely:
dlsym_auto_underscore
This can be fixed by deleteing all of the statements in configure that say "-Ddlsym=dlsym_auto_underscore". This will break 10.2 and eariler. I ...In MacOS 10.4 one will find problems about missing symbols namely:
dlsym_auto_underscore
This can be fixed by deleteing all of the statements in configure that say "-Ddlsym=dlsym_auto_underscore". This will break 10.2 and eariler. I do not have 10.3 to test on. This can be done by running
sed 's/-Ddlsym=dlsym_auto_underscore//g' configure > configure.new && mv -f configure.new configure && chmod +x configure
After doing this there will still be missing symbols from the CoreAudio framework (something like AudioHardwareGetProperty usually). This is because the -framework CoreAudio has been left in the generated makefile in the src/plugins/macosx directory. I cannot narrow it down to fix it properely, but a hack is to cd to this directory, type 'make', then copy the last 'gcc' command (it ends in -lpthread for my machine), then type '-framework CoreAudio' at the end and rerun the command. Then type make install from the top directory and all should work.
The command should look like:
gcc -flat_namespace -undefined suppress -o .libs/libmacosx.so -bundle .libs/ao_macosx.o -lpthread -framework CoreAudio
This would have been picked up had the '-undefined suppress' option been left out.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/723glibc has memory problem, sends SIGABRT2019-07-01T08:51:48Zdan724glibc has memory problem, sends SIGABRT```
dan@localhost ~ $ gaim
*** glibc detected *** free(): invalid pointer: 0x083550e0 ***
Aborted
dan@localhost ~ $ gdb gaim
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Publi...```
dan@localhost ~ $ gaim
*** glibc detected *** free(): invalid pointer: 0x083550e0 ***
Aborted
dan@localhost ~ $ gdb gaim
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-pc-linux-gnu"...(no debugging
symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) handle SIGPIPE nostop
Signal Stop Print Pass to program Description
SIGPIPE No Yes Yes Broken pipe
(gdb) run
Starting program: /usr/bin/gaim
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 14913)]
*** glibc detected *** double free or corruption (out): 0x0835f230
***
Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 14913)]
0x405670c1 in kill () from /lib/libc.so.6
(gdb) bt
#0 0x405670c1 in kill () from /lib/libc.so.6
#1 0x40036def in pthread_kill () from /lib/libpthread.so.0
#2 0x400371c1 in raise () from /lib/libpthread.so.0
#3 0x40566e60 in raise () from /lib/libc.so.6
#4 0x405681f4 in abort () from /lib/libc.so.6
#5 0x40599c31 in __fsetlocking () from /lib/libc.so.6
#6 0x4059f395 in malloc_usable_size () from /lib/libc.so.6
#7 0x4059fe13 in free () from /lib/libc.so.6
#8 0x41c7142d in operator delete ()
from /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/libstdc++.so.6
#9 0x41b7d28c in Arts::readTypeSeq<Arts::InterfaceDef> ()
from /usr/kde/3.4/lib/libmcop.so.1
#10 0x0db1bf65 in ?? ()
(gdb) quit
The program is running. Exit anyway? (y or n) y
dan@localhost ~ $
```
All of these errors occur after gaim has run for a while. This is the 1.5.0 version of gaim compiled from source. The gaim developers claim the issue is with your sound libraries and disabling sound in gaim seems to make the problem go away... supporting this theory.
```
System info:
localhost dan # uname -a
Linux localhost 2.6.13-gentoo-r3 #1 SMP Tue Oct 18 00:53:09 Local
time zone must be set--see zic i686 Intel(R) Pentium(R) 4 CPU 3.
00GHz GenuineIntel GNU/Linux
localhost dan # gcc -v
Reading specs from /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/specs
Configured with: /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/
configure --prefix=/usr --bindir=/usr/i386-pc-linux-gnu/gcc-bin/3.4.4 --
includedir=/usr/lib/gcc/i386-pc-linux-gnu/3.4.4/include --datadir=/usr/
share/gcc-data/i386-pc-linux-gnu/3.4.4 --mandir=/usr/share/gcc-
data/i386-pc-linux-gnu/3.4.4/man --infodir=/usr/share/gcc-data/i386-
pc-linux-gnu/3.4.4/info --with-gxx-include-dir=/usr/lib/gcc/i386-pc-
linux-gnu/3.4.4/include/g++-v3 --host=i386-pc-linux-gnu --
build=i386-pc-linux-gnu --disable-altivec --enable-nls --without-
included-gettext --with-system-zlib --disable-checking --disable-
werror --disable-libunwind-exceptions --disable-multilib --disable-
libgcj --enable-languages=c,c++,f77 --enable-shared --enable-
threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)
localhost dan # ld -v
GNU ld version 2.15.92.0.2 20040927
glibc version:
glibc-2.3.5-r2
libao version:
libao-0.8.5
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/722libao.conf.5 still mentions alsa092005-10-18T07:35:55ZKyungjoon Leelibao.conf.5 still mentions alsa09libao.conf.5 in SVN needs to reflect the fact that alsa points
to alsa09 now.libao.conf.5 in SVN needs to reflect the fact that alsa points
to alsa09 now.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/718[PATCH] signal fix for libao oss driver2010-01-30T13:50:27Zheikki.orsila[PATCH] signal fix for libao oss driverLibao 0.8.6 (and the current svn version) has a bug in oss driver. It may skip some samples, meaning that it doesn't write them to the device, if a signal, such as SIGTSTP, happens at a bad time. write() returns an error on signal if no ...Libao 0.8.6 (and the current svn version) has a bug in oss driver. It may skip some samples, meaning that it doesn't write them to the device, if a signal, such as SIGTSTP, happens at a bad time. write() returns an error on signal if no bytes have yet been committed to the device. In that case errno is set to EINTR, and the write should be run again. The same goes for EAGAIN.
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/701[PATCH] Autodetection of esd can trash environment variables, leading to a cr...2010-01-31T10:44:49Zthekingant[PATCH] Autodetection of esd can trash environment variables, leading to a crash of the application using libaoThe *ao_plugin_text()* function in src/plugins/esd/ao_esd.c adds an environment variable using *putenv()*. The *putenv()* function uses the reference that is passed to it. This is fine, until *ao_shutdown()* is called and the ao esd pl...The *ao_plugin_text()* function in src/plugins/esd/ao_esd.c adds an environment variable using *putenv()*. The *putenv()* function uses the reference that is passed to it. This is fine, until *ao_shutdown()* is called and the ao esd plugin is unloaded, at which point the reference passed to *putenv()* becomes invalid and future calls to *getenv()* may cause a crash.
I'm experiencing this in Gaim CVS, where we've moved our call to *ao_shutdown()* to be earlier in our shutdown process, and we have calls to gettext afterwards which call *getenv()* which causes a crash.
The best solution for this is to call *unsetenv()* to unset the ESD_NO_SPAWN environment variable. I think you could also go back to using setenv, which looks like it makes a copy of the data passed to it (although it seems to be less portable). However, it's probably better to not set that environment variable in the parent's process.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/696Delay API for live devices2010-01-30T14:10:34ZNicolas GeorgeDelay API for live devicesWould you consider adding a function to get the delay between the sample currently being played and the sample that was last given to ao_play? Something like snd_pcm_delay or its equivalent for others devices.
Such a function would be v...Would you consider adding a function to get the delay between the sample currently being played and the sample that was last given to ao_play? Something like snd_pcm_delay or its equivalent for others devices.
Such a function would be very useful in cases where audio synchronization is essential, like video programs, or when trying to play the same sound on several computers. Obviously, its result would only make sense for live devices, but it could just return 0 for non-live devices.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/683Fixed a bug in libao 0.8.6 ALSA driver2005-07-12T19:57:02Zheikki.orsilaFixed a bug in libao 0.8.6 ALSA driverALSA driver in libao 0.8.6 is buggy. When catching a SIGINT (ctrl-c) during writei() the ALSA framework returns -EINTR. It causes libao to print "ALSA write error: Interrupted system call" and exit() with error. Unfortunately SIGINT is n...ALSA driver in libao 0.8.6 is buggy. When catching a SIGINT (ctrl-c) during writei() the ALSA framework returns -EINTR. It causes libao to print "ALSA write error: Interrupted system call" and exit() with error. Unfortunately SIGINT is not a terminal condition, and thus it (and other signals) should be handled properly.
Following patch fixes the problem (applies for 0.8.5 too):
http://shd.ton.tut.fi/patches/libao-0.8.6-alsa09-signal-fix.diff
Please apply the patch.
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/665[PATCH] segmentation fault in NAS plugin of libao caused by integer overflow2007-11-19T03:24:29ZGitlab Bot[PATCH] segmentation fault in NAS plugin of libao caused by integer overflowUsing (32 bit) int variables to store 32 bit unsigned integer values leads to integer overflows in the NAS plugin of libao. This bug is in versions 0.8.5 and 0.8.6 of libao (I didn't check older versions). The following patch fixes this ...Using (32 bit) int variables to store 32 bit unsigned integer values leads to integer overflows in the NAS plugin of libao. This bug is in versions 0.8.5 and 0.8.6 of libao (I didn't check older versions). The following patch fixes this problem:
```
diff -Naur libao-0.8.5/src/plugins/nas/ao_nas.c libao-0.8.5.new/src/plugins/nas/ao_nas.c
--- libao-0.8.5/src/plugins/nas/ao_nas.c 2003-07-14 04:59:10.000000000 +0200
+++ libao-0.8.5.new/src/plugins/nas/ao_nas.c 2005-05-18 09:48:45.843142463 +0200
@@ -61,8 +61,8 @@
AuFlowID flow;
AuDeviceID dev;
char *host;
- int buf_size;
- int buf_free;
+ int64_t buf_size;
+ int64_t buf_free;
} ao_nas_internal;
int ao_plugin_test()
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/664aclocal m4 file needs to be updated2006-06-12T10:28:44Zdenisaclocal m4 file needs to be updatedaclocal issues the following warning :
/usr/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
I t...aclocal issues the following warning :
/usr/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
I think your ao.m4 file needs to be updated. IIRC, these are minor (backward-compatible) syntactic changes.
Stan SeibertStan Seibert