libao issueshttps://gitlab.xiph.org/xiph/libao/-/issues2017-11-03T10:00:02Zhttps://gitlab.xiph.org/xiph/libao/-/issues/1822libao.conf.5 man page is out-of-date2017-11-03T10:00:02ZVincent Lefèvrelibao.conf.5 man page is out-of-dateThe libao.conf.5 man page is out-of-date. Documentation on http://xiph.org/ao/doc/config.html is more recent.The libao.conf.5 man page is out-of-date. Documentation on http://xiph.org/ao/doc/config.html is more recent.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1815ALSA driver always uses native byte order2011-06-25T11:44:20ZMaarten ter HuurneALSA driver always uses native byte orderIn ao_alsa.c, the alsa_get_sample_bitformat() function will return constants like SND_PCM_FORMAT_S16, which specify the native byte order for ALSA. However, in ao_plugin_open() there is a comment "alsa's endinness will be the same as the...In ao_alsa.c, the alsa_get_sample_bitformat() function will return constants like SND_PCM_FORMAT_S16, which specify the native byte order for ALSA. However, in ao_plugin_open() there is a comment "alsa's endinness will be the same as the application's" and there the device byte order is made equal to the client byte order.
One possible solution would be to make alsa_get_sample_bitformat() respect its "bigendian" argument and return SND_PCM_FORMAT_S16_LE or SND_PCM_FORMAT_S16_BE depending on that. This would yield the best performance if the hardware can support both byte orders. I don't know whether libalsa will convert the byte order or return an error if the byte order requested is not available though.
Another possible solution would be to set the device byte order to the native byte order. This might lead to unnecessary byte swapping, but it is a two-line fix (line 528 and 530).
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1809libao: add version info to ao/ao.h2012-05-15T14:15:25ZNicklibao: add version info to ao/ao.hAs new features are added to libao, version information in the ao.h header would be helpful so code that uses libao can detect the version and use the new features.
For example, the ao_sample_format has a new field called matrix in 1.x....As new features are added to libao, version information in the ao.h header would be helpful so code that uses libao can detect the version and use the new features.
For example, the ao_sample_format has a new field called matrix in 1.x.x that is not int version 0.8.8 (the version currently in the Ubuntu repositories 10.04, 11.04).
I'm releasing code that will work with 0.8.8 but it would be nice to be able to include code for 1.1.0 when it becomes available in the Ubuntu repositories.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1808libao web documentation incorrect fo ao_play2017-11-03T10:00:02ZNicklibao web documentation incorrect fo ao_playThe web documentation for ao_play specifies void * data, not char * data.
Suggest generating reference documentation from the source code using a tool like Doxygen.
The web documentation for ao_play specifies void * data, not char * data.
Suggest generating reference documentation from the source code using a tool like Doxygen.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1806Amend ALSA options2011-05-28T08:58:04ZKaroly NegyesiAmend ALSA optionsIt took me quite some time to figure out how to configure my alsa configuration. I would recommend adding a mapping from aplay -L because it's everything but trivial to map especially the default.
It says:
The alsa driver normally choo...It took me quite some time to figure out how to configure my alsa configuration. I would recommend adding a mapping from aplay -L because it's everything but trivial to map especially the default.
It says:
The alsa driver normally chooses one of "surround71", "surround51", "surround40", "front", or "default" automatically depending on number of output channels.
I would change to:
You can see the available devices by running aplay -L. Use the name before the colon, for example "surround71", "surround51", "surround40", "front", or "default". The alsa driver normally chooses one of these in the order above automatically depending on the number of output channels.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1801Missing header from sndio backend.2017-11-03T10:00:02ZBrad SmithMissing header from sndio backend.The sndio backend is currently missing the string.h header which results in the following warnings...
```
ao_sndio.c: In function 'ao_plugin_set_option':
ao_sndio.c:84: warning: incompatible implicit declaration of built-in function 'st...The sndio backend is currently missing the string.h header which results in the following warnings...
```
ao_sndio.c: In function 'ao_plugin_set_option':
ao_sndio.c:84: warning: incompatible implicit declaration of built-in function 'strdup'
ao_sndio.c: In function 'ao_plugin_open':
ao_sndio.c:105: warning: incompatible implicit declaration of built-in function 'strdup'
ao_sndio.c:127: warning: incompatible implicit declaration of built-in function 'strdup'
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1799Leak in audio_out.c2017-11-03T10:00:02ZGitlab BotLeak in audio_out.cao_shutdown should free info_table.
Fix by adding this line in ao_showdown:
free(info_table);
ao_shutdown should free info_table.
Fix by adding this line in ao_showdown:
free(info_table);
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1787Writing "au" file to stdout causes call to "ao_play" to crash2017-11-03T10:00:02ZMatthew FlintWriting "au" file to stdout causes call to "ao_play" to crash(It's probably something I'm doing wrong, but I can't find anywhere more suitable to ask for help)
Hello,
I'd like to use "libao" to output an "au" stream to STDOUT.
If I call "ao_open_file" with a filename, then a valid "au" file is...(It's probably something I'm doing wrong, but I can't find anywhere more suitable to ask for help)
Hello,
I'd like to use "libao" to output an "au" stream to STDOUT.
If I call "ao_open_file" with a filename, then a valid "au" file is created. But if I use the special filename "-", then the program crashes during a call to "ao_play".
Are there any other special changes I need to make, in order to write to STDOUT? I assumed from the docs that I'd just need to give the special filename...
Finally, is there anything I could be doing to provide more useful information?! ;-)
Thanks!
MatthewStan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/1779libao plugins call functions defined in libao proper2017-11-03T10:00:02ZChris Brannonlibao plugins call functions defined in libao properOur project uses libltdl to dynamically load plugin modules.
One of our modules links against libao.
When we try to load that module, libao prints an error message stating
that dlopen() failed when loading libao's alsa plugin.
I patched ...Our project uses libltdl to dynamically load plugin modules.
One of our modules links against libao.
When we try to load that module, libao prints an error message stating
that dlopen() failed when loading libao's alsa plugin.
I patched libao, so that I could see the message reported by dlerror.
dlerror claims that ao_is_big_endian is undefined.
Should libao's plugins be calling functions defined by libao itself?
Note that this also causes problems for language bindings like pyao.Monty MontgomeryMonty Montgomeryhttps://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 Montgomery