Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-11-03T10:00:02Zhttps://gitlab.xiph.org/xiph/libao/-/issues/1776libao 1.1.0 skipping default alsa device2017-11-03T10:00:02Zledtilibao 1.1.0 skipping default alsa deviceMy distribution recently upgraded libao ^(1)^ from 1.0.0 to 1.1.0 and I have encountered a problem where libao is ignoring the default device set in my local .asoundrc file.
It is defaulting to hw:0,0 even though hw:1,0 is set as the de...My distribution recently upgraded libao ^(1)^ from 1.0.0 to 1.1.0 and I have encountered a problem where libao is ignoring the default device set in my local .asoundrc file.
It is defaulting to hw:0,0 even though hw:1,0 is set as the default output device. After blacklisting hw:0,0, I ran two separate applications that use libao. The console output is included as an attachment.
Forgive me if this is distribution related, but it seemed to me to be a upstream issue.
Downgrading to 1.0.0 or blacklisting the snd-hda-intel module fixes the issue for me, though the latter option results in the attached output.
,,1. [upgpkg: libao 1.1.0-1](http://projects.archlinux.org/svntogit/packages.git/commit/libao/trunk/PKGBUILD?id=8307fae21dbe306c94c93b79c8fce8ff66bf7c52),,
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1771libao pulse driver fault2011-02-22T15:56:25Zsimplelibao pulse driver faultHello. I have some problems with using pulse driver for libao.I launched "pacat --record | sox -t raw -r 44100 -s -b 16 -c 2 - -t ao pulse pitch -500" for processing audio input, but it faulted with "Assertion 'p' failed at pulse/simple...Hello. I have some problems with using pulse driver for libao.I launched "pacat --record | sox -t raw -r 44100 -s -b 16 -c 2 - -t ao pulse pitch -500" for processing audio input, but it faulted with "Assertion 'p' failed at pulse/simple.c:384, function pa_simple_drain(). Aborting". Using other drivers, such as alsa, works fine, but I need pulseaudio. So is it because of libao and how can I solve this problem?
Ubuntu 10.10, PulseAudio. libao 1.0.
Thanx.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1764[PATCH] Version symbols2011-02-22T16:28:53ZCristian Morales Vega[PATCH] Version symbolsThe attached patch adds symbol versioning. Doing this
- ao_read_config_files()
- ao_au
- ao_null
- ao_raw
- ao_wav
are not exported anymore. Looking at http://www.xiph.org/ao/doc/libao-api.html it seems this is OK, correct?
Notice...The attached patch adds symbol versioning. Doing this
- ao_read_config_files()
- ao_au
- ao_null
- ao_raw
- ao_wav
are not exported anymore. Looking at http://www.xiph.org/ao/doc/libao-api.html it seems this is OK, correct?
Notice that web page (and the ao.h file) talks about an ao_file_extension() function. But such a function doesn't exists at all!! It's not exported with this patch and wasn't exported before.
The patch is against the latest SVN version. I used only the LIBAO4_1.0.0 symbol (extra verbose, could be changed) since I don't know of any added functionality in any of the functions since the 1.0.0 version... is this OK?
The symbol versioning support detection from configure.ac is copied from libpng, so I expect it to work without problems in other systems. Still, I didn't test it.
Symbol versioning has multiple advantages:
- Avoids crashes in UNIX systems when two ABI incompatible versions of libao are loaded in the same process image (since symbol resolution is global)
- The RPM build process automatically adds dependencies based on symbol versions. So, if the library is versioned, a package that requires libao 1.0.1 will have such dependency in the RPM package. Otherwise any library with the same soname, even if too old, would be allowed.
- If you trust Drepper and want to do the extra work, you can avoid any future ABI breakage.
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1762[PATCH] libao ALSA driver could have a problem with some sound cards2010-12-17T11:32:27ZCristian Morales Vega[PATCH] libao ALSA driver could have a problem with some sound cardsFrom Takashi Iwai, from ALSA fame:
"There are devices that have only a small number of periods (aka
fragments) for a buffer, typically just two periods. So, if you set
the buffer size first, you limit the minimum period size to the half...From Takashi Iwai, from ALSA fame:
"There are devices that have only a small number of periods (aka
fragments) for a buffer, typically just two periods. So, if you set
the buffer size first, you limit the minimum period size to the half
of the given buffer size. This would result in a large latency.
OTOH, if you first set the period size, it limits the max buffer
size. So, the latency is assured.
Thus, it's a question whether you want a smaller latency or a better
stability. In the case of libao, the latency is more important."
This patch (or an equivalent, the source has change over years) has been in openSUSE since 2005 (yeah, sorry) without any complains, so it should be well tested.
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1760[PATCH] libao misses header to use isspace()2010-12-17T11:28:52ZCristian Morales Vega[PATCH] libao misses header to use isspace()config.c uses isspace() without an "#include <ctype.h>"
config.c uses isspace() without an "#include <ctype.h>"
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1735add libffado support2011-02-22T16:30:00ZGitlab Botadd libffado supportin order to play on firewire audio devices on linux, one has to use ffado ( http://www.ffado.org/ )
It would be nice if libao supported that. in order to play on firewire audio devices on linux, one has to use ffado ( http://www.ffado.org/ )
It would be nice if libao supported that. Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1734[PATCH] Make libao compile with VC 10.2016-08-29T19:36:21ZBoris DuĊĦek[PATCH] Make libao compile with VC 10.Changes:
* export API symbols from the DLL
* use C99's variadic macros for logging instead of a similar gcc extension
* include ks.h instead of ksmedia.h
* use ANSI versions of functions explicitely (do not use Unicode versions)
* i...Changes:
* export API symbols from the DLL
* use C99's variadic macros for logging instead of a similar gcc extension
* include ks.h instead of ksmedia.h
* use ANSI versions of functions explicitely (do not use Unicode versions)
* isspace requires ctype.h
* remove unused dirent.h
* use size_t as return value of strlen
With these changes, code compiles with no errors and warnings (level 3)
with VC 10 compiler and WinSDK v7.1, in Debug and Release modes, for
Win32, x64 and Itanium platforms. It also compiles and links without a
warning on Mac OS X with the 10.6 SDK and gcc 4.2 compiler (using
./configure ; make).
Used preprocessor definitions:
HAVE_WMM;_CRT_SECURE_NO_WARNINGS;_CRT_NONSTDC_NO_WARNINGS;AO_BUILDING_LIBAO
This does not deal with dl(open|sym|close) APIs, so plugins do not work
currently.
Also this only means clean compilation/linking. Correct working of the
library has not been tested (because I do not know how to test it).
Testing that the logging format is correct would be appreciated (rework
of logging was the biggest change).
I would also like to submit the VC 2010 solution and project file for inclusion
into libao (perhaps as a second revision of this patch). Is it possible? If
yes, is there a good place to put it into (like contrib/vc10)? Need to know to
make correct relative paths from the project file to the source files.
P.S.: could not find libao's SCM (Git, SVN) - is there one?Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1731Mac OS X 10.6.4 Build 10F569 - Loss of audio when inserting or removing devic...2010-12-03T22:44:57ZJasonMac OS X 10.6.4 Build 10F569 - Loss of audio when inserting or removing device from audio jackInitiating pianobar while using the macbook's built in speakers, then plugging headphones into or unplugging from the headphone jack results in complete loss of sound from pianobar. The app needs to be restarted to restore sound.
I'm mo...Initiating pianobar while using the macbook's built in speakers, then plugging headphones into or unplugging from the headphone jack results in complete loss of sound from pianobar. The app needs to be restarted to restore sound.
I'm more than willing to provide more info, but I'm not sure what info would be needed to diagnose this. This is a consistent issue and can be replicated on my system 100% of the time.
Related:
http://github.com/PromyLOPh/pianobar/issues/closed#issue/36
http://github.com/PromyLOPh/pianobar/issues/#issue/35Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1728High-level noise and sound deformation with libao4 on debian-ppc2024-02-02T12:03:49ZGitlab BotHigh-level noise and sound deformation with libao4 on debian-ppcFirst filed at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588901
Hello,
After upgrading mpg321 from version 0.2.10.6 which uses libao2 to version 0.2.12-1 which uses libao4, I started having the following problems when playing a...First filed at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588901
Hello,
After upgrading mpg321 from version 0.2.10.6 which uses libao2 to version 0.2.12-1 which uses libao4, I started having the following problems when playing a mp3 file:
- high-level noise in the background
- sound deformation especially on voices.
I first filled a bug report for mpg321 (bug number 588531) where I have attached a mp3 file which corresponds to the output sound of my system (having mpg321 write a wav file then I converted it to mp3)
(http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=Sample_output_mpg321.mp3;att=1;bug=588531)
If you listen to the mp3 file, you will be able to hear the problems.
However, after a discussion with the mpg321 maintainer and a few tests (he sent me a short code using libao to play a wav file), we identified that the problem came from libao4.
Wav files play just fine when the code is compiled against libao2 but the problems I have described appear when it is compiled against libao4.
This problem only occurs on the debian-ppc version (it works fine on my amd64 debian desktop).
If that seems relevant, could you merge the previously filled bug report for mpg321 (588531) with this new one?
Please tell me if you would need more information.
Best regards.
Jad
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1727device->internal no longer available2012-02-15T13:52:36ZRichard Kettlewelldevice->internal no longer availableForwarded from debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577400
Package: libao-dev
Version: 1.0.0-3
In earlier versions of libao it was possible to write new plugins for
it, using the interface described at doc/plugin-ov...Forwarded from debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577400
Package: libao-dev
Version: 1.0.0-3
In earlier versions of libao it was possible to write new plugins for
it, using the interface described at doc/plugin-overview.html and
doc/plugin-api.html.
However, the contents of the ao_device structure is no longer visible,
so plugins that store their private data via device->internal can no
longer be built. That would be fine if there was an alternative way to
associated private data with an ao_device, but there isn't.
plugin-overview.html mentions a number of other fields of ao_device
which plugins are expected to be able to access, e.g.
driver_byte_format, but they are also invisible.
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1725libao mac os 10.6.4 audiojack problem2010-12-03T22:44:37ZGitlab Botlibao mac os 10.6.4 audiojack problemUsing Pianobar (http://github.com/PromyLOPh/pianobar, which utilizes libao) on a macbook pro 2010 13', while playing a song with headphones on, once the headphones are removed, there is no sound for the currently playing song from the ma...Using Pianobar (http://github.com/PromyLOPh/pianobar, which utilizes libao) on a macbook pro 2010 13', while playing a song with headphones on, once the headphones are removed, there is no sound for the currently playing song from the macbook speakers. Plugging the headphones back in does nothing. Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1724libao waking from sleep problem in Mac OSX2010-12-03T22:44:15ZGitlab Botlibao waking from sleep problem in Mac OSXI have noticed that while using the Pianobar application (http://github.com/PromyLOPh/pianobar, which utilizes libao) in Snow Leopard 10.6.4, and the macbook goes to sleep, when the macbook wakes up, the current playing song has no audio. I have noticed that while using the Pianobar application (http://github.com/PromyLOPh/pianobar, which utilizes libao) in Snow Leopard 10.6.4, and the macbook goes to sleep, when the macbook wakes up, the current playing song has no audio. Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1719SEGV after changes libao2010-12-02T22:07:50ZGitlab BotSEGV after changes libaoHi
I use libao in my application.
After last update from 0.8.6 to 1.0.0 I've reported failure. Everything was compiled correctly, but I get SEGV.
It was affected because it's been added a field char *matrix in structure ao_sample_forma...Hi
I use libao in my application.
After last update from 0.8.6 to 1.0.0 I've reported failure. Everything was compiled correctly, but I get SEGV.
It was affected because it's been added a field char *matrix in structure ao_sample_format. After set it on null, application run ok.
I compiled your ao_example.c and it's not setting it - it printed error "Unrecognized channel name" with random string or crashes.
My propose is use memset to clear structure before set or use assign format.matrix = NULL;
Secondly, I suggest add a version define in library header. Now I recognize change of structure in my application by finding new define of AO_EBADFORMAT in ao.h file.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1715ao_sndio.c:103: error: `hdl' undeclared2010-08-04T01:24:40ZGitlab Botao_sndio.c:103: error: `hdl' undeclaredSorry; I don't have the time to fix this.
Might be a trivial fix... don't know.
On the download page there did not appear to be a list of required packages; If 'hdl' is due to a missing package dependency then please list it on the down...Sorry; I don't have the time to fix this.
Might be a trivial fix... don't know.
On the download page there did not appear to be a list of required packages; If 'hdl' is due to a missing package dependency then please list it on the download page.
$ make
[...]
ao_sndio.c: In function `ao_plugin_open':
ao_sndio.c:103: error: `hdl' undeclared (first use in this function)
$ uname -srvm
OpenBSD 4.5 GENERIC#1749 i386
$ find /usr/include -exec grep -q -e hdl \;-print -exec grep -n -e hdl \;
/usr/include/dev/audio_if.h
136: void *hdl;
[... not relevant ...]
nothing in /usr/local/include
and /include is non-existant
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1694Segfaults of mpg321 if build with libao 1.0.02010-12-02T22:01:41ZfundawangSegfaults of mpg321 if build with libao 1.0.0See:
https://qa.mandriva.com/show_bug.cgi?id=59019
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580062See:
https://qa.mandriva.com/show_bug.cgi?id=59019
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580062Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1689libao not working correctly with pulse audio2010-12-02T21:59:56ZGitlab Botlibao not working correctly with pulse audioI'm using an app called "PianoBar". It's a a cli based Pandora client that uses libao for playback. When trying to play it returns the error:
Assertion 'p' failed at pulse/simple.c:384, function a_simple_drain(). Aborting.
Aborted
Play...I'm using an app called "PianoBar". It's a a cli based Pandora client that uses libao for playback. When trying to play it returns the error:
Assertion 'p' failed at pulse/simple.c:384, function a_simple_drain(). Aborting.
Aborted
Plays back fine using the Alsa backend.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1667libao 1.0.0 does not compile on Mac OS X 10.52010-04-06T17:25:44ZMax Hornlibao 1.0.0 does not compile on Mac OS X 10.5As the title says, libao 1.0.0 does not compile on Mac OS X 10.5. This is the error:
/bin/sh ../../../libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"libao\" -DPACKAGE_TARNAME=\"libao\" -DPACKAGE_VERSION=\"1.0.0\" -DPACKAGE_STRING...As the title says, libao 1.0.0 does not compile on Mac OS X 10.5. This is the error:
/bin/sh ../../../libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"libao\" -DPACKAGE_TARNAME=\"libao\" -DPACKAGE_VERSION=\"1.0.0\" -DPACKAGE_STRING=\"libao\ 1.0.0\" -DPACKAGE_BUGREPORT=\"monty@xiph.org\" -DPACKAGE=\"libao\" -DVERSION=\"1.0.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_DLFCN_H=1 -DHAVE_DLOPEN=1 -DHAVE_LIBPTHREAD=1 -DDLOPEN_FLAG=\(RTLD_LAZY\) -DSHARED_LIB_EXT=\".so\" -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -I. -I. -I../../../include/ao -I../../../include -DAO_SYSTEM_CONFIG='"/sw/etc/libao.conf"' -I/sw/include -D__NO_MATH_INLINES -fsigned-char -g -O2 -DAO_BUILDING_LIBAO -c -o ao_macosx.lo ao_macosx.c
libtool: compile: gcc -DPACKAGE_NAME=\"libao\" -DPACKAGE_TARNAME=\"libao\" -DPACKAGE_VERSION=\"1.0.0\" "-DPACKAGE_STRING=\"libao 1.0.0\"" -DPACKAGE_BUGREPORT=\"monty@xiph.org\" -DPACKAGE=\"libao\" -DVERSION=\"1.0.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_DLFCN_H=1 -DHAVE_DLOPEN=1 -DHAVE_LIBPTHREAD=1 "-DDLOPEN_FLAG=(RTLD_LAZY)" -DSHARED_LIB_EXT=\".so\" -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -I. -I. -I../../../include/ao -I../../../include -DAO_SYSTEM_CONFIG=\"/sw/etc/libao.conf\" -I/sw/include -D__NO_MATH_INLINES -fsigned-char -g -O2 -DAO_BUILDING_LIBAO -c ao_macosx.c -fno-common -DPIC -o .libs/ao_macosx.o
ao_macosx.c:74: error: syntax error before 'AudioComponentInstance'
The attached patch fixes this issue. It might even restore compatibility with 10.4, but I cannot test that right now (but will try to find out).
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1642Pulse ALSA emulation refusing hw_param settings2010-02-05T23:15:30ZMonty MontgomeryPulse ALSA emulation refusing hw_param settingsPulse's alsa interception is refusing some hw_param settings that normal ALSA is not. Track this behavior down on an F11/12/13 box.Pulse's alsa interception is refusing some hw_param settings that normal ALSA is not. Track this behavior down on an F11/12/13 box.Monty MontgomeryMonty Montgomeryhttps://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 Seibert