similar to: libao: Cross-platform audio for ogg123

------- Forwarded Message Return-Path: owner-vorbis-dev@xiph.org Delivery-Date: Mon Jul 10 01:38:16 2000 Delivered-To: xiphmont@localhost.xiph.org Received: from localhost (localhost [127.0.0.1]) by bloopfish.xiph.org (Postfix) with ESMTP id 1A4A48882F for <xiphmont@localhost>; Mon, 10 Jul 2000 01:38:15 -0700 (PDT) Delivered-To: xiphmont@xiph.org Received: from xiph.org

A branch of ogg123 is in CVS now which you can use to test the libao prerelease. Because of the way I did the branch, checkout is a little screwy (as Monty once said: "Know thy tools!"). (I am assuming here that you already have CVSROOT set correctly.) cvs co vorbis-tools # Notice there is no tag here! cd vorbis-tools/ogg123 cvs update -r volsung_20010721 Or, if you already have

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

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

The output of ogg123 -h and the man page should be updated to document the devices currently available through libao. (Those extraneous carriage returns in ogg123.1 suck, btw.) --- ogg123/ogg123.1.orig Sat Jun 30 14:48:43 2001 +++ ogg123/ogg123.1 Sat Jun 30 15:02:46 2001 @@ -76,7 +76,7 @@ written to output overhead. .IP oss -Open Sound System driver for Linux and {Net,Free,Open}BSD. +Open

libao now has dynamic plugin support. ogg123 now builds with libao. they are both happy and smiley. please try it out, this should cease the bitching :) also, there is no more default device in ao. my opinion is that the calling app should keep track of default device, probably in an rc file or something. i'm open to suggestions. also, the solaris and the irix driver don't currently

This patch fixes three problems with the current configure script: 1. Manual exclusion of drivers: Now you will be able to force drivers NOT to be compiled, even if they are detected. This was specifically requested with so that ALSA could be disabled. 2. Selecting the default device: Now you can override the default driver chosen by the script with your own preference. Again, this enhancement

Just so people know what I'm working on (between physics assignments), here's a quick list of what's currently in the pipeline: * I received an IRIX patch which I am very excited about. I'll be submitting that shortly. * A month ago another user sent me a very small patch that improved ALSA performance on his machine. I don't understand what it does exactly, and would

Now that libao is integrated with ogg123, I was hoping that people with platforms different than mine could test the operation of ogg123+libao. I would really appreciate it if people testing ogg123 could send me email (privately, NOT to the list) with the following information: Hardware Platform: (Intel x86, MIPS, PowerPC, etc.) Operating System: (Linux, NetBSD, IRIX, etc.) Other sound

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

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

Dear developers, I patched ogg123 so that it can use esd (only local socket currently). In order to compile you need to copy esd.h from the esound-devel to the vorbis-tools directory. Usage: ogg123 -e -d something file.ogg the "something" is not important I don't intend to maintain this patch, but perhaps somebody could make it more nicer and incorporate it in the

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

(Hi, this isn't exactly vorbis related, but I figure most of you use libao with ogg123.) Libao 0.8.4 has been released today. It's mostly a bug-fix release, but has some new drivers too! We've also moved libao to it's own website: http://www.xiph.org/ao/ Source, RPMS for RedHat 9, and Debian packages are there. Enjoy! Changelog: * Incorporated OS X patches from the Fink

Ironically, just as we have a big thread on cross compatabilty somehow the configure for vorbis on BeOS stops with the message i586-pc-beos is not currently supported by libao configure: error: ./configure failed for vorbis-tools/libao it just needs the 'exit 1' taking out of the libao configure script on line 1313 or a proper fix from the main configure script; Dave --- >8 ----

I saw that libao has a NAS plugin and wanted to try it out, especially with ogg123. However, I had/have several problems. My platform is Solaris 9/SPARC 12/02, NAS 1.6, libao 0.8.5, curl 7.10.8, libogg 1.1, libvorbis 1.0.1, and vorbis-tools 1.0.1. PROBLEM ONE: ------------ I had to specify LDFLAGS="-lXt -lsocket -lm" before running ./configure with "--enable-nas" in order

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

A playback of a mono vorbis track on a system using the i810 audio driver via ogg123 results in a double speed playback (chipmunk sound). It seems that this chipset doesn't support mono and while xmms seems to compensate for it, ogg123 doesn't I have a bugzilla report at redhat.com filed on this with more details https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90433 Regards, Yusuf

Again, Hi All, Thanks for your replies. I probably should've mentioned that I'm not subscribed to the list but I found your answers on the archives. I just wanted to go on record and mention that I do in fact have all the original CD's and that by re-encoding I meant repeating the entire process of ripping the original CD's (with cdparanoia (of course ;)) and then encoding them