similar to: [kcarnold@xiph.org: [xiph-cvs] cvs commit: vorbis/vorbis-tools/libao ao_alsa.c ao_oss.c audio_out.c audio_out.h]

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

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

Hey' Can't seem to compile libao. I'm using Slackware-7.1-current-ish, linux-2.4.2, gcc-2.95.2, and alsa-9.0-beta2. This is the first time I've tried to compile libao so I don't know if the problem is related to alsa-9.0 changes. Alsa headers seem to be there: /usr/include/linux> ls -l as*.h -rw-r--r-- 1 root root 35994 Mar 3 10:57 asequencer.h -rw-r--r-- 1

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

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,

The attached patch for src/plugins/alsa/ao_alsa.c supersedes the one I posted last night (well, this morning actually...) The changes are: Handling of incomplete snd_pcm_write()s that actually works (hey, I was sleepy when I wrote the other one). Padding of the playback buffer with zeroes to meet the N*fragment size requirement for snd_pcm_write(). (It might be better to use stream mode

The enclosed patch to ao_alsa.c (src/plugins/alsa/ao_alsa.c) fixes (after a fashion) a problem I had with interrupted snd_pcm_write() calls. Apparently this behaves like write() rather than fwrite() and needs to be handled accordingly. The fix is dirty, but it gets the thing working. The patch is against the 0.8.0 version of libao, but I believe the latest ao_alsa.c from CVS is similar (if not

------- Forwarded Message The following patches should fix vorbis-tools to build on NetBSD. I'm not including the diff to the configure scripts, so you'll need to rerun autoconf in the toplevel and libao directory after applying these patches to the configure.in files. It also appears that vorbis-tools/libao/ao_libs.inc is automatically generated by a configure script but checked into

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

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

attached please find patches to make vorbis kit (2000/8/18 daily tar.gz) to compile on netbsd. we need more tests and cleanups (like moving -lossaudio into AC_CHECK_LIB() in configure.in), but it should be good as starting point. thanks. itojun PS: i'm not on the list. if possible please cc: to me. $NetBSD: patch-aa,v 1.1.1.1 2000/08/17 16:56:18 itojun Exp $ ---

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

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

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

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

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 >

machine/soundcard.h was only a compatibility symlink to sys/soundcard.h and just went away. >From Motoyuki Konno <motoyuki@bsdclub.org>. --- src/plugins/oss/ao_oss.c.orig Wed Apr 10 21:56:57 2002 +++ src/plugins/oss/ao_oss.c Wed Apr 10 21:57:11 2002 @@ -32,8 +32,6 @@ #include <math.h> #if defined(__OpenBSD__) || defined(__NetBSD__) #include <soundcard.h> -#elif

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

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

Here is a patch that makes ao_alsa.c support alsa 0.9. Device parameter "card" is gone from the 0.9 version and "dev" has changed from numeric to string and defaults to "default" (another possibility is "plughw:0,1"). The configure.in changes cover allowing alsa 0.9 and /not/ having arts-dev (or whatever it is) installed. Bill (taniwha) -- Leave others