similar to: Bugzilla?

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

I just used ogg123 to play back a file encoded from a 22.5 KHz WAV, and it played twice too fast. Looking at the source, it seems that the sampling rate and number of channels are hard-coded into it. What´s the best way of fixing this? I quickly hacked together something that closes and reopens the devices before each file (diff attached). Is there a better solution? Aaron Plattner <HR

Here's yet another ogg123 patch that: 1) Adds a command-line parameter "--prebuffer n" or "-p n" that decodes "n" chunks into the buffer before even forking off the writer thread. 2) Moves the buffer_shutdown call in ogg123.c to its proper place. 3) Doesn't use signals ;) This way, the default behavior is to start playing immediately, while allowing the user

I know you're tired of hearing me complain about ogg123, but this time I noticed that some of the error messages are a bit inconsistant. Also, I noticed that some things (like "Error connecting to server") are fatal errors that kill ogg123, while I think they should simply go on to the next file in the list like "input not an Ogg Vorbis audio stream" does. Another problem

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 tried to use ogg123 -b to play from a slow HTTP server, and I realized that ogg123 starts to play immediately even if the buffer isn't full, so if it can't read the ogg fast enough it skips, even with a huge buffer. Is this the way it's supposed to work? It seems to me like the buffer shouldn't start playing until it's full. Am I misunderstanding the purpose of having a

Hi! The version of ogg123 (or perhaps libao I think) says that the wav output can't go to STDOUT. Is this feature supported already in the current CVS? Bye, Peter Surda (Shurdeek) <surda@bigfoot.com>, ICQ 10236103, +436505122023 -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. <HR NOSHADE> <UL> <LI>application/pgp-signature attachment: stored

Looking at it, I think this patch is actually better than the one I sent before, mainly because it keeps from adding a bunch of weird parameters to functions at the expense of a single global variable (globals... ick). Aaron Plattner <HR NOSHADE> <UL> <LI>text/plain attachment: ogg123.diff.2 </UL> -------------- next part -------------- A non-text attachment was

I installed fink and now I have the /sw/lib, however that didn't fix my problem. I went as far as to take out the - Ddlsym=dlsym_auto_underscore out of the configuration files. Now however the libao package won't build at all and yips about this: [ukiel:/MP3/OGG/libao-0.8.6] wind% make Making all in src Making all in plugins Making all in oss make[3]: Nothing to be done for

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

happy new year. a day off is a day to pick up a new project, so I wrestled my way through making ogg vorbis work on macosx. first, libao (not entirely a proper patch, but 2 source file diffs and a diff of a configure'd Makefile to one that works.): http://bolson.org/pub/libao-0.8.2-diff.tar.gz libogg and libvorbis compiled without incident. vorbis-tools were more complicated. I think

happy new year. a day off is a day to pick up a new project, so I wrestled my way through making ogg vorbis work on macosx. first, libao (not entirely a proper patch, but 2 source file diffs and a diff of a configure'd Makefile to one that works.): http://bolson.org/pub/libao-0.8.2-diff.tar.gz libogg and libvorbis compiled without incident. vorbis-tools were more complicated. I think

Hello, I built the entire Vorbis kit on my PowerMac G4 running OSX 10.4.6. I'm having problems however doing anything with the libao package. Any time I try to use the library to link it errors out with the following message: /usr/bin/ld: Undefined symbols: _dlsym_auto_underscore collect2: ld returned 1 exit status If I try to run the ogg123 application I get this:

Hi All, For my new file (and thus mp3) server I've decided to switch completely to Ogg Vorbis. This means having to reencode ~30GB worth of 128Kb MP3's, but i figured that it would all be worth the effort. So I downloaded the sources for libogg, libvorbis and vorbis-tools and fired up my trusty old compiler. libogg and libvorbis built and installed like a charm. Not so for

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 :

Here's an updated set of patches to fix some problems with the build process. These patches are relevant to the CVS head as of 30 Dec 2000. Overview: - Patch 1: Allowing the user to set CFLAGS/LDFLAGS before running configure in all four modules. All these patches do is essentially: cflags_save="$CFLAGS" ldflags_save="$LDFLAGS" # ... stuff to

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

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

Xiph.Org announces the release of libao-1.0.0, libvorbis-1.3.1 and vorbis-tools-1.4.0. This is a coordinated update of the audio libraries and tools to deploy improved surround-sound support across the libraries and toolchain. libao improvements: - AO returned to active development - Added surround channel mapping API and capability - Updated all drivers on modern installs - New config file

Xiph.Org announces the release of libao-1.0.0, libvorbis-1.3.1 and vorbis-tools-1.4.0. This is a coordinated update of the audio libraries and tools to deploy improved surround-sound support across the libraries and toolchain. libao improvements: - AO returned to active development - Added surround channel mapping API and capability - Updated all drivers on modern installs - New config file