similar to: Raw driver patch for libao (New Version)

I've completed the new device for libao that just writes raw, headerless, unformatted audio data to the file of your choice. The driver also supports writing to stdout by specifying the output file to be "-". This is the better way to stream uncompressed audio for now, thereby avoiding the headaches contained in wav files. To add the driver: 1) Copy ao_raw.c into ao/src/ 2) Apply

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

I'm also working on writing the raw driver I mentioned in the last email, but noticed that Jack has rearranged some of the guts of ao since I last looked at it. In ao/include/ao/ao.h you define AO_NULL and AO_WAV to be 0 and 1, respectively. If I want to add a raw driver that is compiled into the main library, can I just add #define AO_RAW 2 and then modify ao_initialize to put ao_raw

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

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

In January I submitted a new "raw" output driver for libao that lets you write the audio samples directly to a file without any headers or anything else. It never got committed. Is it too late in the beta cycle to add it? I've been contacted by an author of a CD recording application whose problem could be solved by the inclusion of the raw driver. I need to make a change to the

I finally managed to compile ogg123 under MacOS X, after creating a PB project for it. Rillian, do you want to include the PB project in cvs? (it needs a LOT of polishing, though). ---------- Ogg123 from PACKAGE VERSION by Kenneth Arnold <kcarnold@arnoldnet.net> and others Usage: ogg123 [<options>] <input file> ... -h, --help this help -V, --version display

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

Here are some of my notes with building and using vorbis-tools-1.0beta4 under Debian Linux 2.2. 1) building libao: make[3]: Leaving directory `/home/jeremy/src/ogg/libao-0.6.0/src/plugins/alsa' Making all in arts make[3]: Entering directory `/home/jeremy/src/ogg/libao-0.6.0/src/plugins/arts' /bin/sh ../../../libtool --mode=compile gcc -DPACKAGE=\"libao\"

I've made a new source release of libao. This includes the polypaudio driver contributed by Lennart Poettering. http://downloads.xiph.org/releases/ao/libao-0.8.6.tar.gz http://downloads.xiph.org/releases/ao/libao-0.8.6.zip SHA1 checksums: 2050e008ffcfd6803e2c2c03c7d5f469b6d8379e libao-0.8.6.tar.gz 872ed527a4db012f315ce56e4b27a69e5b191a9f libao-0.8.6.zip MD5 checksums:

Hello, Can I get svn access for applying some libao patches? It seems that nobody maintains libao currently. This is really bad because there are many projects out wich using it. BTW: Not all kind of apps need all available audio controlling settings. My current plans: 1. extending ao_pulse for controlling prebuffering and latency 2. later extending libao api with volume control (softvol). 3. I

Kenneth mentioned he wanted a cross-platform audio library to use for ogg123. So, I've spent the last week hacking up the libao from ac3dec that someone suggested earlier. It bears little resemblance to the old code, but now does what I want. libao now supports OSS and WAV file output, with the infrastructure in place to expand further. There are Solaris and IRIX drivers that I inherited

I recently had a function added to the aRts API that lets you see if aRts is actually holding the DSP device open or not. This call can be useful in trying to autodetect what audio output to use, like libao does. I've written a patch for libao to take advantage of this. It adds an autoconf macro to test for the presence of this new function (so that it'll still work for people with an

On 16-01-13 21:52, Clemens Ladisch wrote: > Rene Herman wrote: >> I'm out of touch of with alsa -- but should dmix/dsnoop still be >> enabled by default on hardware that doesn't do hardware mixing? > > Yes. > >> I believe that it should be from /usr/share/alsa/cards/ICH4.conf, >> but I don't get mixing on this setup when using the

Hello Vorbis Developers. I'm in the proccess of writing an OggVorbis audio player using libao and libvorbisfile. I've greatly appreciated the simplicity of the API and good documentation with the souce of the libraries. I've descided that I really want a mixer on my player, and I'm unsure how to best go about it. LibAO (unless I'm absolutely blind) doesn't

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

Ben, Thanks for taking an interest in libao. Just so you know, there are a couple of things outstanding. Jeff Waugh asked whether we'd be willing to relicense libao so it can be used with proprietary applications. We have permission from the original authors to do this (either LGPL or BSD) and from Lennart Poettering, but not for most of the plugins. So if we did this the next release

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

According to this:http://www.mail-archive.com/fink-users@lists.sourceforge.net/msg03120.html try adding -L/sw/lib to the compilation. Silvia. -----Original Message----- From: ogg-dev-bounces@xiph.org on behalf of wind Sent: Thu 10/5/2006 5:19 AM To: ogg-dev@xiph.org Cc: Subject: [ogg-dev] problem using libao on OSX 10.4 Hello, I built the entire Vorbis kit on my PowerMac G4 running OSX

Compiling libao on a system w/linux2.4.2 & glibc-2.0 (I think), I get an error. gcc -DPACKAGE=\"libao\" -DVERSION=\"0.6.0\" -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DHAVE_SYS_SOUNDCARD_H=1 -I. -I. -I../../.. -I../../../include -O20 -ffast-math -D_REENTRANT -fsigned-char -DAO_PLUGIN_PATH=\"/usr/local/lib/ao\" -c ao_alsa.c -fPIC -DPIC -o ao_alsa.lo In file