similar to: Future libao refinements

Hi there. Sorry I may be a little off topics with this mail but I have already written to the official libao maintainer (volsung@xiph.org) and he is the one who suggest me to write here. As I did not see any more suitable mailing list @xiph.org here I am. My point is that I have recently written a win32 driver for the libao and I would be glad to see this contribution include to the official

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

Ack! I hate it when I have to fix my own crappy code. :) I present the endian fix for the wav output driver. Apply it along with the endian-fix.patch I sent earlier and things should be okay. Hopefully. Kenneth can check me on this with his PowerPC. --- Stan Seibert --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe

> Does anyone object to the attached patches? The main change is to be able > to call > > ao_append_option(&opts, "key", "value"); > I'm all for this one. The original form of the function is really poor design on my part. I hope this gets committed. --- Stan Seibert --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project

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

Ok, this patch replaces the old patch I sent, and it does a bit more. For one, it sorts the linked list of drivers based on the priority values, highest valued ones coming first. That allows the _find_default_driver_id code to stop looping (break) immediately when it finds a driver that works, because it already knows it's the working driver with the highest priority (what it normally

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

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

Okay, before I submit my patch to make libao produce sorta-streamable wav files, I want to know what these partial wav files do to various players. I've posted two sample wav files on my webserver: http://volsung.dhcp.asu.edu/~stan/infinite.wav http://volsung.dhcp.asu.edu/~stan/zero.wav The first uses a riff and data length of 0xFFFFFFFF (approximately infinite) and second uses a riff and

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've been kind of busy lately, but I wanted to see what's up with ao after the build change. I was able to check out the vorbis module, but when I tried to check out the ao module I saw this: [stan@volsung vorbis]$ cvs -d:pserver:anoncvs@cvs.xiph.org:/usr/local/cvsroot co -r branch_postbeta2 ao cvs server: Updating ao cvs server: Updating ao/doc cvs server: Updating ao/include cvs

Hi folks, I'd like to remind people with write access on the CVS mainline not to put any tools/libs/patches into the main build that are not portable... I'm getting not-very-pretty flames from NetBSD folks because libao fails to *configure* under NetBSD (let alone build), thus breaking building the build for the entire CVS mainline. Specifically: >checking size of int...

After applying SP2 to our Windows Server 2003 domain controller, we are unable to access Samba Version 3.0.4 shared user diectories.? ? Access fails with these message:? unable to validate password for user USER in domain DOMAIN to Domain controller \\DOODAH. Error was NT_STATUS_ACCESS_DENIED. If no one has experienced and resolved this, how do I debug this situation? ? Thanks, in advance, for

I am about to commit HTTP streaming code for ogg123. This has no relation to the discussion about "real" steaming Ogg; it just downloads and plays at the same time. But unless you have a direct T3 connection, it'll almost definately break up quite frequently. Solution? Buffer. But I have other things to work on for the rest of the day... Any screaming objections? This has been

Hi, I'm whining again about the inclusion of the raw driver in libao. Can someone please commit the patch I posted in message: http://www.xiph.org/archives/vorbis-dev/0098.html (which will turn into http://www.xiph.org/archives/vorbis-dev/200103/0098.html in 4 days.) I've got people who want it included asking me what's the hold up. --- Stan Seibert --- >8 ---- List archives:

I was looking back through the libao source after some time away from it and I noticed the addition of a plugin_get_latency() function to the plugin API. What is the purpose of this function and what was the motivation for adding it? --- Stan Seibert --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a

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.

I'm reordering the code in ao_wav.c that writes wav files to prevent the problem we had earlier. If ogg123 was improperly terminated (Segfault, kill -9, etc.), the output wav file was not even recognizable because the header was totally blank. I have found that at the start of playback (from libao's perspective), I know all of the wav header info except two things: 1) The length of the