similar to: Xiph.Org releases libao 1.0.0, libVorbis 1.3.1, and vorbis-tools 1.4.0

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 >

I've tweaked Tim Wood's Mac OS X DP4 patches so they compile and run reasonably well on OS X DP4 and added a couple minor tweaks of my own. I've placed diffs from the head revision in cvs at my web site: <http://www.gizzywump.com/vorbis-macosx-diffs> This includes a new file at vorbis-tools/libao/ao_macosx.c, which is in the diff. Note that "patch" doesn't seem

Hi! There are some little inconvenience in libao-0.8.5. - The biggest is may that: the documentation and the header file declare the ao_file_extension function, which give a hint for the file extension where the device is realy a sound file. This function is missing. -An other: the alsa 0.5 and the alsa 0.9+ drivers short name. It will be better if the alsa 0.5's name will be alsa05 and the

Hi folks, I'd like to remind people with write access on the CVS mainline not to put any tools/libs/patches into the main build that are not portable... I'm getting not-very-pretty flames from NetBSD folks because libao fails to *configure* under NetBSD (let alone build), thus breaking building the build for the entire CVS mainline. Specifically: >checking size of int...

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:

Why has ao been changed so that there are now two open() functions ? IMHO the original ao_open() was fine - if you wanted to set the filename for output, you could add an option via ao_append_option and if you wanted to avoid overwriting an existing file, you could stat() it yourself. Having ao_open_live() and ao_open_file() just makes more work for the user of the library for no gain, AFAICT.

Why has ao been changed so that there are now two open() functions ? IMHO the original ao_open() was fine - if you wanted to set the filename for output, you could add an option via ao_append_option and if you wanted to avoid overwriting an existing file, you could stat() it yourself. Having ao_open_live() and ao_open_file() just makes more work for the user of the library for no gain, AFAICT.

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

Hi All, For my new file (and thus mp3) server I've decided to switch completely to Ogg Vorbis. This means having to reencode ~30GB worth of 128Kb MP3's, but i figured that it would all be worth the effort. So I downloaded the sources for libogg, libvorbis and vorbis-tools and fired up my trusty old compiler. libogg and libvorbis built and installed like a charm. Not so for

Hi there. Sorry I may be a little off topics with this mail but I have already written to the official libao maintainer (volsung@xiph.org) and he is the one who suggest me to write here. As I did not see any more suitable mailing list @xiph.org here I am. My point is that I have recently written a win32 driver for the libao and I would be glad to see this contribution include to the official

Rather than using libtool to build its sets, the ao.m4 in beta3 is hard coding '-ldl': AO_LIBS="$AO_LIBS -lao -ldl" Not all systems have a dl library. For now, I can obviously just remove it and keep working on stuff, but what would be a suitable patch that would get accepted to be committed? Should I just check the current build target and set AO_LIBS differently on my

Hi, I have downloaded the following files libao-0.6.0.tar.gz libogg-1.0beta4.tar.gz libvorbis-1.0beta4.tar.gz vorbis-tools-1.0beta4.tar.gz as said from the download section. But I'm at a loss to what do after that. I don't have much experience/knowledge in compiling etc, but I still want to try out ogg. (I downloaded the source coz I have an OpenBSD machine, and there was no

I hope I'm not being an idiot, but I'm attempting to install vorbis-1.0 RPMs on a few redhat machines and failing horribly. I'm in dependency hell. For starters, libao-0.8.3-1 requires libasound.so.2 (an alsa library?) which does not seem to be available in any recent redhat releases. Then vorbis-tools wants libcurl.so.2, which makes redhat 7.2 machines choke. Worst of all is

happy new year. a day off is a day to pick up a new project, so I wrestled my way through making ogg vorbis work on macosx. first, libao (not entirely a proper patch, but 2 source file diffs and a diff of a configure'd Makefile to one that works.): http://bolson.org/pub/libao-0.8.2-diff.tar.gz libogg and libvorbis compiled without incident. vorbis-tools were more complicated. I think

happy new year. a day off is a day to pick up a new project, so I wrestled my way through making ogg vorbis work on macosx. first, libao (not entirely a proper patch, but 2 source file diffs and a diff of a configure'd Makefile to one that works.): http://bolson.org/pub/libao-0.8.2-diff.tar.gz libogg and libvorbis compiled without incident. vorbis-tools were more complicated. I think

Form the vorbis.com homepage: "Ogg Vorbis does not compromise quality for freedom. Its stunning quality is coupled with aggressive features like fast bitrate scaling, surround channels, and fast sample-granularity seek and decode." This makes me wonder... -- What is "fast bitrate scaling"? -- I've never seen anything in the source supporting surround channels. -- I

It seems that the configure script in CVS does not check the CFLAGS environment variable at all. Indeed, on line 121 of configure.in, CFLAGS is explicitly set to be blank. Is this done for a reason? I see that several sets of CFLAGS are passed into the Makefiles by configure based upon specific architecture/compiler combinations -- perhaps this is the reason...? I ask because users may wish to

In January I submitted a new "raw" output driver for libao that lets you write the audio samples directly to a file without any headers or anything else. It never got committed. Is it too late in the beta cycle to add it? I've been contacted by an author of a CD recording application whose problem could be solved by the inclusion of the raw driver. I need to make a change to the

I had a go at building libao-0.6.0 and it barfed on the alsa output part, complaining that snd_pcm_channel_status_t is undeclared - probably due to me running alsa 0.9.0 beta4. So the question is, should I try and beat the configure stuff into letting me disable alsa support and just use OSS, or would I be better off trying my luck with the nightly builds? And if so, can I get away with just

I had a go at building libao-0.6.0 and it barfed on the alsa output part, complaining that snd_pcm_channel_status_t is undeclared - probably due to me running alsa 0.9.0 beta4. So the question is, should I try and beat the configure stuff into letting me disable alsa support and just use OSS, or would I be better off trying my luck with the nightly builds? And if so, can I get away with just