similar to: ogg123 compile error fix

I'm updating my vorbis rpm spec file, and when I try to do "make -C vorbis-tools ogg123", due to rpm's build environment, I get lots of: gcc ogg123.o -o ogg123 -lm ../lib/libvorbis.a ../lib/vorbisfile.a ../lib/vorbisfile.a(vorbisfile.o): In function `_get_prev_page': vorbisfile.o(.text+0x54): undefined reference to `ogg_sync_reset' vorbisfile.o(.text+0xa9): undefined

Hey. Last night I hacked grip so that it'd allow me to use vorbize and comments with grip. It's very ugly because grip'd need a bit of rearrangement in order to facilitate the way the vorbis comments work (that is, the comments are not added in after the encoded file has been written). Any one who wants to use it should patch grip-2.94 (http://www.nostatic.org/grip), and make sure you

[Apologies -- I've been offline for over a month, and so haven't sent this patch in a timely manner. Also, I'm still not up-to- speed and do not yet have the latest source downloaded, so this patch might be unnecessary anyway. And the list archives appear to not be updated since I started sending patches, so I haven't seen any feedback yet, if any. As usual, don't reply to

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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.

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