Displaying 20 results from an estimated 200 matches similar to: "libao: alsa plugin won't compile"
2001 Nov 09
1
libao - patch for ALSA (0.5.x) plugin
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
2000 Sep 05
1
[kcarnold@xiph.org: [xiph-cvs] cvs commit: vorbis/vorbis-tools/libao ao_alsa.c ao_oss.c audio_out.c audio_out.h]
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
2001 Feb 27
1
libao compilation difficulty
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
2000 Aug 12
1
libao patch: Minor clean up / Byte-order proposal
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
2013 Jan 17
1
libao problem (Re: [alsa-devel] No dmix/dsnoop on Intel ICH4/5 by default?)
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
2001 Nov 09
0
libao - new ao_alsa.c patch
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
2001 Jun 12
3
libao and recent ALSA builds
I had a go at building libao-0.6.0 and it barfed on the alsa output part,
complaining that snd_pcm_channel_status_t is undeclared - probably due to me
running alsa 0.9.0 beta4. So the question is, should I try and beat the
configure stuff into letting me disable alsa support and just use OSS, or
would I be better off trying my luck with the nightly builds?
And if so, can I get away with just
2001 Jun 12
3
libao and recent ALSA builds
I had a go at building libao-0.6.0 and it barfed on the alsa output part,
complaining that snd_pcm_channel_status_t is undeclared - probably due to me
running alsa 0.9.0 beta4. So the question is, should I try and beat the
configure stuff into letting me disable alsa support and just use OSS, or
would I be better off trying my luck with the nightly builds?
And if so, can I get away with just
2004 Oct 22
0
libao-0.8.5 patch
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
2001 Aug 30
1
alsa 0.9 support
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
2001 Sep 12
0
libao.spec
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 :
2000 Aug 07
1
libao patch: Endian-ness fix
[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
2003 Oct 25
0
libao-0.8.4 on OS/X
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
2011 Feb 22
0
libao 1.1.0 released
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,
2007 May 24
2
Re: libao ready for release
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
2007 May 23
0
libao todos
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
2000 Sep 02
1
libao endian fix (attempt 2)
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
2002 Apr 10
1
libao: FreeBSD OSS patchlet
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
2004 Sep 09
0
Builf libao for arm on x86
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
2001 Nov 05
0
[vorbis] libao on OS X
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