similar to: Parallelism

Many of you probably remember the flurry of posts that I created a few weeks ago about writing a parallel vorbis encoder. Here's what I have been doing since... Someone (I can't remember who offhand -- might have been Greg) mentioned using threads instead of MPI for parallelism on the argument that more people have SMPs than who have (and know how to use) an MPI implementation. Good

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

I sent a message about 2 weeks ago about build problems at the head of the CVS tree with non-gcc compilers on POSIX systems, although I didn't correctly identify the link problems as being static-library only (see my previous mail about "static link broken"). Some problems have been fixed, but some still seem to be there. I have edited my original mail to list the problems that

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

Happy new millenium! Summary: I'm having a problem queueing up the ogg_packet results of vorbis_analyze() for later writing to an .ogg stream. The docs don't seem to say if this is permissable or not. Hence, I don't know if I'm using the API incorrectly, or if this is an actual bug. ----- Attached is a short patch to vorbis-tools/oggenc/encode.c (from CVS head, 01/01/01... I

A variation on questions that I've asked before... In working on the parallel version of oggenc (both threaded and MPI), a profiling run shows that the function vorbis_analysis() takes up the majority of the run time. This seems to be an obvious choice for parallelization -- send each vorbis_block to a different processor, and let them call vorbis_analsis() in parallel with each other.

This is a rather obscure question, I realize. I have written to the package author but have not heard back as of yet. I have read the README in the package, as well, but it didn't give me enough detail to diagnose the problems that I am having. (I did edit out the LAM-MPI check in zzz.R.in.) I am working to install Rmpi on top of MPICH on a beowulf cluster. Below is the output of the

I've put together a first cut for a Win32 DLL using the BladeEnc interface. Right now, it's just a drop-in replacement for BladeEnc.dll that ignores all encoding parameters passed to it and uses the info_A vorbis_info struct (same as the encoder_example). It's not particularly useful as of yet, but you can rename it to BladeEnc.dll and use it with any number of rippers out there

So it looks like the Frauenhoffer boys are issuing an updated format -- MP3pro. They claim that it will give 128kbps/MP3 quality in 64kbps. I'm interested to see what others think of this. I'm also curious: I've seen others on the list say that Ogg/Vorbis' sound quality is "better" than MP3. Can this be quantified (or is this already on a web page somewhere)? I kinda

Hi everyone, My name is Tord Jansson and I'm the creator of BladeEnc. I'm very delighted to see that someone has created an open and patent-free sound format which seems to have the qualifications to be on par (or beat) even the best proprietary formats. Congratulations to everyone involved! I would like to help making Vorbis a popular format for compressed audio and have been thinking

I have having problems trying to take a file recorded with Monitor and convert it to MP3. When I use 'play' to play the .wav file, it sounds fine. After bladenc'ing it, it plays at lightening speed, and the voices are all high pitch. I tried using sox to resample to 32000 before encoding, but that didnt work either. Do any of you convert your .wav files to mp3? Monitor call:

Hi, I have two questions about llvm, and expect your reply very much. 1. Is there any plan of llvm to support Thread-Level Parallelism by using OpenMP, MPI, pthread or llvm-defined directives? If automatic parallelism exploring is very hard, what is the key problem? We can't get the precise data dependence information at compile-time? 2. Can I use the functions provided by llvm to

I have a small feature request for oggenc: Can a command line option be added to allow the user to set the first serial number to be used for the output ogg stream? This only takes a few lines of code, actually. Rationale: it is quite helpful for debugging other encoders. If oggenc is the "reference" encoder, ensuring that your new whiz-bang encoder has diffable output to oggenc is a

>From /., here's the URL with the announcement of mp3PRO http://www.twice.com/html/pagebeta.cfm?InputKey=2853 {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness {+} "I came to ND for 4 years and ended up staying for a decade" --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage:

vorbis/lib/vorbisenc.c:138 and 157 have "//" comments. Patch included for the lazy (like me!). {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness {+} "I came to ND for 4 years and ended up staying for a decade" Index: vorbis/lib/vorbisenc.c =================================================================== RCS file:

Per Monty's suggestions from a while ago, I have [finally] gotten around to playing with different schemes for parallel oggenc. Monty's main suggestion was to have a single thread loop over reading samples and calling vorbis_analysis_blockout(), and then queueing up the resulting blocks to be processed through vorbis_analysis() in other threads (in parallel). To verify that this works, I

I have sent some patches to some Makefile.am's as well as to some configure.in's, particularly for building without gcc and gmake. Can someone review those patches, and/or commit them? (we are working at the CVS head these days, no?) I cannot build in Solaris without gcc/gmake, for example -- running "autogen.sh" in the ao project with the native Solaris compilers causes

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

Hi, I've been trying here to install Rmpi on an SGI IA-64 machine with 64 processors, running SuSE Linux Enterprise Server 9, R 2.4.0 and lam-mpi 7.1.3. While I've read of similar problems on this list, I think I've got an entirely new set of error messages to contribute (see below). I'm not sure what the actual error is and what the @gprel relocation message is about. Any help

vorbis-tools/oggenc/utf8.c:164 has a //-style comment; it should be /* ... */ so that non-gcc compilers won't barf (e.g., solaris Forte 6.1 cc). Patch included, if you're really lazy. :-) {+} Jeff Squyres {+} squyres@cse.nd.edu {+} Perpetual Obsessive Notre Dame Student Craving Utter Madness {+} "I came to ND for 4 years and ended up staying for a decade" Index: oggenc/utf8.c