similar to: Preview of next version of libao

A branch of ogg123 is in CVS now which you can use to test the libao prerelease. Because of the way I did the branch, checkout is a little screwy (as Monty once said: "Know thy tools!"). (I am assuming here that you already have CVSROOT set correctly.) cvs co vorbis-tools # Notice there is no tag here! cd vorbis-tools/ogg123 cvs update -r volsung_20010721 Or, if you already have

Hi! There are some little inconvenience in libao-0.8.5. - The biggest is may that: the documentation and the header file declare the ao_file_extension function, which give a hint for the file extension where the device is realy a sound file. This function is missing. -An other: the alsa 0.5 and the alsa 0.9+ drivers short name. It will be better if the alsa 0.5's name will be alsa05 and the

Hi, I noticed there was some discussion on this list about the desire for ogg123 to support output to stdout via Sun's .au file format, so I decided to give implementing an AU driver for libao a shot. Here is my first attempt. To test the driver: * Apply the patch below (against ao in CVS) * Copy the attached ao_au.c into ao/src * Run ao/autogen.sh, compile, and

OK, wanted to check out the macosx driver for libao on me new iBook. Everything compiles beautifully (given some utils from the fink project, like automake), but... but the dynamic plugin system is broken. 1) on OS X, dll's en in .dylib, not .so, as is hardwired in. this should be an easy fix. 2) dlopen chokes on opening the .dylib files...so the plugin is never loaded. i know not enought

OK, wanted to check out the macosx driver for libao on me new iBook. Everything compiles beautifully (given some utils from the fink project, like automake), but... but the dynamic plugin system is broken. 1) on OS X, dll's en in .dylib, not .so, as is hardwired in. this should be an easy fix. 2) dlopen chokes on opening the .dylib files...so the plugin is never loaded. i know not enought

Hi there. Sorry I may be a little off topics with this mail but I have already written to the official libao maintainer (volsung@xiph.org) and he is the one who suggest me to write here. As I did not see any more suitable mailing list @xiph.org here I am. My point is that I have recently written a win32 driver for the libao and I would be glad to see this contribution include to the official

I tried sending this once, but it appears my school is having mail server issues. I've been playing with libao on OS X; I wanted to check out the macosx plugin for it, see if I could bend it to my will. Given some utilities from the fink project (automake comes to mind) I was able to compile it just fine. But, there was a problem. It cannot load dynamic plugins! The first reason I found

I tried sending this once, but it appears my school is having mail server issues. I've been playing with libao on OS X; I wanted to check out the macosx plugin for it, see if I could bend it to my will. Given some utilities from the fink project (automake comes to mind) I was able to compile it just fine. But, there was a problem. It cannot load dynamic plugins! The first reason I found

Hi Heikki, So libao is currently not maintained upstream. In the appropriate IRC channels I'm lead to believe that there are better libraries out there that should be used instead. If so many debian packages didn't link against it I would seriously consider dropping it all together. It doesn't sound like it's worth anyone's time maintaining libao properly upstream. I do have

Hi! On March 17th I posted a message on this list concerning an artifact bug in beta4 that is audible in all available bitrates. It was this rumbling sound in the bass area. I made a demo clip, which still is available at http://www.stud.uni-karlsruhe.de/~us87/ogg/vorbis_bassrumble_demo.rar and that contains both the original .WAV and an .OGG @ 350kbps. This archive is 2.1 MB large. Today, I

remember kenneth that libao has moved to the "ao" module, so copy the changes... jack. ----- Forwarded message from "Kenneth C. Arnold" <kcarnold@xiph.org> ----- Delivered-To: cvs-outgoing@xiph.org Delivered-To: cvs@xiph.org To: cvs@xiph.org Subject: [xiph-cvs] cvs commit: vorbis/vorbis-tools/libao ao_alsa.c ao_oss.c audio_out.c audio_out.h Date: Tue, 5 Sep 2000

While trying to compile libao 0.8.0 under OS X 10.1, I got the following problems: > [localhost:ecc/Sources/libao-0.8.0] root# ./configure > creating cache ./config.cache > checking for a BSD compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking whether make sets ${MAKE}... yes > checking for working aclocal... found >

Okay, here's the patch that should fix byte-ordering madness. The basic rule with libao is that samples have to be in native byte order. All of the drivers will assume this, and libao provides a ao_is_big_endian() function for library clients (and sometimes drivers) to test their byte ordering. I would appreciate it if someone on a big endian platform test ogg123 and make sure that it works

Here is a patch to fix the compiler warnings I mentioned earlier. I've removed the byte-order changes that don't make sense. (Thanks Michael for pointing out the error!) As for the byte-order changes, since some output modules don't have the option to set the sample byte-order, I would like to standardize libao and ogg123 on native byte-order. Will this break the ao_wav.c patches

Ok, this patch replaces the old patch I sent, and it does a bit more. For one, it sorts the linked list of drivers based on the priority values, highest valued ones coming first. That allows the _find_default_driver_id code to stop looping (break) immediately when it finds a driver that works, because it already knows it's the working driver with the highest priority (what it normally

Just so people know what I'm working on (between physics assignments), here's a quick list of what's currently in the pipeline: * I received an IRIX patch which I am very excited about. I'll be submitting that shortly. * A month ago another user sent me a very small patch that improved ALSA performance on his machine. I don't understand what it does exactly, and would

I hope this is the right place to submit libao patches -- the freshmeat page points to ogg vorbis as the homepage for libao. Currently, at least on my system (SB Live Value!, ALSA .9 branch), stuff going to alsa sounds *awful* because of too-small buffers. mpg321 and similar programs are unusable, and none of them seem to want to let you set the buffer size. This patch lets an environment

This patch fixes three problems with the current configure script: 1. Manual exclusion of drivers: Now you will be able to force drivers NOT to be compiled, even if they are detected. This was specifically requested with so that ALSA could be disabled. 2. Selecting the default device: Now you can override the default driver chosen by the script with your own preference. Again, this enhancement

Hi, I have downloaded the following files libao-0.6.0.tar.gz libogg-1.0beta4.tar.gz libvorbis-1.0beta4.tar.gz vorbis-tools-1.0beta4.tar.gz as said from the download section. But I'm at a loss to what do after that. I don't have much experience/knowledge in compiling etc, but I still want to try out ogg. (I downloaded the source coz I have an OpenBSD machine, and there was no

(Is this the right list for libao patches?) The following adds support for a sndio plugin to libao. sndio is OpenBSD's new audio API. diff -uNrp libao-0.8.8.orig/configure.ac libao-0.8.8/configure.ac --- libao-0.8.8.orig/configure.ac Thu May 24 12:51:05 2007 +++ libao-0.8.8/configure.ac Mon Dec 8 16:34:44 2008 @@ -300,6 +300,11 @@ dnl Check for Sun audio AC_CHECK_HEADERS(sys/audioio.h)