similar to: ogg123 running under MacOS X

While trying to compile libao 0.8.0 under OS X 10.1, I got the following problems: > [localhost:ecc/Sources/libao-0.8.0] root# ./configure > creating cache ./config.cache > checking for a BSD compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking whether make sets ${MAKE}... yes > checking for working aclocal... found >

Hello, I built the entire Vorbis kit on my PowerMac G4 running OSX 10.4.6. I'm having problems however doing anything with the libao package. Any time I try to use the library to link it errors out with the following message: /usr/bin/ld: Undefined symbols: _dlsym_auto_underscore collect2: ld returned 1 exit status If I try to run the ogg123 application I get this:

I installed fink and now I have the /sw/lib, however that didn't fix my problem. I went as far as to take out the - Ddlsym=dlsym_auto_underscore out of the configuration files. Now however the libao package won't build at all and yips about this: [ukiel:/MP3/OGG/libao-0.8.6] wind% make Making all in src Making all in plugins Making all in oss make[3]: Nothing to be done for

I'm having several problems with ogg123 on a FreeBSD-STABLE machine. In each case, ogg123 dumps core complaining about a bus error. 1) ogg123 plays all files at what seems like twice the correct speed. When given a SIGINT, ogg123 dumps core. This is using the program defaults, including the OSS driver. Here's a backtrace from gdb: Core was generated by `ogg123'. Program

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

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

A playback of a mono vorbis track on a system using the i810 audio driver via ogg123 results in a double speed playback (chipmunk sound). It seems that this chipset doesn't support mono and while xmms seems to compensate for it, ogg123 doesn't I have a bugzilla report at redhat.com filed on this with more details https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90433 Regards, Yusuf

Ok, I managed to compile the Ogg and Vorbis libs. Then, after modifying the file audio_out.c as follows: original: #include <dlfcn.h> modified: #include <win32/include/dlfcn.h> I was able to (finally!) compile libao. Then I tried to compile the module vorbis-tools, but uninvited problems came to my party. [...] > /usr/bin/ld: multiple definitions of symbol _getopt >

Hi, I've written an ao plugin for aRts, the soundserver that comes with KDE. Any chance of including this in the ao distribution ? Pretty please ? :) Sources and patches attached. This is a very simple plugin because it uses the easy-to-use 'artsc' C wrapper that aRts installs. configure.in.diff is for ao/configure.in Makefile.am.diff is for ao/src/plugins/Makefile.am Makefile.am

hi, i am trying to load vorbis tool on to my arm board EDB9302 , till now i have cross compiled libao, libogg, libvorbis, flac, speex and vorbis tool. when i run the command line arm-linux-ogg123 with some sample ogg format file on my arm board it gave *"Could not load default driver and no driver specified in config file : Exiting"* , please help me to over come this error.

Here are some of my notes with building and using vorbis-tools-1.0beta4 under Debian Linux 2.2. 1) building libao: make[3]: Leaving directory `/home/jeremy/src/ogg/libao-0.6.0/src/plugins/alsa' Making all in arts make[3]: Entering directory `/home/jeremy/src/ogg/libao-0.6.0/src/plugins/arts' /bin/sh ../../../libtool --mode=compile gcc -DPACKAGE=\"libao\"

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

On Monday, November 5, 2001, at 12:54 AM, dongoodman wrote: > ok, I haven't tried compiling your vorbis-tools PB project, as I still > can' > t get vorbis.framework to like me. test linkings still complain about > too many main()'s...and in fact, quite a lot of the c files in the > vorbis source have main()'s in them...how very odd. > I'm sorry, I have

Here is patch with manpages for ogg123(1), mp3tovorbis(1) and vorbize(1). Manpages are in pod format, because it is the most readable man source, and are compiled by pod2man. all and clean for man/ work. Install and uninstall for man/ seem to work. Manpages are GPLed of course. <HR NOSHADE> <UL> <LI>text/plain attachment: manpages.diff </UL> -------------- next part

I've run into two problems with ogg123 that appears only when using the esound driver. Case 1: pops in output Audible pops, especially at low volume. Original mp3 file does not exhibit these pops, nor does oss output from ogg123, nor does esd output from mpg123. Things ruled out: disk speed - the HD is ATA/33 with DMA on. It's a single user

Speaking of ogg123 fixes and Solaris... <getopt.h> doesn't appear to exist in Solaris. Hence, ogg123 won't compile on Solaris at all (even with gcc). I originally mentioned this back in November (http://www.xiph.org/archives/vorbis-dev/200011/0291.html). Can this be fixed? {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness

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

ogg123 seems to have a issue when streaming for long peroids of time. If I have ogg123 up connected to a streaming server for more than 3.5 hours it begins to stutter or add blocks of static. I've verifed this with 2 different soundcards in both alsa oss emulation and regular oss. It's 100% repeatable for me. It does not happen with xmms using libvorbis as the output plugin so it

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