similar to: Couple of fixes for ogg123

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

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

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

There seem to be a couple of problems with the buffering code just checked in: 1. buffer_shutdown(NULL) is called when the bitrate changes and you're not using a buffer. 2. The buffer is not used for anything but the first file. 3. The buffer isn't explicitly closed when playback is finished, sometimes leaving an ogg123 process sitting sucking up 100% CPU time. Here's a patch that

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:

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

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

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

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

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,

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

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

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 am using the ogg123 player through an emacs interface to mpg123 I patched up to support ogg123 (shameless plug, see http://asf.void.at/emacs.html). This has a problem (apart from it being emacs, which might offend some of you (-:): The verbose output from ogg123 is collected and inserted into a temporary buffer. This works when emacs has nothing else to do, but fails when it blocks. Then,

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

MoiN I thought you should be able to set system wide defaults for the output device of ogg123. The following patch will look for /etc/ogg123rc, if no ~/.ogg123rc can be found. So the user can still override the system defaults, but not every user needs to have an ~/.ogg123rc file. Ingo -- 16 Hard coded constant for amount of room allowed for

Linking libvorbis.a and vorbisfile.a in the opposite order corrected a linker error in ogg123. (dont ask me why.. Im not a genius - in fact, you could ask Monty...) I am just about to commit the fix as follows: vorbis-tools/Makefile.in : -LIBS=@LIBS@ ../lib/libvorbis.a ../lib/vorbisfile.a +LIBS=@LIBS@ ../lib/vorbisfile.a ../lib/libvorbis.a Michael Beattie

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.