libao issueshttps://gitlab.xiph.org/xiph/libao/-/issues2017-11-03T10:00:01Zhttps://gitlab.xiph.org/xiph/libao/-/issues/1904Silent option handling can lead to pain2017-11-03T10:00:01ZEd SchwartzSilent option handling can lead to painHi,
I just spent an hour or so debugging a painful, silly user error.
The problem was that I commented out some lines in /etc/libao.conf by prepending #.
Some drivers, like alsa, allow options with unknown keys to be set. Other drive...Hi,
I just spent an hour or so debugging a painful, silly user error.
The problem was that I commented out some lines in /etc/libao.conf by prepending #.
Some drivers, like alsa, allow options with unknown keys to be set. Other drivers, like pulse, do not.
I had a commented out line with the alsa driver (which worked), and could not figure out why the pulse driver would mysteriously fail!
A quick fix to help stupid people like me would be to add a verbose error message in audio_out.c:
if (!device->funcs->set_option(device, options->key, options->value)) {
/* Problem setting options */
aerror("Unable to set option %s\n", options->key);
return AO_EOPENDEVICE;
}
It probably also makes sense to make sure that all audio plugins behave consistently when given invalid options.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1856dlopen: use RTLD_LAZY instead of RTLD_NOW2017-11-03T10:00:01ZGitlab Botdlopen: use RTLD_LAZY instead of RTLD_NOWSummary says it all. There are issues with newer versions of glibc and libao.
Cdemu is suffering from this on Fedora and Archlinux.
Please have a look: https://sourceforge.net/tracker/?func=detail&aid=3449342&group_id=93175&atid=603423
...Summary says it all. There are issues with newer versions of glibc and libao.
Cdemu is suffering from this on Fedora and Archlinux.
Please have a look: https://sourceforge.net/tracker/?func=detail&aid=3449342&group_id=93175&atid=603423
Might already be on your list.
CheersMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1844Mac OS X 10.7.2 Build 11C74 - Loss of audio when inserting or removing device...2017-11-03T10:00:01ZlordB8rMac OS X 10.7.2 Build 11C74 - Loss of audio when inserting or removing device from audio jackIdentical to issue #1731 (closed), but I'm up to date on libao:
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 ...Identical to issue #1731 (closed), but I'm up to date on libao:
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.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1834plugin directory cannot be relocated (OS X)2020-06-14T10:13:32ZHans Oesterholtplugin directory cannot be relocated (OS X)I'm using flac123, which in turn uses libao for it's audio output. I'm creating an application to play music on Mac OS X. I compiled Gtk, mpg123, flac123 and libao in a development environment and next I need to install flac123/libao as ...I'm using flac123, which in turn uses libao for it's audio output. I'm creating an application to play music on Mac OS X. I compiled Gtk, mpg123, flac123 and libao in a development environment and next I need to install flac123/libao as part of CuePlay in the /Applications/CuePlay.app directory.
This means that /<home>/workspace/cueplay/lib/ao/plugin-4 is relocated to /Applications/CuePlay.app/lib/ao/plugin-4.
The consequence is that plugins do not load anymore.
I think this is a bug. On Mac OS X, one should be able to install a library with the application and not on a fixed location.
For me this is a blocker, because I can't distribute my (open source) application this way.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1830shell-fm doesn't open /dev/snd/timer2011-08-22T17:28:00ZGitlab Botshell-fm doesn't open /dev/snd/timerI have a problem using [shell-fm](http://nex.scrapping.cc/shell-fm/) and libao (it uses libao for playback).
If the file/dev/snd/timer is not opened by any process, shell-fm starts playing music without opening it. However if it's alrea...I have a problem using [shell-fm](http://nex.scrapping.cc/shell-fm/) and libao (it uses libao for playback).
If the file/dev/snd/timer is not opened by any process, shell-fm starts playing music without opening it. However if it's already opened by another process, it opens it.
The problem is that when shell-fm starts playing sounds without opening /dev/snd/timer, any other process can't play sounds.
I can't reproduce this behavior using libao 1.0.
As default driver I'm using alsa.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/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/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/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/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/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/654LibAO should support format change without closing/opening devices.2010-01-30T13:47:13ZtruLibAO should support format change without closing/opening devices.To achive gapless playback between two files with diffrent samplerate you should really have the option to change the audio format without closing and opening the device. This is supported by most audio backends and should be a new api c...To achive gapless playback between two files with diffrent samplerate you should really have the option to change the audio format without closing and opening the device. This is supported by most audio backends and should be a new api call to libao.Monty MontgomeryMonty Montgomery