similar to: Buffer problems

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

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

The problem I noted earlier about segfaulting at the end of playback and the problem about mangled wav files have the same cause. The playback buffer in ogg123 is freed without checking if it has even been allocated. Ken probably didn't notice because he was using a buffer (which is optional). :) A patch for ogg123.c is attached. (Probably takes the record for the smallest patch

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

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

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

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

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

Yes it is 2:42 PM, and yes I stayed up finishing ogg123 buffering. But I'm not committing it because I'm really tired now and I'm very, very, very suprised it even worked (the first time!). I see why people use semaphores; I thought select() and a signal could work just as well. The select times out every second, so it keeps the buffer relatively filled without eating up loads of CPU.

Hello ppl! I asked some time ago how about adding the option to control ogg123 interactively from command line, similar to mpg123. So I got fed up waiting and added it myself today. The code initially comes from mpg123, I already adapted it to work with aviplay and vlc so it's proven and shouldn't introduce many problems. The only problems I see now: - in order to compile ogg123 now

Merry Christmas, Vorbis folks! Here's bunches of cleanups to ogg123. I haven't changed much in the raw code, mostly a few places with broken implementations. I'm also trying to cleanup some places where we assume too much, because ogg123 might eventually be able to safely run suid (or sgid) (to access the audio devices). I think the next thing I'll attack is the buffering. --

Hello all, I'm going away on vacation again, so no work on ogg123 from me for a week. This is disappointing because I would have liked to be able to get my branch work into shape for an rc3 release, but there's no way I'll be able to get it done by then. That said, since I have moved the buffer code to pthreads and added libcurl streaming, the new code needs a lot of testing,

I was just about to commit a big buffer overhaul when I realized that it would probably break a lot of stuff and I'd get yelled at, so it's in the kcarnold_work tag (or will be momentarily...). Have a look at it, try to make it deadlock. If I messed up the CVS tagging, also let me know -- I know only enough about CVS to be dangerous :) This should also reduce CPU usage noticably. The

Hi people! I think it would be cool if ogg123 had a mode in which you could conrol it with stdin. pausing, quitting/stopping and seeking would be enough imho. mpg123 already has something like this (I think -e). I'd do it myself but I'm busy. Shouldn't take much time. Bye, Peter Surda (Shurdeek) <surda@bigfoot.com>, ICQ 10236103, +4369910964300 -- The dark ages

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

A small patch (attached) to the ogg123 source (dec 15 nightly build from CVS) that implements ranged playback a la: ogg123 -r 12:10-13:00 file.ogg to playback 12m:10s-13m:00s fragment from the file.ogg soundfile. Usage: ogg123 -r hours:minutes:seconds.fraction-hours:minutes:seconds.fraction anything can be pretty much omitted (within reason) [although it does not support hh:mm:ss.hh- ]

I have been very busy for the last few months with school, during which time Jack and others have taken over ogg123. Now I have a week off for Christmas ("Winter Break" for the politically correct), so I have some free time. And what better place to spend it than at my computer? (heh) So anyway I decided to take a look at (what's left of) ogg123. Yuck. Eeew. Horror. The good news:

Hi all, Ralph Giles pointed me here for my ogg123 patch. I had mail'd the authors (listed in ogg123.1) and Xiph about this but I recieved no response - and here is probably a better place for it. I decided to work on ogg123 when I wanted to work on Ogg Vorbis support in Nautilus (if you don't know what it is, it is the new Graphical File Manager for GNOME). Currently Nautilus has mp3

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've been doing a ton of work on my branch. CVS log tells a little of the story. For one, the buffer is nearly completely rewriten. That means deadlock cases. I've caught a few, but I need help. Anyone who's computer is faster or slower than my own or perhaps schedules things differently (i.e. everyone) please hit the ogg123 on my branch (kcarnold_work) with the strangest conditions