Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-01-21T13:05:26Zhttps://gitlab.xiph.org/xiph/speex/-/issues/1616Problem configuring speex 1.2rc12018-01-21T13:05:26ZPierreProblem configuring speex 1.2rc1[...]
checking for main in -lwinmm... yes
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for short... yes
checking size of short... configure: error: cannot compute size...[...]
checking for main in -lwinmm... yes
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for short... yes
checking size of short... configure: error: cannot compute sizeof (short)
See `config.log' for more details.
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/speex/-/issues/1739Speex uses GCC specific compile option2018-01-21T13:05:26ZBrian CameronSpeex uses GCC specific compile option
Speex will not compile with the Sun Studio compiler because it uses a GCC-specific compile option. Can this be removed, or can the configure script be made smarter so it only adds this sort of compile option when GCC is actually being ...
Speex will not compile with the Sun Studio compiler because it uses a GCC-specific compile option. Can this be removed, or can the configure script be made smarter so it only adds this sort of compile option when GCC is actually being used. See attached patch to see the issue.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/speex/-/issues/1832Encoding state on the fly2018-01-21T13:05:26ZGitlab BotEncoding state on the flyWhen i create and destroy my encoding state and my Bits for each frame i get a "tick" between each of them. Since it's not in the documention i though i will give you the feedback. A lot of people are not supposed to know that, specially...When i create and destroy my encoding state and my Bits for each frame i get a "tick" between each of them. Since it's not in the documention i though i will give you the feedback. A lot of people are not supposed to know that, specially C++ programmers who usually create objects as needed.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1818libvorbisenc NULL dereference2017-12-31T04:26:08ZMathieu Gelilibvorbisenc NULL dereferenceHi,
I'm running mpd with vorbis streaming enabled on an ARMv5 device. mpd SEGFAULT upon startup because of libvorbisenc.so.2 as seen by this GDB log :
```
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x43d9...Hi,
I'm running mpd with vorbis streaming enabled on an ARMv5 device. mpd SEGFAULT upon startup because of libvorbisenc.so.2 as seen by this GDB log :
```
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x43d9c410 (LWP 25624)]
0x4101bd20 in vorbis_encode_setup_init () from /usr/lib/libvorbisenc.so.2
(gdb) x/16i $pc
=> 0x4101bd20 <vorbis_encode_setup_init+6420>: ldr r4, [r2, #4]
0x4101bd24 <vorbis_encode_setup_init+6424>: cmp r4, #0
0x4101bd28 <vorbis_encode_setup_init+6428>: mvneq r0, #0
0x4101bd2c <vorbis_encode_setup_init+6432>: beq 0x4101bdd4 <vorbis_encode_setup_init+6600>
0x4101bd30 <vorbis_encode_setup_init+6436>: mov r1, r11
0x4101bd34 <vorbis_encode_setup_init+6440>: mov r0, r10
[...]
```
NULL deref is here in vorbis/lib/vorbisenc.c :
```
static double setting_to_approx_bitrate(vorbis_info *vi){
[...]
r = setup->rate_mapping; // setup == NULL
[...]
}
```
setup (that is (&(&vi->codec_setup)->hi)->setup ) is changed to NULL in the following code :
```
static void vorbis_encode_floor_setup(vorbis_info *vi,int s,
const static_codebook *const *const *const books,
const vorbis_info_floor1 *in,
const int *x){
int i,k,is=s;
vorbis_info_floor1 *f=_ogg_calloc(1,sizeof(*f));
codec_setup_info *ci=vi->codec_setup;
```
If I swap the last two lines and watch (&ci->hi)->setup before and after the _ogg_calloc call I see that after it is NULL.
Any suggestions to fix that ?
Thanks !
--
Mathieu
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2190ezstream (libshout?) hangs while streaming the attached mp32017-11-16T12:06:13Zjakebriggsezstream (libshout?) hangs while streaming the attached mp3ezstream (libshout?) hangs while streaming the attached mp3. Using advanced debugging techniques (printf's, everywhere, a forest of printf's) I've made my way down to the function shout_send in libshout - specifically I think this never ...ezstream (libshout?) hangs while streaming the attached mp3. Using advanced debugging techniques (printf's, everywhere, a forest of printf's) I've made my way down to the function shout_send in libshout - specifically I think this never returns:
```
return self->send(self, data, len);
```
but my advanced debugging techniques ran out of steam here.... I might have a play with gdb but I've never played with that before....Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2238Delete SHOUTERR_METADATA2017-11-16T12:06:13ZPhilipp SchafftDelete SHOUTERR_METADATAThe error value SHOUTERR_METADATA is never used and has no comment telling what it should be used for. Also the error-to-string function shout_get_error() doesn't include it.
This should be cleaned up as part of the next ABI change.The error value SHOUTERR_METADATA is never used and has no comment telling what it should be used for. Also the error-to-string function shout_get_error() doesn't include it.
This should be cleaned up as part of the next ABI change.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/1891fix autoconf so configure --enable/--disable-foo is tri-state2017-11-05T22:14:58ZThomas B. Rückerfix autoconf so configure --enable/--disable-foo is tri-stateCurrently you can --enable-foo, but if foo headers are not there it will just switch off 'foo', instead of failing due to 'foo headers missing'.Currently you can --enable-foo, but if foo headers are not there it will just switch off 'foo', instead of failing due to 'foo headers missing'.Thomas B. RückerThomas B. Rückerhttps://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/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/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/1972libao alsa output driver fails to open device2017-11-03T10:00:01ZCody P Schaferlibao alsa output driver fails to open deviceAn example using ogg123 (a libao user) vs mplayer (which does not use libao)
```
~ $ cat /etc/libao.conf
default_driver=alsa
dev=default
debug
~ $ ogg123 ~/Radiohead_-_Pyramid_Song_\(sample\).ogg
debug: Loaded driver null (built-in)
de...An example using ogg123 (a libao user) vs mplayer (which does not use libao)
```
~ $ cat /etc/libao.conf
default_driver=alsa
dev=default
debug
~ $ ogg123 ~/Radiohead_-_Pyramid_Song_\(sample\).ogg
debug: Loaded driver null (built-in)
debug: Loaded driver wav (built-in)
debug: Loaded driver raw (built-in)
debug: Loaded driver au (built-in)
debug: Loading driver plugins from /usr/lib64/ao/plugins-4...
debug: Loaded driver pulse
debug: Loaded driver alsa
debug: Loaded driver oss
debug: Testing drivers to find playback default...
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Playing: /home/cody/Radiohead_-_Pyramid_Song_(sample).ogg
Ogg Vorbis stream: 2 channel, 44100 Hz
ao_alsa debug: Trying to open ALSA device 'default'
ao_alsa debug: snd_pcm_hw_params_set_access() failed.
ao_alsa debug: Unable to open ALSA device 'default'
ao_alsa ERROR: Unable to open ALSA device 'default' for playback => Invalid argument
ERROR: Cannot open device alsa.
~ $ mplayer -ao alsa ~/Radiohead_-_Pyramid_Song_\(sample\).ogg
MPlayer 1.1-4.7.3 (C) 2000-2012 MPlayer Team
MMX2 supported but disabled
Playing /home/cody/Radiohead_-_Pyramid_Song_(sample).ogg.
libavformat version 54.63.104 (external)
libavformat file format detected.
[vorbis @ 0x7fc9a96a07a0]Warning: not compiled with thread support, using thread emulation
[lavf] stream 0: audio (vorbis), -aid 0
Load subtitles in /home/cody/
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
libavcodec version 54.92.100 (external)
[vorbis @ 0x7fc9a96a07a0]Warning: not compiled with thread support, using thread emulation
AUDIO: 44100 Hz, 2 ch, floatle, 64.0 kbit/2.27% (ratio: 8000->352800)
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis)
==========================================================================
AO: [alsa] 44100Hz 2ch floatle (4 bytes per sample)
Video: no video
Starting playback...
A: 2.1 (02.0) of 28.6 (28.6) 0.8%
Exiting... (Quit)
```
The specific version of libao used is gentoo's `libao-1.1.0-r1`.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1976libao / OSS on illumos2017-11-03T10:00:01ZGabriele Bulfonlibao / OSS on illumosHi, we're working on a new distro based on illumos (Solaris fork).
While trying to work out xmms2, we had to build and package libao,
required for xmms2 / OSS on Solaris brands.
It works for many simple audio files, but not for many hig...Hi, we're working on a new distro based on illumos (Solaris fork).
While trying to work out xmms2, we had to build and package libao,
required for xmms2 / OSS on Solaris brands.
It works for many simple audio files, but not for many high quality
mp3 or so, because libao seems not to support 32 bit samples in
this configuration:
ao_oss ERROR: Unsupported number of bits: 32.ao_oss
Is there anything we can do to make it work?
Gabriele.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/2006libao: 24-bit ALSA playback is broken2017-11-03T10:00:01ZAndrew Ekstedtlibao: 24-bit ALSA playback is brokenALSA requires 24-bit samples to be padded to 32 bits.
> The 24-bit linear samples use 32-bit physical space, but the sample is stored in the lower three bytes.
> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_formats
Libao ...ALSA requires 24-bit samples to be padded to 32 bits.
> The 24-bit linear samples use 32-bit physical space, but the sample is stored in the lower three bytes.
> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_formats
Libao used to do this correctly, but changeset r18883 (which made it in to libao 1.2) rewrote the padding code to also handle upconverting arbitrary sample sizes, by filling the low bytes with zeros. Unfortunately, ALSA's 24-bit padding works the other way around - the _high_ byte is supposed to be zero-filled. Needless to say, padding the wrong end doesn't work very well.
https://gitlab.xiph.org/xiph/libao/-/issues/2034release 1.2.0 was not announced and is not linked on the downloads page2017-11-03T10:00:01Zjohn_spencerrelease 1.2.0 was not announced and is not linked on the downloads pagedespite it being available on the ftp since several weeksdespite it being available on the ftp since several weeksMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/2035libao 1.2.0 differing behaviour for 8bit audio2017-11-03T10:00:01Zjohn_spencerlibao 1.2.0 differing behaviour for 8bit audiolibao 1.1.0 behaves as expected: the amplitude is unsigned (0..255)
libao 1.2.0 behaves differently: the amplitude is signed (-128..127)
noticed when trying to mute a stream by using 0 for the samples
for 1.2.0 you have to pass 127 to m...libao 1.1.0 behaves as expected: the amplitude is unsigned (0..255)
libao 1.2.0 behaves differently: the amplitude is signed (-128..127)
noticed when trying to mute a stream by using 0 for the samples
for 1.2.0 you have to pass 127 to mute.
```
#include <unistd.h>
#include <ao/ao.h>
#include <stdlib.h>
#include <string.h>
struct AoWriter {
ao_device *device;
ao_sample_format format;
int aodriver;
};
int AoWriter_init(struct AoWriter *self) {
ao_initialize();
memset(self, 0, sizeof(*self));
self->format.bits = 8;
self->format.channels = 1;
self->format.rate = 11025;
self->format.byte_format = AO_FMT_LITTLE;
self->aodriver = ao_default_driver_id();
self->device = ao_open_live(self->aodriver, &self->format, NULL);
return self->device != NULL;
}
int AoWriter_write(struct AoWriter *self, void* buffer, size_t bufsize) {
return ao_play(self->device, buffer, bufsize);
}
int AoWriter_close(struct AoWriter *self) {
return ao_close(self->device);
}
static unsigned char blip[] = {0x52, 0x51, 0x51, 0x51, 0xC4, 0x4C, 0xF4, 0xF4, 0xF3,0xEF};
static int blip_frame(int idx) {
idx = idx % (2*sizeof(blip));
if(idx>=sizeof(blip)) idx=(2*sizeof(blip))-idx;
return blip[idx];
}
static void generate_blip(unsigned char* data, size_t bufsize, double volume) {
int i;
for(i=0;i<bufsize;i++)
/* libao 1.1.0 behaves as expected: the amplitude is unsigned (0..255)
libao 1.2.0 behaves differently: the amplitude is signed (-128..127) */
#if 1
data[i] = (blip_frame(i)-128)*volume+127;
#else
data[i] = blip_frame(i)*volume;
#endif
}
#define DEFAULT_VOLUME 0.02
int main() {
struct AoWriter ao;
AoWriter_init(&ao);
unsigned char buf[100];
generate_blip(buf, sizeof(buf), DEFAULT_VOLUME);
unsigned passed = 0;
while(1) {
usleep(1000);
passed++;
if(passed >= 200) {
passed=0;
AoWriter_write(&ao, buf, sizeof buf);
}
}
AoWriter_close(&ao);
return 0;
}
```
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/2051non-blocking ao_play() and associated ao_wait()2017-11-03T10:00:01ZPeter Billamnon-blocking ao_play() and associated ao_wait()Greetings. I've been exploring libao, but for what I want to do I need a non-blocking ao_play(), so I can then do processing in real-time, then an ao_wait to get to the end of the previous buffer, then play my new buffer and loop.
It lo...Greetings. I've been exploring libao, but for what I want to do I need a non-blocking ao_play(), so I can then do processing in real-time, then an ao_wait to get to the end of the previous buffer, then play my new buffer and loop.
It looks like this has not been implemented, perhaps because it's not portable enough :-(
Suggestions gratefully received...
Regards, PeterMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/2083[patch] support for jack in libao2017-11-03T10:00:01Zlparcq[patch] support for jack in libaoThe patch for the configure.ac and src/plugins/Makefile.am is 0001-jack-plugin.patch
The code for the plugin itself is libao-jack-plugin.tgz
By default it connects to all available physical ports. It can be configured
with the paramet...The patch for the configure.ac and src/plugins/Makefile.am is 0001-jack-plugin.patch
The code for the plugin itself is libao-jack-plugin.tgz
By default it connects to all available physical ports. It can be configured
with the parameter "ports"
ports=system:playback_1,system:playback_2
The plugin uses libsamplerate to resample the audio to the jack server rate.
There are different algorithms in libsamplerate. There are selected according to
the value of parameter "quality" (value from 0 to 9). The default is 5. It
impacts the CPU consumption.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/2196ao_open_file: Race condition in checking for file2017-11-03T10:00:01ZRaúl Salinas-Monteagudoao_open_file: Race condition in checking for fileWhen "not overwrite" is specified, [ao_open_file()](https://trac.xiph.org/browser/trunk/ao/src/audio_out.c#L1352) will try to first open it for reading and this does not fail, open it for writing.
```
if (!overwrite) {
/* Test for fil...When "not overwrite" is specified, [ao_open_file()](https://trac.xiph.org/browser/trunk/ao/src/audio_out.c#L1352) will try to first open it for reading and this does not fail, open it for writing.
```
if (!overwrite) {
/* Test for file existence */
file = fopen(filename, "r");
if (file != NULL) {
fclose(file);
errno = AO_EFILEEXISTS;
return NULL;
}
}
file = fopen(filename, "w");
```
There is a [TOCTTOU](http://en.wikipedia.org/wiki/Time_of_check_to_time_of_use) condition, the file could have been created by someone else after the check.
A non-racy way to create it would be to use
```
file=fopen(filename, "wx");
```
and checking for the errno E_EXIST.
If this is not portable enough, open( ... , O_CREAT|O_EXCL) could be used.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/2217libao fails to signal output device change2017-11-03T10:00:01Zjrleemanlibao fails to signal output device changelibao does not signal a change of audio output device in such a way that applications may respond. Related to/discovered in pianobar issue: https://github.com/PromyLOPh/pianobar/issues/536#issuecomment-135080348 libao does not signal a change of audio output device in such a way that applications may respond. Related to/discovered in pianobar issue: https://github.com/PromyLOPh/pianobar/issues/536#issuecomment-135080348 Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/2282Sample rate: return effective value, option to disable auto-conversion2017-11-03T10:00:01ZDaniel Richard G.Sample rate: return effective value, option to disable auto-conversionI am writing a program based on LibAO that synthesizes sound. For this to work correctly, I need to know the exact sample rate that is in effect.
Unfortunately, this is at present not so straightforward in LibAO. Some drivers may not gi...I am writing a program based on LibAO that synthesizes sound. For this to work correctly, I need to know the exact sample rate that is in effect.
Unfortunately, this is at present not so straightforward in LibAO. Some drivers may not give you the exact rate you request, but something close. (Problem: You have no way of knowing what the real rate is.) Some drivers, like "alsa", will actually give you any arbitrary sample rate you choose (let's do 512 kHz!) but actually resample in software to whatever the hardware wants. (Problem: This eats up CPU, and messes up my synthesis.)
The attached patch (against git master) addresses these issues:
1. As far as I can tell, only the "alsa", "macosx" and "oss" drivers can give you a sample rate different than what you requested. In these, I added code to update the ao_sample_format struct that was passed in to reflect the actual rate. This way, the calling program can subsequently examine the struct to see what it got.
(The same thing could potentially be done with other parameters in there, like the channels. I think this would be a good pattern to follow generally, as the struct is otherwise useless after the ao_open_*() call.)
2. Pass in SND_PCM_NO_AUTO_RESAMPLE to the snd_pcm_open() call in ao_alsa.c, to disable the "dmix" resampling layer. If you request a rate of 512000, you should see a "sample rate not supported" warning and get an actual rate like 48000; you should not get a software simulation of a 512 kHz ultra-hi-def sound card.
(FYI: the snd_pcm_hw_params_set_rate_resample() function may be another way of going about this. I used the aforementioned open-mode flag only because I saw its use in a patch to VLC's ALSA driver.)Monty MontgomeryMonty Montgomery