similar to: libao source build problems on Mandrake 8.2b4: artsc.h missing?

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\"

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

I ran into a dependency problem while compiling the CVS snapshot which did not occur while compiling the beta 3 tarballs. For some missing resources, autogen.sh echoes very helpful messages (such as if automake is not present), but there was no indication that the kdelibs-devel package was required for ao (in order to get artsc.h into /usr/include - I'm sure it is possible to edit the

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

wine-20031212-1fc1winehq.src.rpm fails here: cd `dirname winmm/winearts/__depend__` && /usr/bin/make depend make[2]: Entering directory `/usr/src/redhat/BUILD/wine-20031212/dlls/winmm/wine arts' ../../../tools/makedep -I. -I. -I../../../include -I../../../include -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -C. a rts.c audio.c Unknown

Hello, i had nearly the same problem when compiling libao (of nightly snapshot of 2001/02/10) >checking for artsc-config... /usr/bin/artsc-config >I don't know enough about KDE to know if this file is supposed to be >there without any of the kde-devel packages installed (if not, then I >have a Mandrake bug). If I move this file so it can't be found, make >and make install

Hello, i had nearly the same problem when compiling libao (of nightly snapshot of 2001/02/10) >checking for artsc-config... /usr/bin/artsc-config >I don't know enough about KDE to know if this file is supposed to be >there without any of the kde-devel packages installed (if not, then I >have a Mandrake bug). If I move this file so it can't be found, make >and make install

The first error in CVS - fairly minor - is in the docs section: ---------------------------------------------------------------- make[1]: Entering directory `/tmp/temp/oggstuff/theora/doc' python txt2py.py spec.txt spec.py python txt2html.py spec.txt spec.html make[1]: *** No rule to make target `testspec.raw', needed by `all-am'. Stop.

Hi, I'm compiling theora from the cvs. I use it with mplayer. I had run in these problems: 1. At make time I got that: Making all in doc make[1]: Entering directory `/work/src/theora/doc' make[1]: *** No rule to make target `testspec.raw', needed by `all-am'. Stop. make[1]: Leaving directory `/work/src/theora/doc' make: *** [all-recursive] Error 1 I cannot skip that

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

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 >

libao.spec needs a couple of changes before an RPM can be built from current CVS (update the version number and change the module path). Aaron Plattner <HR NOSHADE> <UL> <LI>text/plain attachment: patch </UL> -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: application/octet-stream Size: 591 bytes Desc: not available Url :

[Oops. Sent this to the wrong list.] Kenneth already appears to have committed a byte order fix for the WAV output driver. Attached is a patch to fix byte order in the OSS and ALSA drivers. The other output drivers seem to just use the native byte order (which libvorbisfile uses). As I do not have anything but Linux systems on Intel hardware at my disposal, I would really appreciate it if

Hi! Is this the correct place to ask about libao? I'm having a bit of trouble getting libao-0.8.4 running on OS/X 10.2.8 - libao builds fine but dlopen'ing the macosx plugin keeps failing with undefined symbols (from the CoreAudio framework it appears). Steven Schultz --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project

Xiph.Org is pleased to announce the release of libao version 1.1.0. This release consists of minor functionality improvements and several important bugfixes. The 1.1.0 API/ABI is fully backwards compatible with 1.0.0; All users of libao are encouraged to upgrade to the 1.1.0 release. Bugfixes in this release include: * Fix Mac OS X AUHAL support to properly handle suspend/wakeup,

On Thu, May 24, 2007 at 12:46:41PM +0200, BeN [F1233 121D3R] wrote: > I had successfully accessed the svn repository. I had commit everything > for a new release including the new win32 driver. I need is to know if > there is some kind of official way for xiph release ? So release packages go in https://svn.xiph.org/releases/ao/ Update the MD5SUMS and SHA1SUMS checksum files as the

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

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

I am having trouble configuring libao for cross compiling for an arm target on an x86 host. I try ./confgure --target=arm but, get the following error configure: error: can not run test program while cross compiling and it ends without finishing. How can I configure for arm development on an x86 system? tj