search for: linuxaudiosystems

On Tue, Aug 17, 2010 at 3:12 PM, Paul Davis <paul at linuxaudiosystems.com> wrote: > On Mon, Aug 16, 2010 at 11:09 PM, Glenn McCord <glenn.mccord at gmail.com> wrote: > >> libtool: link: gcc -I/Users/glennm/libOGG-i386/include -O3 >> -funroll-loops -finline-functions -Wall -W -Winline -arch i386 -arch >> i386 -o flac analyze.o decode.o...

On Fri, Jan 7, 2011 at 3:56 PM, David Richards <rawdod at gmail.com> wrote: > Its really sad to hear thats happening but even more sad is the fact > that flac is becoming a very common format for music on the interweb > whilst at the same time the development has ceased. I've found some > severe issues with OggFLAC that essentially make it a useless format > for streaming,

> From: Paul Davis <paul at linuxaudiosystems.com> > To: flac-dev at xiph.org > Cc: > Sent: Friday, March 25, 2011 5:39 AM > Subject: Re: [Flac-dev] pkg-config output and <FLAC/assert.h> > > On Fri, Mar 25, 2011 at 5:32 AM, Erik de Castro Lopo > <mle+la at mega-nerd.com> wrote: >> Hi, >> >...

hi, and sorry that my first post to the list is a complaint. the .pc file for 1.2.1 produces this for --cflags: -I$PREFIX/include/FLAC i humbly suggest that this is wrong. it appears to support inclusion of FLAC headers with #include <filename.h> rather than #include <FLAC/filename.h> but more importantly, it means that when building an app using pkg-config to

--- On Fri, 8/14/09, Paul Davis <paul at linuxaudiosystems.com> wrote: > On Fri, Aug 14, 2009 at 5:05 PM, Josh Coalson<xflac at yahoo.com> > wrote: > > it's unlikely flac will ever support floating-point > > samples natively. ?the main application for it is audio > > engineering, which demands easy editing and very high...

...h unmodified then I'm sure the device is hitting these bugs. There is different bugs in the encoding and decoding side of things, and also in the ogg packaging layer. All of this is related to periods of silence in the stream of sound. -D On Fri, Jan 7, 2011 at 4:01 PM, Paul Davis <paul at linuxaudiosystems.com> wrote: > On Fri, Jan 7, 2011 at 3:56 PM, David Richards <rawdod at gmail.com> wrote: >> Its really sad to hear thats happening but even more sad is the fact >> that flac is becoming a very common format for music on the interweb >> whilst at the same time the deve...

Josh Coalson wrote: > > From: Paul Davis <paul at linuxaudiosystems.com> > > To: flac-dev at xiph.org > > Cc: > > Sent: Friday, March 25, 2011 5:39 AM > > Subject: Re: [Flac-dev] pkg-config output and <FLAC/assert.h> > > > > On Fri, Mar 25, 2011 at 5:32 AM, Erik de Castro Lopo > > <mle+la at mega-nerd.com>...

...e device is hitting these bugs. There is different bugs in the > encoding and decoding side of things, and also in the ogg packaging > layer. All of this is related to periods of silence in the stream of > sound. > > -D > > On Fri, Jan 7, 2011 at 4:01 PM, Paul Davis <paul at linuxaudiosystems.com> wrote: >> On Fri, Jan 7, 2011 at 3:56 PM, David Richards <rawdod at gmail.com> wrote: >>> Its really sad to hear thats happening but even more sad is the fact >>> that flac is becoming a very common format for music on the interweb >>> whilst at the sa...

Hi, FLAC helpfully provides a flac.pc file. Unfortunately there is a nasty interaction between that file and system header files. If ones installs flac and relies on pkg-config to find the CFLAGS one woulf get CFLAGS value of "-I${includedir}/FLAC" which suggests that FLAC header files like <metadata.h> should be included as: #include <metadata.h> However, FLAC also

Thanks for the reply. I would very much like OGG container support, so disabling it isn't really an option. I have built OGG so that it creates a libogg.a, libogg.0.dylib and a symbolically linked libogg.dylib (that links to the libogg.0.dylib) file. If I remove the .dylib files in an attempt to 'encourage' the compiler to use libogg.a, then it complains that it can't find the

On Fri, Aug 14, 2009 at 5:05 PM, Josh Coalson<xflac at yahoo.com> wrote: > it's unlikely flac will ever support floating-point samples natively. ?the main application for it is audio engineering, which demands easy editing and very high speed for both encoding and decoding above everything else. thats not why floating point is used. the highest current feasible bit resolution for

On Mon, Dec 6, 2010 at 6:10 AM, Maurizio De Cecco <jmax at dececco.name> wrote: > I have been looking for a while to  LLVM as a possible technology to build a > DSP execution engine, providing the runtime flexibility needed by real-time > interactive DSP applications (like patcher languages), or by plug-in based > processors, and in the same moment > the powerful link time

On Sat, Jan 8, 2011 at 8:39 PM, grarpamp <grarpamp at gmail.com> wrote: > Yes, this is sad. cdparanoia, which could be considered a strong > opensource meatspace partner to FLAC (along with cdda2wav) > is also effectively dead. All three living on only in the ports trees of > various operating systems. Minor bugs and doc fixes are always > needed. What's worse is, when

On Mon, Mar 7, 2011 at 11:25 AM, Brian Willoughby <brianw at sounds.wa.com> wrote: > All professional tools use conversion factors such as 0x8000 for > float-to-int and int-to-float because it has a single significant > bit, and thus this factor does not increase the bit depth of the > samples passing through. i'm not sure what "all" means, but i don't think

On Fri, Mar 25, 2011 at 5:32 AM, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Hi, > > FLAC helpfully provides a flac.pc file. Unfortunately there is a > nasty interaction between that file and system header files. > > If ones installs flac and relies on pkg-config to find the CFLAGS > one woulf get CFLAGS value of "-I${includedir}/FLAC" which suggests

On Fri, Aug 14, 2009 at 6:47 PM, Brian Willoughby<brianw at sounds.wa.com> wrote: > When the ADC source and the DAC destination are both limited to 24- > bit fixed point integers, it makes absolutely no sense to store > recordings or final mixes in 32-bit floating point representation. > The headroom you speak of is completely unavailable when storing the > output of an ADC

>I can't really comment on jackd itself, as I haven't looked that much >into it. If running jackd as root requires client apps to also run as >root then that is a pretty bad issue. I would of thought that running >jackd as a realtime process (whether root or not) would be an important >consideration. jackd (realtime) requires various resources which it shares with its