similar to: libao.spec

Is anyone looking at bugs.xiph.org? There are several bugs that are easy to fix (bugs 2,3,4,7, and 9) or have already been fixed (Bugs 5 and 6). Bug 8 I think is a Multi/single -threaded issue and Bug 15 is a problem with ogg123, not with libao. Some of these bugs are pretty old. Is anyone going to fix them? I'd do it, but I don't have CVS write access. Aaron Plattner <HR

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

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

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

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

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

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

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

Seeing that the au driver has been committed, I wonder if there is a particular reason my sun driver (native NetBSD/OpenBSD/Solaris sound support) never has been added. Relevant files attached. Again. -- Christian "naddy" Weisgerber naddy@mips.inka.de <HR NOSHADE> <UL> <LI>text/plain attachment: ao.patch </UL> -------------- next

The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: log.txt

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

[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

Okay, here's the new version of the raw output driver. It now allows output in native, little-endian, and big-endian (to make the .cdr people happy) order. I've now had two different people request this driver, so I know there is some demand for it. Below are the patching directions cut-and-pasted from the original email: To add the driver: 1) Copy ao_raw.c into ao/src/

I've attached a patch for the IRIX driver that should make it actually compile and work! The driver definitely won't work without the endian fix I posted 30 min ago, so make both have been applied before you complain to me. :) --- Stan Seibert <HR NOSHADE> <UL> <LI>TEXT/PLAIN attachment: irix.patch </UL> -------------- next part -------------- A non-text

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

I was looking at the Freeamp stuff and I looked at their RDF metadata stream spec. (http://www.musicbrainz.org/MM). I noticed on that page it says, "Furthermore, this format will hopefully be used by the Open Source audio codec Vorbis to store audio/video metadata with the audio/video tracks." Is this the metadata format planned for Vorbis? If so, how would it be embedded in the .ogg?

I noticed that ogg123 still has its problem opening multiple devices. Here´s a patch that fixes that. I made it considerably easier by changing append_device to return the new device struct instead of the head of the list each time. This way, the options for the device are modified with the structure already in the list, instead of building up options before doing so. I also moved an fprintf