Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2010-03-23T09:16:46Zhttps://gitlab.xiph.org/xiph/libao/-/issues/1641need better configuration output wrt to which backends built2010-03-23T09:16:46ZMonty Montgomeryneed better configuration output wrt to which backends builtA reminder to me:
the configure script right now does not make it clear which backend support is being built and which is not. This must be made more explicit for the 1.0.9 release.A reminder to me:
the configure script right now does not make it clear which backend support is being built and which is not. This must be made more explicit for the 1.0.9 release.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1629PATCH: Add support for newer automake versions to libao's autogen.sh2010-01-11T20:39:13ZMax HornPATCH: Add support for newer automake versions to libao's autogen.shThe attached patch enables libao's trunk version to be used with automake 1.10 and newer, by fixing its autogen.sh in a fashion similar to what vorbis & ogg do.
The attached patch enables libao's trunk version to be used with automake 1.10 and newer, by fixing its autogen.sh in a fashion similar to what vorbis & ogg do.
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1582Libao, too many arguments to function ao_play()2010-01-11T20:49:02ZExiquioLibao, too many arguments to function ao_play()I am working on wrapping libao in Ruby and I ran into an issue that probably is a big in my code (I am not a good C programmer). I get the following make error message referring to the method that wraps a call to ao_play():
gcc -I. -I. ...I am working on wrapping libao in Ruby and I ran into an issue that probably is a big in my code (I am not a good C programmer). I get the following make error message referring to the method that wraps a call to ao_play():
gcc -I. -I. -I/usr/lib/ruby/1.8/i686-linux -I. -D_FILE_OFFSET_BITS=64 -fPIC -march=i686 -mtune=generic -O2 -pipe -fPIC -c audiolibs.c
audiolibs.c: In function ‘play_ao’:
audiolibs.c:56: error: expected expression before ‘ao_device’
audiolibs.c:56: error: too few arguments to function ‘ao_play’
make: *** [audiolibs.o] Error 1
I am running Arch Linux (Linux ghostintheshell 2.6.30-ARCH #1 SMP PREEMPT Fri Jul 31 18:10:38 UTC 2009 i686 Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz GenuineIntel GNU/Linux) with extra/libao 0.8.8-2, core/make 3.81-4, and core/gcc 4.4.1-1 installed.
I have attached a few relevant files. Maybe you have an idea of what is going on. Any help that you provide will be much appreciated. Thanks for you time.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1580Compile libao by Visual Studio?2010-01-11T20:51:01ZJIA PeiCompile libao by Visual Studio?To whom it may concern:
Is there any plan for Visual Studio compilation of libao?
Best Regards
JIA Pei
To whom it may concern:
Is there any plan for Visual Studio compilation of libao?
Best Regards
JIA Pei
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1397libao pulseaudio support does not work on bigendian machines2010-03-23T06:28:10Zj.w.r.degoedelibao pulseaudio support does not work on bigendian machinesHi,
I'm the Fedora package maintainer of libao, today I received this bugreport:
https://bugzilla.redhat.com/show_bug.cgi?id=454165
I don't have the necessary hardware to reproduce this, but I know the reporter well and I trust him. He...Hi,
I'm the Fedora package maintainer of libao, today I received this bugreport:
https://bugzilla.redhat.com/show_bug.cgi?id=454165
I don't have the necessary hardware to reproduce this, but I know the reporter well and I trust him. He has written a (simple) patch for this which I'll attach.
Regards,
Hans
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1279[PATCH] ao_wmm,c; nBlockAlign incorrect for non multiple of 8 bit samples2010-01-13T21:14:39ZGitlab Bot[PATCH] ao_wmm,c; nBlockAlign incorrect for non multiple of 8 bit samplesao_wmm,c; nBlockAlign incorrect for non multiple of 8 bit samples
should be:
wavefmt.nBlockAlign = ((wavefmt.wBitsPerSample+7)>>3)*wavefmt.nChannels;ao_wmm,c; nBlockAlign incorrect for non multiple of 8 bit samples
should be:
wavefmt.nBlockAlign = ((wavefmt.wBitsPerSample+7)>>3)*wavefmt.nChannels;Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1278[PATCH] ao_wmm.c has debug output enabled by default2010-01-13T21:56:55ZGitlab Bot[PATCH] ao_wmm.c has debug output enabled by defaultao_wmm.c has debug output enabled by default
static int debug_flag = 1;
4 suggestions:
1. Have it off by default
2. Have it settable from the command line
#ifndef AO_WMM_DEBUG
#define AO_WMM_DEBUG 0
#endif
static int debug_flat = AO_WMM...ao_wmm.c has debug output enabled by default
static int debug_flag = 1;
4 suggestions:
1. Have it off by default
2. Have it settable from the command line
#ifndef AO_WMM_DEBUG
#define AO_WMM_DEBUG 0
#endif
static int debug_flat = AO_WMM_DEBUG;
3. Add it to the configure
if test "x$has_wmm" = "xyes" && test "x$enable_wmm_debug"; then
CFLAGS="$CFLAGS -DAO_WMM_DEBUGS=1"
fi
(also add comment)
4. Add it as an option to ao_wmm_option
static char * ao_wmm_options[] = {"debug, "dev", "id");
and ao_wmm_set_option
if(!strcmp("debug")) {
if(!strcmp("yes")) {
debug_flag = 1;
res = 1;
}
else if(!strcmp("no")) {
debug_flag = 0;
res = 1;
}
else {
res = 0;
}
goto finish;
}
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1267[patch] alsa plugin should check rate2010-01-13T22:02:45ZGitlab Bot[patch] alsa plugin should check rateIt is a mandatory to check the actual
rate after calling snd_pcm_hw_params_set_rate_near().
Otherwise it may be an arbitrary value.
I have the sound card that (or its driver)
only supports 48KHz. When libao is trying
to set, say, 22050, ...It is a mandatory to check the actual
rate after calling snd_pcm_hw_params_set_rate_near().
Otherwise it may be an arbitrary value.
I have the sound card that (or its driver)
only supports 48KHz. When libao is trying
to set, say, 22050, the rate will still be
48K, so the playback will be of the wrong
speed.
The attached patch fixes the problem.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1257libao wav driver saves strange noise instead of sound which is played by wmm ...2010-01-13T22:06:33Zfuxxlibao wav driver saves strange noise instead of sound which is played by wmm pluginI modified slightly sample which is shipped with library and added ability to save wav files. But to my surprise saved files aren't useable at all. I attaching source code and sample file produced by it.I modified slightly sample which is shipped with library and added ability to save wav files. But to my surprise saved files aren't useable at all. I attaching source code and sample file produced by it.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1140unhelpful underrun messages on stderr (stdout?)2010-01-28T11:53:45ZGitlab Botunhelpful underrun messages on stderr (stdout?)When using a program which links in libao, messages like these are common:
`ALSA: underrun, at leaast 0ms`
The problems with these messages are:
1. The program creating the message is not identified
2. The library creating the mes...When using a program which links in libao, messages like these are common:
`ALSA: underrun, at leaast 0ms`
The problems with these messages are:
1. The program creating the message is not identified
2. The library creating the message is not identified
3. The library is creating these messages without the linking program's permission
4. The program may have a graphical interface, or a network interface, and thus standard out/error are the wrong place for informational messages.
5. This occurs during normal operation, when there is no error
* The system may not even have sound output enabled, making this extra-useless.
6. Can you get a negative time underrun?
#### Suggestions
Small improvement::
Clearly label this message as coming from libao, so that it can be identified.
Nicer improvement::
Label this message as coming form libao, but also identify the process generating the message. The program name would be nice, but just the PID would be a start.
Best improvement::
Unless this library is built or initialized in a special debug manner, do not print these messages at all, anywhere. They typically appear on terminals in active use by other programs, and even appear when the programmer of a tool has provided a -q for quiet mode and has carefully avoided sending any output to standard output or error, only to have her or his goals broken by libao, perhaps multiple libraries away.
Optionally, if you think sending them somewhere by default is really important, please provide some way users of programs (not developers against the library!) can specify where these messages are sent. EG. export LIBAO_WARNINGS_LOGFILE=/dev/null
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1139Make libao.conf less useless: make it possible to prepend switches to ao_open...2010-01-31T11:55:07ZGitlab BotMake libao.conf less useless: make it possible to prepend switches to ao_open_live()I'm too busy to rewrite my entire story. Your Trac ate my description because it contained a link. Thanks and good day, sir!
```
--- src/ao_private.h Fri Aug 29 20:18:32 2003
+++ src/ao_private.h Sat Mar 3 17:14:59 2007
@@ -61,6 +61,7 ...I'm too busy to rewrite my entire story. Your Trac ate my description because it contained a link. Thanks and good day, sir!
```
--- src/ao_private.h Fri Aug 29 20:18:32 2003
+++ src/ao_private.h Sat Mar 3 17:14:59 2007
@@ -61,6 +61,7 @@
typedef struct ao_config {
char *default_driver;
+ ao_option *prepended;
} ao_config;
/* --- Functions --- */
--- src/audio_out.c Tue Mar 9 16:35:41 2004
+++ src/audio_out.c Sat Mar 3 17:23:18 2007
@@ -80,7 +80,8 @@
static driver_list *driver_head = NULL;
static ao_config config = {
- NULL /* default_driver */
+ NULL /* default_driver */,
+ NULL /* prepended options */
};
static ao_info **info_table = NULL;
@@ -446,6 +447,7 @@
static ao_device* _open_device(int driver_id, ao_sample_format *format,
ao_option *options, FILE *file)
{
+ ao_option *prepended = config.prepended;
ao_functions *funcs;
driver_list *driver;
ao_device *device;
@@ -486,6 +488,12 @@
return NULL; /* Couldn't init internal memory */
}
+ /* Default options */
+ while (prepended != NULL) {
+ /* Ignore errors */
+ funcs->set_option(device, prepended->key, prepended->value);
+ prepended = prepended->next;
+ }
/* Load options */
while (options != NULL) {
if (!funcs->set_option(device, options->key, options->value)) {
--- src/config.c Thu Aug 7 17:44:36 2003
+++ src/config.c Sat Mar 3 17:17:28 2007
@@ -23,6 +23,7 @@
*
*/
+#include "ao/ao.h"
#include "ao_private.h"
#include <stdio.h>
#include <stdlib.h>
@@ -52,7 +53,8 @@
int read_config_file(ao_config *config, const char *config_file)
{
FILE *fp;
- char line[LINE_LEN];
+ ao_option *aopt;
+ char line[LINE_LEN], *split;
int end;
@@ -60,15 +62,32 @@
return 0; /* Can't open file */
while (fgets(line, LINE_LEN, fp)) {
- /* All options are key=value */
+ /* Remove trailing newline */
+ end = strlen(line);
+ if (line[end-1] == '\n')
+ line[end-1] = '\0';
if (strncmp(line, "default_driver=", 15) == 0) {
+ /* Store default driver for efficiency */
free(config->default_driver);
- end = strlen(line);
- if (line[end-1] == '\n')
- line[end-1] = 0; /* Remove trailing newline */
-
config->default_driver = strdup(line+15);
+ } else {
+ /* All options are key=value */
+ split = strchr(line, '=');
+ if (split == NULL || split[1] == '\0')
+ continue;
+
+ /* Add new option to the list */
+ aopt = malloc(sizeof(ao_option));
+ if (aopt == NULL)
+ continue;
+ aopt->next = config->prepended;
+ config->prepended = aopt;
+
+ /* Split line in two and copy key/value */
+ *split = '\0';
+ aopt->key = strdup(line);
+ aopt->value = strdup(split + 1);
}
}
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1124data loss with esd over network2010-01-28T18:53:49Zschizodata loss with esd over networkCopied from Debian bug#267073:
It fixes some issues when using ESOUND over non-UNIX sockets like TCP.
In the esd driver write() needs to be called in a loop to make sure that
the complete sample data is written to the server.
Thanks,
...Copied from Debian bug#267073:
It fixes some issues when using ESOUND over non-UNIX sockets like TCP.
In the esd driver write() needs to be called in a loop to make sure that
the complete sample data is written to the server.
Thanks,
LennartStan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1103unnamespaced global symbols in libao2010-01-30T14:31:15ZGitlab Botunnamespaced global symbols in libaojorton@jolt:~$ rpm -qf /usr/lib/libao.so.2
libao-0.8.6-3.i386
jorton@jolt:~$ nm -D /usr/lib/libao.so.2
...
41068d30 T read_config_file
41068e70 T read_config_files
buys you these collisions with other FC6 libraries:
Clashes for /usr/li...jorton@jolt:~$ rpm -qf /usr/lib/libao.so.2
libao-0.8.6-3.i386
jorton@jolt:~$ nm -D /usr/lib/libao.so.2
...
41068d30 T read_config_file
41068e70 T read_config_files
buys you these collisions with other FC6 libraries:
Clashes for /usr/lib/libao.so.2.1.3:
with /usr/lib/libsnmp.so.10.0.1 => read_config_files
with /usr/lib/libnetsnmp.so.10.0.1 => read_config_files
I fixed it by adding "-export-symbols-regex '^ao_.*'" to LDFLAGS in src/Makefile.{in,am}.Monty MontgomeryMonty Montgomeryhttps://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 Seibert