similar to: ao/

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 >

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

Hi, I've written an ao plugin for aRts, the soundserver that comes with KDE. Any chance of including this in the ao distribution ? Pretty please ? :) Sources and patches attached. This is a very simple plugin because it uses the easy-to-use 'artsc' C wrapper that aRts installs. configure.in.diff is for ao/configure.in Makefile.am.diff is for ao/src/plugins/Makefile.am Makefile.am

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, 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

Just a quick note that the priority in the Pulse AO plugin (ao/src/plugins/pulse/ao_pulse.c) should be changed from 41 to 50 (in the ao_pulse_info struct). Since the plugin now ships as part of libao, its priority should be a factor of 5, as that's how I designed the plugin priority system. Plugins that ship with libao should be a factor of 5, so that 3rd party plugins can fit in between

Boa Tarde, Estou com problemas para autentica??o de meus computadores no dominio samba. Quando tento pelo pr?prio windows ou na m?o pelo console adicionar uma m?quina ao dominio, ela ? cadastrada com sucesso, ela fica em ou=Computers,dc=xxx,dc=xxx por?m o smbd a procura em people o que resulta que meus usu?rios n?o conseguem logar... assim ... ao inves de o sambra procurar em ou=Computers ele

I added a couple of functions to my copy of ao. int ao_get_driver_count(void); const char * ao_get_driver_name(int index); With these, I can get a list of drivers and give the user a choice by using radio buttons, e.g. [ ] alsa [*] oss [ ] esd [ ] null [ ] wav This is a lot nicer than just asking them to enter the name of the driver. Here's the code I added to audio_out.c: const char *

I just committed what will eventually become the next version of libao. I've made some major changes: renamed stuff, redesigned the API, actually documented things. It *will* break any current libao applications (like ogg123). It is on its own branch, so it shouldn't affect the mainline libao code for a while. But beware: I want to land this branch before Vorbis 1.0 goes out. Please

Hi Jeremy, I went through the list archives, and have been trying to follow and implement things as I understand: 1. libao needs <sys/soundcard.h> and <machine/soundcard.h>, and so I linked /usr/include/soundcard.h there. 2. Since `soundcard.h' doesn't have SNDCTL_DSP_GETODELAY, I uncommented that particular line in `src/plugins/oss/ao_oss.c'. These steps made sure

I decided to take a break from trying to get the encoding working in order to update my libraries to the latest versions I tried to build ao-python from both SRPM and tarball, and here's what I got: --- + python setup.py install --root=/var/tmp/pyao-buildroot --record=INSTALLED_FILES running install running build running build_ext building 'aomodule' extension creating build creating

Rather than using libtool to build its sets, the ao.m4 in beta3 is hard coding '-ldl': AO_LIBS="$AO_LIBS -lao -ldl" Not all systems have a dl library. For now, I can obviously just remove it and keep working on stuff, but what would be a suitable patch that would get accepted to be committed? Should I just check the current build target and set AO_LIBS differently on my

I have sent some patches to some Makefile.am's as well as to some configure.in's, particularly for building without gcc and gmake. Can someone review those patches, and/or commit them? (we are working at the CVS head these days, no?) I cannot build in Solaris without gcc/gmake, for example -- running "autogen.sh" in the ao project with the native Solaris compilers causes

I submitted four new packages for the NetBSD pkgsrc collection: libao, libogg, libvorbis and vorbis-tools for 1.0beta4. The following is some of the patches needed for libao and vorbis-tools. Official Developers: When you receive patches or development suggestions can you please acknowledge them? (For example: "Noted.", "Thanks, but already done.", "Not necessary,

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

Hello, I hope this is the right place to ask. I am having random lockups from the python bindings. My app has one or two threads running, the lockups only occure at one point, here is the code run as a thread def play(self): self.playing = TRUE self.output = [] self.lastplay = time.time() args = self.song_file, self.output retval =

Why has ao been changed so that there are now two open() functions ? IMHO the original ao_open() was fine - if you wanted to set the filename for output, you could add an option via ao_append_option and if you wanted to avoid overwriting an existing file, you could stat() it yourself. Having ao_open_live() and ao_open_file() just makes more work for the user of the library for no gain, AFAICT.

Why has ao been changed so that there are now two open() functions ? IMHO the original ao_open() was fine - if you wanted to set the filename for output, you could add an option via ao_append_option and if you wanted to avoid overwriting an existing file, you could stat() it yourself. Having ao_open_live() and ao_open_file() just makes more work for the user of the library for no gain, AFAICT.

Ok, I managed to compile the Ogg and Vorbis libs. Then, after modifying the file audio_out.c as follows: original: #include <dlfcn.h> modified: #include <win32/include/dlfcn.h> I was able to (finally!) compile libao. Then I tried to compile the module vorbis-tools, but uninvited problems came to my party. [...] > /usr/bin/ld: multiple definitions of symbol _getopt >

Here's the promised Sun audio system plug-in. I have tested this on OpenBSD. It should work without changes on NetBSD, too. Jeremy, could you please verify this? After a few minor tweaks it now also compiles on Solaris 2.7. Alas, I can't verify whether it actually plays anything there. I guess this could also with little effort be made to work on SunOS4. Attached: - Diff to