Re: [Flac-dev] [PATCH] autogen.sh : detect automake-1.10 correctly
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Josh, > > Macports on OSX ships with automake-1.10 and the current autogen.sh > detects 1.10 as an invalid version of automake. > > The following patch (snarfed from autogen.sh from libvorbis) fixes > that. fixed in cvs (I think, I might have messed it up editing the inline patch from the mail, attachments work better) Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Compile problems on OSX
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Sorry, I just updated from CVS and its still broken. If FLAC__HAS_OGG > is false it tries to compile this: > > (void)decode_options; > > and there is no "decode_options" identifier. oops, fixed. Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] [PATCH] autogen.sh : detect automake-1.10 correctly
Josh, Macports on OSX ships with automake-1.10 and the current autogen.sh detects 1.10 as an invalid version of automake. The following patch (snarfed from autogen.sh from libvorbis) fixes that. Once that is fixed there are still some other issues that need fixing for automake-1.10. Cheers, Erik diff -u -r1.16 autogen.sh --- autogen.sh 21 Nov 2006 01:40:57 - 1.16 +++ autogen.sh 10 Sep 2007 01:51:16 - @@ -46,9 +46,10 @@ DIE=1 } -VERSIONGREP="sed -e s/.*[^0-9\.]\([0-9]\.[0-9]\).*/\1/" -VERSIONMKINT="sed -e s/[^0-9]//" - +VERSIONGREP="sed -e s/.*[^0-9\.]\([0-9][0-9]*\.[0-9][0-9]*\).*/\1/" +VERSIONMKMAJ="sed -e s/\([0-9][0-9]*\)[^0-9].*/\\1/" +VERSIONMKMIN="sed -e s/.*[0-9][0-9]*\.//" + # do we need automake? if test -r Makefile.am; then AM_OPTIONS=`fgrep AUTOMAKE_OPTIONS Makefile.am` @@ -68,12 +69,15 @@ fi else echo -n "checking for automake $AM_NEEDED or later... " +majneeded=`echo $AM_NEEDED | $VERSIONMKMAJ` +minneeded=`echo $AM_NEEDED | $VERSIONMKMIN` for am in automake-$AM_NEEDED automake$AM_NEEDED \ - automake automake-1.7 automake-1.8 automake-1.9; do + automake automake-1.7 automake-1.8 automake-1.9 automake-1.10; do ($am --version < /dev/null > /dev/null 2>&1) || continue - ver=`$am --version < /dev/null | head -n 1 | $VERSIONGREP | $VERSIONMKINT` - verneeded=`echo $AM_NEEDED | $VERSIONMKINT` - if test $ver -ge $verneeded; then + ver=`$am --version < /dev/null | head -n 1 | $VERSIONGREP` + maj=`echo $ver | $VERSIONMKMAJ` + min=`echo $ver | $VERSIONMKMIN` + if test $maj -eq $majneeded -a $min -ge $minneeded; then AUTOMAKE=$am echo $AUTOMAKE break @@ -82,11 +86,12 @@ test -z $AUTOMAKE && echo "no" echo -n "checking for aclocal $AM_NEEDED or later... " for ac in aclocal-$AM_NEEDED aclocal$AM_NEEDED \ - aclocal aclocal-1.7 aclocal-1.8 aclocal-1.9; do + aclocal aclocal-1.7 aclocal-1.8 aclocal-1.9 aclocal-1.10; do ($ac --version < /dev/null > /dev/null 2>&1) || continue - ver=`$ac --version < /dev/null | head -n 1 | $VERSIONGREP | $VERSIONMKINT` - verneeded=`echo $AM_NEEDED | $VERSIONMKINT` - if test $ver -ge $verneeded; then + ver=`$ac --version < /dev/null | head -n 1 | $VERSIONGREP` + maj=`echo $ver | $VERSIONMKMAJ` + min=`echo $ver | $VERSIONMKMIN` + if test $maj -eq $majneeded -a $min -ge $minneeded; then ACLOCAL=$ac echo $ACLOCAL break -- - Erik de Castro Lopo - "It is capitalist America that produced the modern independent woman. Never in history have women had more freedom of choice in regard to dress, behavior, career, and sexual orientation." -- Camille Paglia ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Compile problems on OSX
Josh Coalson wrote:
> the main reason I haven't swtiched is I'm not up on pkgconfig
> and XIPTH_PATH_OGG has been working pretty well... can you tell
> why it's not working for you?
>
> I'm always hesitant to mess with things in configure.in because
> is such whack-a-mole problem (fixes things for some people and
> breaks for others).
I'll look into that over the next day or so. The pkg-config method
has the advantage of being highly robust, but is a pain for MinGW
because you need pkg-config.
> > Second problem is that I get a compile error when FLAC__HAS_OGG is 0
> > in src/flac/decode.c:
> >
> > decode.c:393: error: 'options' undeclared (first use in this
> > function)
> >
> > The code in question is this:
> >
> > #if FLAC__HAS_OGG
> > if(decoder_session->is_ogg) {
> > /* Some code here. */
> > }
> > else
> > #else
> > (void)decode_options;
> > #endif
> > {
> > /* More code. */
> > }
>
> yes, this is fixed in cvs. actually I'll probably be doing a
> release soon and I'd be interested to know if the latest stuff
> works for you.
Sorry, I just updated from CVS and its still broken. If FLAC__HAS_OGG
is false it tries to compile this:
(void)decode_options;
and there is no "decode_options" identifier.
Maybe this is the delay between your CVS commit and the public CVS
being updated.
> interesting idea, hadn't thought of that.
Please take a look at this. Doing it this way means that both code
paths are checked by the semantic analysis stage of the compiler
regardless of value of FLAC__HAS_OGG. It prevents conditional compile
constructs from hiding really blatantly obvious errors like this one.
Erik
--
-
Erik de Castro Lopo
-
"Whenever the C++ language designers had two competing ideas as to
how they should solve some problem, they said, "OK, we'll do them
both". So the language is too baroque for my taste." -- Donald E Knuth
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] FLAC__FrameHeader's blocksize element
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Hi all, > > I've found that the FLAC__FrameHeader struct's blocksize member > has values limited to the range (0, FLAC__MAX_BLOCK_SIZE] where > FLAC__MAX_BLOCK_SIZE is 65535. > > In the encoder, what determines the size of a block? in libFLAC, currently the client dictates the block size which is used for all blocks in the stream. Josh Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Compile problems on OSX
--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've got two problems compiling the current CVS FLAC sources on OSX.
>
> Firstly, the configure script can't find the OGG libraries which were
> installed from MacPorts. I have tried:
>
> ./configure --with-ogg-includes=/opt/local/include \
>--with-ogg-lib=/opt/local/lib
>
> but they are still not found. I notice that in configure.in, you use
> a macro called XIPH_PATH_OGG. Is there any reason you don't use the
> PKG_CHECK_MODULES mcaro which uses pkg-config underneath? For my
> system pkg-config does the right thing:
>
> > pkg-config --cflags --libs ogg
> -I/opt/local/include -L/opt/local/lib -logg
>
> I will put together a patch for this is you are interested.
the main reason I haven't swtiched is I'm not up on pkgconfig
and XIPTH_PATH_OGG has been working pretty well... can you tell
why it's not working for you?
I'm always hesitant to mess with things in configure.in because
is such whack-a-mole problem (fixes things for some people and
breaks for others).
> Second problem is that I get a compile error when FLAC__HAS_OGG is 0
> in src/flac/decode.c:
>
> decode.c:393: error: 'options' undeclared (first use in this
> function)
>
> The code in question is this:
>
> #if FLAC__HAS_OGG
> if(decoder_session->is_ogg) {
> /* Some code here. */
> }
> else
> #else
> (void)decode_options;
> #endif
> {
> /* More code. */
> }
yes, this is fixed in cvs. actually I'll probably be doing a
release soon and I'd be interested to know if the latest stuff
works for you.
> The problem here is that conditional compiles can hide bugs. The code
> above
> re-written to turn a conditional compile into an always compiled if
> statement
> which will trigger the error regardless of the value of
> FLAC__HAS_OGG:
>
> if(FLAC__HAS_OGG && decoder_session->is_ogg) {
> /* Some code here. */
> }
> else
> {
> (void)decode_options;
> /* More code. */
> }
interesting idea, hadn't thought of that.
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Re: multiple core support
--- Ralph Giles <[EMAIL PROTECTED]> wrote: > On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote: > > > it actually is complicated. the libFLAC api is not suited to a > > multithreaded design because the i/o is stream-based, not file- > > based. flac(.exe) is the file-based wrapper around libFLAC that > > allows it to work on files. the way libFLAC buffers data is also > > impossible to parallelize without significantly changing the api. > > It seems like buffering (especially compressed) blocks and writing > them > to the stream in sequence wouldn't be a problem. Is there something > in > the way the blocking decisions are made that makes it hard to divide > the > input audio this way? if the constraint of sequential output is kept, I was thinking that to get maximum efficiency, the library would need to be able to get samples out of order to keep all the threads going at max speed, or might have to grow buffers arbitrarily large if fed samples sequentially because of the different processing requirements of different blocks. extreme example: a block that goes through high- order LPC processing followed by several silence or noise blocks. Josh Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Re: multiple core support
--- Harry Sack <[EMAIL PROTECTED]> wrote: > 2007/9/8, Josh Coalson <[EMAIL PROTECTED]>: > > > > it actually is complicated. the libFLAC api is not suited to a > > multithreaded design because the i/o is stream-based, not file- > > based. flac(.exe) is the file-based wrapper around libFLAC that > > allows it to work on files. the way libFLAC buffers data is also > > impossible to parallelize without significantly changing the api. > > why was this approach used? because the tradeoffs I described required for arbitrarily parallel encoding significantly complicate the api and implementation. libFLAC was not design for multicode file encoding on PCs, it is a reference design that is also being used in embedded devices running <100MHz, low memory, all kinds of different OSes, etc. > The API design seems to me not very smart > because it's not flexible and you're stuck in the future (like now > for multiple core support) > > I don't see any reason why you wouldn't make it all based on files > and not on streams :s It's just a major disavantage in my opinion an api cannot be all things to everyone. you keep making this assertion but if you actually tried to implement it (and I hope you will) the problems we are all bringing up will quickly become obvious. your own lame-mt example is not an incremental improvement but a significant rewrite of lame (and also does not have nearly the performance advantage of process-level parallelism, see http://www.hydrogenaudio.org/forums/index.php?showtopic=50862) > > it would take a specialty file-based encoder using an independent > > frame encoder to do and even that is not trivial. > > so we can assume that those API changes will never come and the flac > encoder will never have multiple core support? you can assume libFLAC will probably not have it. if you can modify libFLAC to make a multithreaded encoder like flac-mt that would be neat and probably useful to some people. until that time there is not much point repeating the same assertions which are just going to aggravate people. Josh Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Re: multiple core support
2007/9/8, Brian Willoughby <[EMAIL PROTECTED]>: > > Harry, > > You assume that the only way to use FLAC is the way that you are using it, > by converting one file format to another. That's not the only way to use > FLAC. The most important uses of FLAC are for internet streaming radio or > hand-held digital audio players. Both of these prominent uses are not > really file based, but are stream based. It makes perfect sense for the > core of FLAC to be stream based. It makes the code small and portable to > any platform, no matter how limited. > 1) I never said this is the only way to use it: you put those words in my mouth, I never told this to anybody :) I also didn't say the fact that the API is based on streams is bad! I only say it's not a good choice if you want to support multiple threads ... Please read carefully what I write :) Besides, the API has support for seekable streams and files. > > The big issue here is that you actually believe it is possible to support > multiple processors and, further, that there would be an advantage to this. > Those are both really big assumptions. I don't think anyone else, besides > you, believes that it is possible or desirable for the FLAC codec to be > multithreaded. > 2) you really show you have no good knowledge about programming. There are several codecs out there that try to use multiple cores. To give a concrete example: http://www.lame-mt.com/ Here is the prove there is a HUGE performance boost: 'The output of this multi-threaded version, based on LAME 3.97 alpha, is 1:1 bit compatible with the original version and it gains *~1.16x speedup* when Constant Bit Rate (CBR) or Average Bit Rate (ABR) models are used and *~1.30 speedup* when Variable Bit Rate (VBR) mode is used on SMT platforms and > 1.45x on SMP systems.' If you say it can't have no speed improvement, then you prove you don't know a thing about programming. I will laugh at you when 8 cores wille be standard in all pc's and you still will say the same :) Harry, you've sent 90 to 100 messages to these mailing lists asking about > whether FLAC supports every possible feature that a given piece of software > or an audio format could have. If you read about a feature someone else, > you come here asking when FLAC will support that feature, or why not, > without any idea of why it would even be good, or even possible. > 3) I told you multiple thread support is possible, I gave you an real-life example of the LAME encoder above. I also gave reasons why it would be better: faster encoding speeds, ... Besides that: you can't decide if I send messages to this list or not, so don't *even* talk about that! You don't seem to understand that it is not possible to put every feature > into every program, not just because of development resource constraints, > but also because certain features are mutually exclusive. Certain features > make other features impossible, or at least undesirable. It simply isn't > possible to do some of the things you're asking for, and I am actually > surprised that you don't understand why they are impossible. You have > basically shown a lack of solid understanding of formats, mathematics, > programming, and logic. > says the guy who tells me supporting multiple threads in the encoding phase of an encoder is impossible and will give NO performance boost (I point you out to LAME MT again that proves you're wrong) ... There is a popular saying: "The is no such thing as a stupid question." > Well, Harry, you're the first person I've experienced who thoroughly > challenges that statement. > And you are the first person who thinks he is mister-knows-it-all but gives EXTREME funny and incorrect statements like: - 'multiple core support won't give a performance boost' - 'it's impossible to implement multiple threads in an audio encoder' I recommend you to study IT (like I did) and get your master's degree and after that maybe your PhD. We'll talk again then when you accomplished this :) best regards, Harry Brian W. > > > On Sep 8, 2007, at 06:02, Harry Sack wrote: > > 2007/9/8, Josh Coalson <[EMAIL PROTECTED]>: > > > > it actually is complicated. the libFLAC api is not suited to a > > multithreaded design because the i/o is stream-based, not file- > > based. flac(.exe) is the file-based wrapper around libFLAC that > > allows it to work on files. the way libFLAC buffers data is also > > impossible to parallelize without significantly changing the api. > > > > why was this approach used? The API design seems to me not very smart > because it's not flexible and you're stuck in the future (like now for > multiple core support) > I don't see any reason why you wouldn't make it all based on files and not > on streams :s It's just a major disavantage in my opinion > > it would take a specialty file-based encoder using an independent > > frame encoder to do and even that is not trivial. > > > > so we can assume that those API changes will never come and the fl
Re: [Flac-dev] Re: multiple core support
2007/9/8, Scot Thompson <[EMAIL PROTECTED]>: > > No, streams should stay. Audio is NOT a file based process -- it's a > stream. You can't listen to an entire song simultaneously. You organize it > into files for later use, but you listen and record from a stream. > Stream-based storage is practically REQUIRED for an audio codec. It's not > random access, it's sequential. You can put wrappers around it to make it > convenient for file storage and conversions, but the codec itself must be > streams. > > Multi-core support may not be practical for a variable-length encoding. > How would you know where to write the next block when you don't know what > size the first block is going to be? The functionality for that is not > trivial and is not currently implemented in the API. > > Maybe somebody will write a multi-core file-based wrapper for you, or > maybe you could try writing one yourself. Or if you disagree with Josh > about the direction of FLAC you can write your own codec. But your > nattering on and on about how you think the API isn't right doesn't help at > all and is very annoying. > I just say that the way it is now it's IMpossible to make multiple core support, that's all. It's just a fact :) Harry -- > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Harry Sack > *Sent:* Saturday, September 08, 2007 6:06 AM > *To:* Brian Willoughby > *Cc:* flac-dev@xiph.org > *Subject:* Re: [Flac-dev] Re: multiple core support > > > > 2007/9/8, Brian Willoughby <[EMAIL PROTECTED]>: > > > > Ralph, > > > > The problem is that there is no clear advantage, at least in terms of > > multiple cores, to the approach you're asking about. In order to > > allow each stage of the codec to overlap, you need smart buffering > > between each stage. That adds code and complexity which isn't there > > currently. So you end up making the system do more work in the hopes > > that there will be some overlap. Basically, later stages get blocked > > waiting for their input buffer to fill, which means that you're not > > really getting very much overlap at all, but plenty of multi- > > threading overhead. At least that's the predicted result - I admit > > that nobody has tried this, to my knowledge. > > > > this is because of the limitations/design problem of FLAC API in > particular. When the developers had made a smart decision and based > everything on file based I/O you would get a HUGE performance boos when > using multiple threads divided between multiple cores, because they only > thing to do was to split the file output in different threads. > But it's not clear to me why everything was based on streams... > > Harry > > Brian Willoughby > > Sound Consulting > > > > > > On Sep 7, 2007, at 18:25, Ralph Giles wrote: > > > > On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote: > > > > > it actually is complicated. the libFLAC api is not suited to a > > > multithreaded design because the i/o is stream-based, not file- > > > based. flac(.exe) is the file-based wrapper around libFLAC that > > > allows it to work on files. the way libFLAC buffers data is also > > > impossible to parallelize without significantly changing the api. > > > > It seems like buffering (especially compressed) blocks and writing them > > to the stream in sequence wouldn't be a problem. Is there something in > > the way the blocking decisions are made that makes it hard to divide the > > input audio this way? > > > > -r > > > > ___ > > Flac-dev mailing list > > Flac-dev@xiph.org > > http://lists.xiph.org/mailman/listinfo/flac-dev > > > > > ___ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > > ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
