libao issueshttps://gitlab.xiph.org/xiph/libao/-/issues2010-01-30T13:45:54Zhttps://gitlab.xiph.org/xiph/libao/-/issues/647all *.dsw and *.dsp files need win32 line endings (cr+lf)2010-01-30T13:45:54ZGitlab Botall *.dsw and *.dsp files need win32 line endings (cr+lf)microsoft visual studio requires all *.dsw and *.dsp to have win32 line endings,
otherwise you even attempt to compile libao on win32
Also, the sourcecode tarball doesn't even include the win32 directory
microsoft visual studio requires all *.dsw and *.dsp to have win32 line endings,
otherwise you even attempt to compile libao on win32
Also, the sourcecode tarball doesn't even include the win32 directory
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/644libao crashes with arts2010-01-30T13:39:47ZGitlab Botlibao crashes with artsI maintain gaim for gentoo linux. I see one bug every other week about crashes when sending/receiving IMs. Gaim devs have confirmed this to be crashing when gaim attempts to play notification sounds through libao, which crashes when tr...I maintain gaim for gentoo linux. I see one bug every other week about crashes when sending/receiving IMs. Gaim devs have confirmed this to be crashing when gaim attempts to play notification sounds through libao, which crashes when trying to use arts.
The latest bug report I have is here: http://bugs.gentoo.org/show_bug.cgi?id=87348
Gaim devs said they just close their bugs from other distros so I don't have much other evidence to show you. I'm sure one of them may comment here now that we've found your tracker.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/611[PATCH] Current ao_sun.c does not support network environments2010-01-29T11:13:12Zosmail[PATCH] Current ao_sun.c does not support network environmentsSun has established environment variables to be used in determining the appropriate audio device. These environment variables were not being checked by src/plugins/sun/ao_sun.c, which simply hardcoded /dev/audio as the device.
I'm atta...Sun has established environment variables to be used in determining the appropriate audio device. These environment variables were not being checked by src/plugins/sun/ao_sun.c, which simply hardcoded /dev/audio as the device.
I'm attaching a context diff (as soon as I figure out how, or I'll mail it on request if I can't) which changes ao_sun.c so that it checks the environment. This updated ao_sun.c will:
1) use the UTAUDIODEV environment variable (used by the SunRay thin client), if set
2) try to use the AUDIODEV environment variable, if set
3) fall back to the hard-coded /dev/audio device if neither of the above two environment variables are set.
Also, I'm compiling libao-0.8.6, which isn't in the version list.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/490libao2: libao driver fails to start on ppc2010-01-29T10:59:49Zccheneylibao2: libao driver fails to start on ppc```
Package: libao2
Version: 0.8.4-1
Severity: grave
Tags: sid
Justification: renders package unusable
Latest version of libao2 on ppc makes it impossible to use any player
based on it (like mpg321 or ogg123) because it always gi...```
Package: libao2
Version: 0.8.4-1
Severity: grave
Tags: sid
Justification: renders package unusable
Latest version of libao2 on ppc makes it impossible to use any player
based on it (like mpg321 or ogg123) because it always gives the error
message :
Can't find a suitable libao driver. (Is device in use?)
Downgrading to 0.8.3-1 fixes the problem. I couldn't rebuild 0.8.4-1
because it has a build dependency on libartsc0-dev which is unavailable.
-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux motoko 2.4.23-pre5-ben0 #1 mer oct 15 21:42:53 CEST 2003 ppc
Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro
Versions of packages libao2 depends on:
ii libc6 2.3.2-8 GNU C Library: Shared libraries
an
-- no debconf information
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/604not playing anything in musicpd2010-01-29T10:58:32Zmtenot playing anything in musicpdI've installed musicpd on freebsd 5.3 and libao came with it. But whenever i tried to play a file with musicpd i got an error "libao - OSS cannot get buffer size for device" in /var/log/mpd.error.
I'm using OSS from 4front-tech.com and ...I've installed musicpd on freebsd 5.3 and libao came with it. But whenever i tried to play a file with musicpd i got an error "libao - OSS cannot get buffer size for device" in /var/log/mpd.error.
I'm using OSS from 4front-tech.com and i have two sound cards (1 is integrated on nforce2 mobo and the other is terratec ewx24/96) and I've experienced the same problem on both. If you need more info please let me know.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/437libao: WAV device doesn't print error when device is full2010-01-29T10:33:20Zccheneylibao: WAV device doesn't print error when device is full```
This is copied from Debian BTS bug #130816:
I used ogg123 to convert an OGG file to a WAV. However, my hard drive
was full. ogg123 didn't tell me this, but happily continued just as
if everything was working fine. In the end,...```
This is copied from Debian BTS bug #130816:
I used ogg123 to convert an OGG file to a WAV. However, my hard drive
was full. ogg123 didn't tell me this, but happily continued just as
if everything was working fine. In the end, I winded up with an empty
file. It would be nice if a "No space left on device" error would be
printed.
1097:tbm@fisch: ..iseducation_of_lauryn_hill] ogg123 -d wav -f ~/audio-test-2/
lh-005.wav 005-doo_wop_\(that_thing\).ogg
Device: WAV file output
Author: Aaron Holtzman <aholtzma@ess.engr.uvic.ca>
Comments: Sends output to a .wav file
Playing: 005-doo_wop_(that_thing).ogg
Title: Doo Wop (That Thing)
Artist: Lauryn Hill
Album: The Miseducation Of Lauryn Hill
Track number: 5
Done.
1098:tbm@fisch: ..iseducation_of_lauryn_hill] ls -l ~/audio-test-2/lh-005.wav
-rw-r--r-- 1 tbm tbm 0 Jan 25 20:23 /home/tbm/
audio-test-2/lh-005.wav
1099:tbm@fisch: ..iseducation_of_lauryn_hill] df ~/audio-test-2
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda7 1912360 1815216 0 100% /home
```Monty MontgomeryMonty Montgomeryhttps://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/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/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/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/648[PATCH] audio_out.c(243) : error C2065: 'PATH_MAX' : undeclared identifier2010-01-28T11:51:48ZGitlab Bot[PATCH] audio_out.c(243) : error C2065: 'PATH_MAX' : undeclared identifierC:\libao-0.8.6\src\audio_out.c(243) : error C2065: 'PATH_MAX' : undeclared identifier
C:\libao-0.8.6\src\audio_out.c(243) : error C2057: expected constant expression
C:\libao-0.8.6\src\audio_out.c(243) : error C2466: cannot allocate an a...C:\libao-0.8.6\src\audio_out.c(243) : error C2065: 'PATH_MAX' : undeclared identifier
C:\libao-0.8.6\src\audio_out.c(243) : error C2057: expected constant expression
C:\libao-0.8.6\src\audio_out.c(243) : error C2466: cannot allocate an array of constant size 0
C:\libao-0.8.6\src\audio_out.c(243) : error C2133: 'fullpath' : unknown size
config.c
With MSVS6, LIMITS.H only defines PATH_MAX if _POSIX_ is defined,
but libao-0.8.6\win32\include\dirent.h doesn't like _POSIX_,
so to fix this modify audio_out.c and change
#include <limits.h>
to
#define _POSIX_
#include <limits.h>
#undef _POSIX_
that's how I get it compiled 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/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/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/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/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/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/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/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/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 Seibert