similar to: ogg123 / Solaris

A feature request that sounds reasonable and a bug report. ----- Forwarded message from Frank Klemm <pfk@fuchs.offl.uni-jena.de> ----- Delivery-Date: Sat Jan 6 06:35:21 2001 Date: Sat, 6 Jan 2001 15:26:43 +0100 From: Frank Klemm <pfk@fuchs.offl.uni-jena.de> To: xiphmont@xiph.org Subject: ogg123 X-Mailer: Mutt 1.0.1i For ogg123 I need the following feature: - Decode one .ogg file

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 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 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've made something. It wasn't done in exactly 10 minutes because I had to >translate the headers to Pascal, but the GUI was certainly done in about >30 minutes. [...] >http://www.xs4all.nl/~walterln/vorbis_play_17apr.zip (259K) would it be hard to add streaming support? a small and simple player, which could also stream vorbis would be cool. also a command line tool for

I finally managed to compile ogg123 under MacOS X, after creating a PB project for it. Rillian, do you want to include the PB project in cvs? (it needs a LOT of polishing, though). ---------- Ogg123 from PACKAGE VERSION by Kenneth Arnold <kcarnold@arnoldnet.net> and others Usage: ogg123 [<options>] <input file> ... -h, --help this help -V, --version display

Every time ogg123 -bXXX is run, it creates another shared memory segment but fails to destroy it on exit. Thus an increasing number of shm segments keeps piling up and eat all the (often rather limited amount of) available shared memory. The patch below corrects this and also fixes the bizarre abuse of stat() permission bits for shmget(). On systems that support it, I'd very much like to

The patch below adds: - acinclude.m4: A new macro A_FUNC_SMMAP to check that sharing pages through mmap() works. This is taken from Joerg Schilling's star. - configure.in: A_FUNC_SMMAP - ogg123/buffer.c: If we have a working mmap(), use it to create a region of shared memory instead of using System V IPC. Works on BSD. Should also work on SVR4 and offspring (Solaris), and Linux.

Hi all, Browsing through the bug database, I was able to reproduce #14. Briefly, when I run, for example: ogg123 -b 8000 test1.ogg test2.ogg test1.ogg [...] where test1.ogg and test2.ogg have different bitrates or numbers of channels (that is important), ogg123's memory usage continuously increases as each new song is played. I think I've tracked down the bug to the use of

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

Hi, I released Squelch 1.0beta9. It's a multi-platform Ogg Vorbis player, if you haven't heard of it. [1] Find it here: http://www.geoid.clara.net/rik/squelch.html Differences from beta8: * Vorbis comment editor ! [2] * More intelligent re-initialisation of output driver. * Stupid bugs in auto-update of master track list resolved. * Some bugs fixed, some more introduced ;) In theory,

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'm reordering the code in ao_wav.c that writes wav files to prevent the problem we had earlier. If ogg123 was improperly terminated (Segfault, kill -9, etc.), the output wav file was not even recognizable because the header was totally blank. I have found that at the start of playback (from libao's perspective), I know all of the wav header info except two things: 1) The length of the

I don't think that the getopt_long() situation is handled correctly in the vorbis-tools module. Here's my take (comments welcome!). ----- This applies to oggenc, ogg123, and vorbiscomment. See http://www.xiph.org/archives/vorbis-dev/200012/0359.html for background and prior discussion on this issue. There are 2 issues: 1. Summary: getopt() is a POSIX function. It will already be on

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've noticed that throughout the code there's quite a variety of formatting styles, especially the size of TAB characters (4 or 8) and size of indents (2 or 4). Is there any agreed standard for new code now? Oh, and whoever wrote the ogg code must get an electric shock every time he hits the spacebar. It's full of spaceless lines like

I am about to commit HTTP streaming code for ogg123. This has no relation to the discussion about "real" steaming Ogg; it just downloads and plays at the same time. But unless you have a direct T3 connection, it'll almost definately break up quite frequently. Solution? Buffer. But I have other things to work on for the rest of the day... Any screaming objections? This has been

I notice that the user is not able to set their own CFLAGS or LDFLAGS in the ao, ogg, vorbis, and voribs-tools projects. Is there a reason for this? I understand the fact that these modules want to set extremely high optimization flags, and that most users won't know what these are offhand, but there are times when it is useful for the user to specify their own CFLAGS/LDFLAGS. For example,

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

1.0rc3, OpenBSD/i386 & FreeBSD/alpha. ogg123 segfaults after playing a file. This will not happen if I specify multiple songs and skip (^C) to the next one. Seems to be independent of buffering (-b) and output device (oss, esd, raw). -- Christian "naddy" Weisgerber naddy@mips.inka.de --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg