Re: [linux-audio-dev] Getting out of the software game
Lee Revell wrote: > The plural of anecdotes is not data. Nice! Thats one for the sigmonster. Erik -- +---+ Erik de Castro Lopo +---+ "Fundamentalists of all faiths are the fundamental evil of our time." -- Salman Rushdie
Re: [linux-audio-dev] Sample Rate Conversion in Linux (Newby)
Jonathan Ryshpan wrote: > Which algorithm/library/program is used for sample rate conversion by > cdrecord in Linux? No sure about cdrecord. > Other programs? Ardour, Sweep, Audacity (I think), ecasound and any other program that cares about quality sample rate conversion uses the Rabbit: http://www.mega-nerd.com/SRC/ > I assume there is a library to > perform this function, which is used by most utilities, xmms, amarok, > cdrecord, audacity, etc. Is there any easy way to find this out? ldd If you see libsamplerate.so.0 there the uses the Rabbit. If cdrecord doesn't use the Rabbit, then you can use the command line sample rate converter (sndfile-resample) included in the Rabbit source code. In Debian/Ubuntu there us a precompiled binary in the samplerate-programs package. HTH, Erik -- +-------+ Erik de Castro Lopo +---+ "The one thing that reading these five books has hammered home is how much C++ has turned into 3 languages stuck in a bag fighting to get out. Low C++, High C++, and Generic C++."
Re: [linux-audio-dev] Sample Rate Converter Comparison
Denis Sbragion wrote: > and did you get it? I'm not there yet, but I'm getting closer. Erik -- +-------+ Erik de Castro Lopo +---+ "We must not forget that Allah's rules have to be established in all lands." -- Imam Muzammil H. Siddiqi of the Islamic Society of North America
Re: [linux-audio-dev] Sample Rate Converter Comparison
Denis Sbragion wrote: > Of course this is just academic, because I really doubt that the tiny > artifacts introduced by SRC are audible at all, even in its current > implementation. Just a matter of winning the race. :) The current algorithm (originally described by Julius O. Smith) has its limitations. Thats why I have spent a considerable amount of time trying to come up with something that has lower computational requirements as well as better quality :-). Cheers, Erik -- +---+ Erik de Castro Lopo +---+ "[Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript." -- Jamie Zawinski
Re: [linux-audio-dev] Sample Rate Converter Comparison
Erik de Castro Lopo wrote: > Hi all, > > SecretRabbitCode was recently included in a test of a number of > commercially available sample rate converters and while it wasn't > the best, it certainly didn't disgrace itself either. I should also thank Ben Loftis of GWL (Harrison consoles) for hooking me up with the people running the tests so that the Rabbit could be included. Erik -- +-----------+ Erik de Castro Lopo +---+ "A 'newbie', in Haskell, is someone who hasn't yet implemented a compiler. They've only written a monad tutorial." -- From #haskell on freenode
Re: [linux-audio-dev] Sample Rate Converter Comparison
Paul Davis wrote: > congrats Erik. Thanks! > as you said, not the best (r8brain ?) r8brains was good as was iZotope, Wavelab/Crystal and a couple of others. > but compared to the > stuff in some proprietary DAWs, pretty great. quite amazing how bad the > ProTools and Sadie systems were ... Protools wasn't *that* bad unless you look at it on a bang per buck basis :-). Sadie however was appallingly bad. Erik -- +-----------+ Erik de Castro Lopo +---+ I call C++ a curse on programmers everywhere; the language that has enabled and encouraged more stupidity and bad software design than any other programming language ever.
[linux-audio-dev] Sample Rate Converter Comparison
Hi all, SecretRabbitCode was recently included in a test of a number of commercially available sample rate converters and while it wasn't the best, it certainly didn't disgrace itself either. The results are here: http://src.infinitewave.ca/ This test gives me yet more incentive to continue my work on coming up with a new improved algorithm. Cheers, Erik -- +---+ Erik de Castro Lopo +---+ "I'd rather not work with people who aren't careful. It's darwinism in software development." -- Linus Torvalds on the linux-kernel list
Re: [linux-audio-dev] libsndfile, or audiofile?
kind king knight wrote: > There is not much to say. Need to know, because learning two different > interfaces would be non-economical :P. I recommend libsndfile :-). Erik -- +---+ Erik de Castro Lopo +---+ Traditional capital was stuck in a company's bank account or investments. It could not walk away in disgust. Human capital has free will. It can walk out the door; traditional capital cannot.
Re: [linux-audio-dev] Paper on dynamic range compression
John Rigg wrote: > On Wed, Oct 18, 2006 at 06:50:39PM +1000, Erik de Castro Lopo wrote: > > > But this should only be happening on transients and the clipping > > should stop as soon as the attack portion of the compression > > process kicks in. > > Yes but my point is that the resulting aliasing sounds worse than the > harmonic distortion. The aliasing is present for 10s of milliseconds. It blurs into the instrument attack. Have a look at the attack transient of an acoustic guitar or a piano. There a bunch of stuff in the first 30 odd milliseconds that bears no relationship with the fundamental note frequencey. > True, but those are removed by the anti-aliasing filters in > the ADCs. I talking about the stuff below half the sample rate. > > Ok, lets say we're sampling at 44.1kHz, which makes the highest > > 3rd harmonic we can represent is 22.0/3 kHz which is about 7kHz. > > Do you really listen to many instruments where the fundamental > > is at 7kHz? > > A lead guitarist will often deliberately play a harmonic `squeal' > in a lead solo (particularly in rock and metal). As a guitarist myself, > I fairly frequently generate fundamentals of around 4 kHz. Thats a bit less than an octave below what I'm talking about. > Deliberate > use of higher frequencies than that might not be very common, but > the equipment should at least deal with it gracefully. I agree completely. > The fact remains that a lot of high end professional users consider many > of the free software plugins to be "nearly unusable" (see Ben Loftis' > earlier post in this thread). I have no problem whatsoever with the possibility that all current free software compressors are poorly implemented, but that doesn't prove that its not possible to implement a good compressor without upsampling. All the best and most famous compressors were implemented using flawed 1960s and 1970s technology. The Joe Meek compressor uses light depend resistors In order to make a good digital compressor, we need to remember that a compressor is lo-tech. Any benchmark DSP implementation should also be relatively lo-tech. Once you have a good working lo-tech DSP implementation then you can start looking to improve it using whatever far out DSP techniques you can think of. Erik -- +---+ Erik de Castro Lopo +---+ "Indeed, I am impressed that Google runs an 8,000 node Linux cluster, 5 data centers, an extensive network, and a rapidly evolving application all with a staff of 12." -- http://research.microsoft.com/~gray/papers/FAAMs_HPTS.doc
Re: [linux-audio-dev] Paper on dynamic range compression
John Rigg wrote: > Soft clipping always sounds better than hard clipping, and there are > analog compressors that behave like this. Unfortunately even a soft > clipper generates significant harmonic distortion, largely 3rd and 5th. But this should only be happening on transients and the clipping should stop as soon as the attack portion of the compression process kicks in. Most instruments with fast transients usually *already* have a high levels of higher harmonics (and inharmonics) that die away far more quickly than the lower harmonics. > The 3rd harmonic alone potentially increases the signal bandwidth by > three times Ok, lets say we're sampling at 44.1kHz, which makes the highest 3rd harmonic we can represent is 22.0/3 kHz which is about 7kHz. Do you really listen to many instruments where the fundamental is at 7kHz? > and aliasing will occur if the sample frequency isn't > high enough to accommodate all harmonics These higher harmonics will be transitory. As soon as the attack portion of the compressor's action is over they're gone. In addition, any aliasing that does occur will be almost indistinguishable from the inharmonics frequencies already in transient part of the sound. I say again, nearly all instruments with very fast transients have a high number of inharmonics frequencuies that die off almost immediately. For instance, think of instruments like acoustic guitars and pianos. Its very easy to get carried away with trying to reach some sort of audio perfection. Things like upsampling in order to apply compression is over-engineering. Erik -- +-----------+ Erik de Castro Lopo +---+ "Attacks by Microsoft Chairman Bill Gates on the GNU General Public License, under which much open source and free software is distributed, have been driven by a fear that the GPL creates a domain of software that Microsoft cannot privatize and control" -- Richard Stallman
Re: [linux-audio-dev] Paper on dynamic range compression
Dan Mills wrote: > > --- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > > > You need a low pass filter on the control signal. It > > should > > be somewhere well below 1kHz. > > Agreed that you need the filter, but a 'brick wall' at > 1Khz means that anything faster then 50ms or so as an > attack time (and there are legit uses for such), will > itself overshoot horrribly due to the gibb effect of > bandlimiting the control signal. This is the way analogue compressors work. If you have a sound with a fast transient going into a slow attack compressor, the transient passes throught pretty much untouched (apart from any clipping that may occur due to other parts of the design). Erik -- +-----------+ Erik de Castro Lopo +---+ Failure is not an option. It comes bundled with your Microsoft product.
Re: [linux-audio-dev] Paper on dynamic range compression
Sorry, I'm coming into this late but . Dan Mills wrote: > The gain control signal has energy right the way out > to the band limit (and probably aliased around it), > never mind what happens when that hits the multiplier! You need a low pass filter on the control signal. It should be somewhere well below 1kHz. > Fixing this right means upsampling and adding a > lowpass filter to the control loop, then downsampling > again. No it doesn't. You want to absolutely avoid fast changes in the control signal because fast changes will modulate the audio signal whcih is **not** desirable. Erik -- +-----------+ Erik de Castro Lopo +---+ "The reasonable man adapts himself to the world; the unreasonable one persists to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw (1856-1950)
Re: [linux-audio-dev] How to test resampling quality?
James Courtier-Dutton wrote: > Hi, > > I was wondering if there are any tools out there to test audio > resampling quality. I am particularly interested in 44.1kHz to 48kHz > resampling due to the fact that most sound cards prefer 48kHz. > > At least with up sampling (low rate to higher rate) one does not get > aliasing. Err, sorry, aliasing can also be produced during up sampling; in particular, aliasing can be created in the fs/2 to fd/2 band where fs is the source sample rate and fd is the desitination sample rate. > I really just want to find some algorithm that I can use to compare > 44.1kHz audio signal with an 48kHz audio signal, and to see if there has > been any lose of quality during the up sample. The Secret Rabbit Code test suite has some pretty extensive SRC test code. YOu can get the Rabbit here: http://www.mega-nerd.com/SRC/ and I gave a bit of a talk about this stuff at an LCA minconf in 2005. The slides are here: http://www.mega-nerd.com/tmp/secret_rabbit_code.pdf HTH, Erik -- +-----------+ Erik de Castro Lopo +---+ Journalist: Microsoft CEO Steve Ballmer has finally said Linux is the No. 1 threat to Windows. What's your response to that? Linus : "Tag, you're it." I don't care. They've had a lot of enemies in their time. Let them fight one enemy that doesn't care for a change.
Re: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)]
Tim Blechmann wrote: > only one? i received 3 mails to 3 different addresses, Thats how I knew it was spam. Emails to three different addresses. Erik -- +---+ Erik de Castro Lopo +---+ "Religion is a magic device for turning unanswerable questions into unquestionable answers." -Art Gecko, Wombat Discord-1, 128649
Re: [linux-audio-dev] plug:jack device channel-count
Lee Revell wrote: > Does Sweep really have no JACK support? Unfortunately that is correct. Its high on the TODO list but none of the current developers have the time to tackle it. Sweep does have a nice driver output layer but I suspect that its mainly geared towards push outputs like OSS/ALSA etc and as I understand it, JACk uses pull instead of push. Is that correct? Erik -- +---+ Erik de Castro Lopo +---+ "C++ is an atrocity, the bletcherous scab of the computing world, responsible for more buffer overflows, more security breaches, more blue screens of death, more mysterious failures than any other computer language in the history of the planet Earth." -- Eric Lee Green
Re: [linux-audio-dev] C++ wrapper for libsndfile
Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > > > Hi all, > > > > Thanks to suggestions from people here I now have a relatively > > complete C++ wrapper for libsndfile: > > > > http://www.mega-nerd.com/tmp/sndfile.hh An another update incorporating a number of suggestions from Daniel Schmitt. - The SF_INFO struct is now private. - Add frames, channels, format and samplerate getters. - Sndfile constructor and open method now require a mode (SFM_READ, SFM_RDWR or SFM_WRITE) and optional format/ channels/samplerate. The latest is at the same URL as the above. Erik -- +-----------+ Erik de Castro Lopo +---+ "No Silicon Heaven? Preposterous! Where would all the calculators go?" -- Kryten, Red Dwarf
Re: [linux-audio-dev] C++ wrapper for libsndfile
Erik de Castro Lopo wrote: > Hi all, > > Thanks to suggestions from people here I now have a relatively > complete C++ wrapper for libsndfile: > > http://www.mega-nerd.com/tmp/sndfile.hh I've updated this with the following: - Templatize the read/write/readf/writef methods. - Stop (potentially) leaking SNDFILE* pointers in the open*() methods. - Change the SF_INFO pointer to const in: Sndfile (const char *path, int mode, const SF_INFO *sfinfo_in) ; Erik -- +-------+ Erik de Castro Lopo +---+ "Software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry." -- Eric S. Raymond
Re: [linux-audio-dev] C++ wrapper for libsndfile
Lars Luthman wrote: > The 4 different overloaded versions of the read, readf, write, and > writef functions will cause ambiguities that will force you to cast them > to their respective types in order to use pointers to them, for example > in functors (e.g. a sigc++ slot), like this: > > mem_fun(sndobj, (sf_count_t (Sndfile::*)(float*, > sf_count_t))&Sndfile::read); > > If they were specialisations of the same template functions instead, > with the sample type as template parameter, you'd only have to write > this: > > mem_fun(sndobj, &Sndfile::read); > > which is a lot nicer and easier to read. Interesting use case. I'm not even close to being an expert in C++ templates, but I suppose that read function would then be defined as something like: template sf_count_t read (T *ptr, sf_count_t items) ; SO how do I ensure that only gets specialised as short, int, float and double? Erik -- +-------+ Erik de Castro Lopo +---+ The difference between genius and stupidity is that genius has its limits.
[linux-audio-dev] C++ wrapper for libsndfile
Hi all, Thanks to suggestions from people here I now have a relatively complete C++ wrapper for libsndfile: http://www.mega-nerd.com/tmp/sndfile.hh There is also a pre-release of libsndfile which includes a test for this wrapper: http://www.mega-nerd.com/tmp/libsndfile-1.0.17pre7.tar.gz C++ users, please comment. Cheers, Erik -- +---+ Erik de Castro Lopo +---+ "Even among Europe's Muslim minorities, roughly one-in-seven in France, Spain, and Great Britain feel that suicide bombings against civilian targets can at least sometimes be justified to defend Islam against its enemies." -- http://pewglobal.org/reports/display.php?ReportID=253
Re: [linux-audio-dev] light C++ set for WAV
Dmitry Baikov wrote:
> Hi, Erik!
>
> I'd suggest making all wrapper functions inline,
> as they are one-liners by definition and
> anyway wrapper includes libsndfile headers.
> So there's nothing to hide here.
Yes, that was my idea. So if the sndfile.hh has:
class Sndile
{
int method (/* params */) ;
}
int method (/* params */)
{
/* whatever */
}
do I need to add an inline keyword anywhere and if so where?
Erik
--
+-----------+
Erik de Castro Lopo
+---+
"It has been discovered that C++ provides a remarkable facility
for concealing the trival details of a program -- such as where
its bugs are." -- David Keppel
Re: [linux-audio-dev] light C++ set for WAV
Paul Coccoli wrote: > I wouldn't bother with openRead/Write; just pass the mode in to open > like in the ctor. The open/close methods are provided so a single Sndfile object can be opened and closed multiple times. I was also going to make the copy constructor and asignment operator private so they can't be misused. > I also second keeping the implementation entirely in the header (if it > really is a light wrapper) and put "inline" in front of each method > definition. Thats was the idea from the start. I light-weight wrapper. > SndFile::strerror() should maybe take an int arg (the value returned > by SndFile::error()) and be declared as a static method? Good catch. Thanks. Erik -- +-----------+ Erik de Castro Lopo +---+ "To me C++ seems to be a language that has sacrificed orthogonality and elegance for random expediency." -- Meilir Page-Jones
Re: [linux-audio-dev] light C++ set for WAV
Taybin Rutkin wrote:
> I prefer the unix-y open_read(). I don't think method names should
> ever start with a capital, unless it's the ctor or dtor.
I'm actually tending towards openRead().
> I noticed that the constructor SndFile::SndFile (const char *path,
> int mode, SF_INFO *sfinfo)
> isn't declared in the class. Also, since this constructor can fail
> if sf_open() fails up, it should throw an exception. Maybe
> containing the results of sf_strerror().
>
> Something like
>
> SndFile::SndFile (const char *path, int mode, SF_INFO *sfinfo)
> {
> psf = sf_open (path, mode, sfinfo) ;
> if (!psf) {
> throw sf_error(psf);
> }
> }
Good tip, thanks.
Erik
--
+---+
Erik de Castro Lopo
+---+
"If you think C++ is not overly complicated, just what is a
protected abstract virtual base pure virtual private destructor
and when was the last time you needed one?" -- Tom Cargill
Re: [linux-audio-dev] light C++ set for WAV
Chris Cannam wrote: > On Wednesday 26 Jul 2006 11:12, Florian Paul Schmidt wrote: > > Well, it is very thin though. Which is not a bad thing at all. One could > > make ue of an arbitrary amount of more advanced C++ features if desired > > though (i.e. templates parametrized with the type you want to read for > > example, or operator<< and operator>> for reading and writing, etc.) > > operator<< and >>... ugh. Yeah I really gotta agree here. Overloading the left and right shift operators has got to the thing I find most distasteful about C++. > I think if your class is named LikeThis, then your method should be named > likeThat (Java-style). If your method is named like_this, then your class > should be named like_that (STL-style). Either is fine, but don't mix your > dialects. Ok, "don't mix dialects" is a good tip. Most of the proposed methods for the Sndfile class have single word names so Java style might be the best option. > Mmm. For what it's worth, I write mostly C++ but have no problem > with using the libsndfile C API. Most people who really know C++ know enough to be comfortable with pure C. I'm pretty sure you fall into this category. However, I do get emails from some of the more clueless Windiots complaining that libsndfile is written in old-fashioned C instead of nice shiny modern C++. IMNSHO these people should not be allowed anywhere near a language as complex, subtle, and unforgiving as C++ (or for that matter as unforgiving as C). Erik -- +---+ Erik de Castro Lopo +---+ "I consider C++ the most significant technical hazard to the survival of your project and do so without apologies." -- Alistair Cockburn
Re: [linux-audio-dev] light C++ set for WAV
Taybin Rutkin wrote: > On Jul 13, 2006, at 4:48 PM, Erik de Castro Lopo wrote: > > > > > I have for some time been looking for someone to write a > > lightweight C++ wrapper for libsndfile that I can distribute > > with libsndfile. > > > > My own rather feeble first attempt is here: > > > > http://www.mega-nerd.com/tmp/sndfile.hh > > > > but I am not a fan nor a great user of C++. The wrapper should > > really be written by someone with a love for the language. > > I use C++ a lot, and I gotta say, this wrapper isn't bad at all. I > prefer lower case method names, but that's about it. Oh, cool, a response at last :-). Well first off, it isn't quite complete and it hasn't been properly tested either. Secondly, with regard to the method names, which do you prefer: - OpenRead - openRead - open_read - something else Since you're the only person who actually responded to the real meat of my email, I have to assume that you are the only person on this list with a love for C++ and hence the only one who should have any real input on this issue ;-). And what you and I come up with the Windiots will have to live with :-). Erik -- +---+ Erik de Castro Lopo +---+ "The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code." -- Paul Graham
Re: [linux-audio-dev] [OT] Language fanboys [was Re: light C++ set for WAV]
Paul Coccoli wrote: > You pretty much can't ever ask something about C++ without all the > haters coming out. C++ has more big ugly warts that any other language I can think of. > I've worked professionally using only C++ (and a little plain old C) > for 8 years, and the last 6 have been exclusively on Linux. Ocaml may > be programming nirvana, but it likely won't pay the bills, I'm currently using Ocaml at work, but I also do C, C++, C#, Python Actionscript and Verilog. I also have a friend who is doing a whole bunch of distributed processing using Erlang, a language which is on my "to learn" list. I'm not so much a specific language fanboy as a languages fanboy. There are so many languages out there that are outside the C, C++, Java and C# bucket that offer features that people in the C/C++/Java/C# camp don't even know about. > so I won't be spending any time on it. Thats your choice, but 6 months learning Ocaml taught me more about programming than I learned in the previous 5 years of a 10 plus year programming career. Being open to new tools, languages and techniques means that my employer now considers me the guy who can be relied on to fix anything that is actually fixable, regardless of whether I've used it before. Erik -- +-------+ Erik de Castro Lopo +---+ Java sucks. C sucks slightly less so, but only because it makes no pretense at all about being a high level language.
Re: [linux-audio-dev] Re: light C++ set for WAV
Loki Davison wrote: > There are quite a few c++ 'not fans' on LAD. C and python all the way ;) I used to be a Python fan but for anything larger than a couple of hundred lines I now prefer Ocaml. Erik -- +-------+ Erik de Castro Lopo +---+ "Data is not information, Information is not knowledge, Knowledge is not understanding, Understanding is not wisdom." -- Clifford Stoll
Re: [linux-audio-dev] memory-mapped wav files
Stephen Sinclair wrote: > > asked about linus said "i know and i intend to keep it that > > way" (paraphrasing). > > ah. > i take it it's not a good idea then.. ;-) > thanks for the answers, they were informative. The other good thing about this is that once you give up mem-mapping you can just use libsndfile and have a bunch of different file formats other than WAV. Erik -- +-------+ Erik de Castro Lopo +---+ GPLG GPLGPLGP GPLGPLGPLGP GPLGP GPL MICROSOFT GPLGP GPLGPLGPLGP GPLGPLGPL GPLGPL
Re: [linux-audio-dev] light C++ set for WAV
Paul Davis wrote: > LOL! that's pretty great. "not a fan" translates in real world terms > into "one of LAD's most persistent critics of almost every aspect of C+ > +" :)) rock on erik, we love you anyway! Aww shucks Paul. I'm blushing :-). Maybe I should start pimping Ocaml here except that I would be the first to agre that Ocaml is really not suited to audio work :-(. Anyway, for Ocaml pimping people can read my blog: http://www.mega-nerd.com/erikd/Blog/CodeHacking/Ocaml/index.html Cheers, Erik -- +-----------+ Erik de Castro Lopo +---+ Oh my god! They killed init! You bastards!
Re: [linux-audio-dev] light C++ set for WAV
Fons Adriaensen wrote: > On Thu, Jul 13, 2006 at 09:56:58PM +0400, Andrew Gaydenko wrote: > > > I mean some minimal C++ class set like: WavFile, WavHeader, WavFrame with > > few apparent methods (open/close, read/write frame(s)). > > Libsndsfile is plain C, but will do what you want without any fuss. > You could write a WAV specific C++ wrapper on top of this in a few minutes. I have for some time been looking for someone to write a lightweight C++ wrapper for libsndfile that I can distribute with libsndfile. My own rather feeble first attempt is here: http://www.mega-nerd.com/tmp/sndfile.hh but I am not a fan nor a great user of C++. The wrapper should really be written by someone with a love for the language. Erik -- +-------+ Erik de Castro Lopo +---+ "An older MS internal whitepaper from August 2000 on switching Hotmail, which MS acquired in 1997, from front-end servers running FreeBSD and back-end database servers running Solaris to a whole farm running Win2K, reads like a veritable sales brochure for UNIX" -- http://www.theregister.co.uk/content/4/28226.html
Re: [Jackit-devel] [linux-audio-dev] What valgrind says
Lee Revell wrote: > I have not looked closely at the code, but could it be considered an > information leak if you're using a byte of unitialized data? If that data is an automatic (ie stack) variable, then yes. Erik -- +---+ Erik de Castro Lopo +---+ "We must not forget that Allah's rules have to be established in all lands." -- Imam Muzammil H. Siddiqi of the Islamic Society of North America
Re: [Jackit-devel] [linux-audio-dev] What valgrind says
Paul Davis wrote: > they don't matter. they are the result of writing a byte to a FIFO to > wake up an(other) client. the contents of the byte do not make any > difference at any point. Regardless of whether this is a bug or not it would be really nice if this could be fixed. Fixing it means that other people valgrinding their apps which use the Jack libs don't see warnings about Jack. Erik -- +-------+ Erik de Castro Lopo +---+ "Christianity has a nasty habit of ignoring the major problems of our time, including overpopulation and exhaustion of resources, because they aren't mentioned in the Bible." -- Paula L. Craig -- +-----------+ Erik de Castro Lopo +---+ "War is deceit." -- Islam's prophet Mohammed (Hadith 4:268)
Re: [linux-audio-dev] Re: Writing a winner takes it all gain filter.
Alex Polite wrote: > On 6/16/06, Bill Schottstaedt <[EMAIL PROTECTED]> wrote: > > Why do you say sndlib is "poorly maintained"? I did not get any > > bug reports that I remember. > > Sorry. That should have been libsndfile What do you mean about libsndfile being poorly maintained? Erik -- +-----------+ Erik de Castro Lopo +---+ Fundamentalist : Someone who is colour blind and yet wants everyone else to see the world with the same lack of colour.
Re: [linux-audio-dev] [ANN] aubio 0.3.0
karsten wiese wrote: > yes, given how AUBIO_MEMSET ist defined: > #define AUBIO_MEMSET(_dst,_src,_t) memset(_dst,_src,sizeof(_t)) > > before the patch above example would expand to > memset(&sfinfo, 0, sizeof(sizeof (sfinfo))); > which becomes > memset(&sfinfo, 0, sizeof(size_t)); > what is not what we want here:-) A of course! I missed that. I therefore repeat my suggestion that having a macro which has a name similar to that of an ISO C standard function but diffrent behaviour is a really bad idea. Erik -- +-----------+ Erik de Castro Lopo +---+ "We have fifty million Muslims in Europe. There are signs that Allah will grant Islam victory in Europe - without swords, without guns, without conquests. The fifty million Muslims of Europe will turn it into a Muslim continent within a few decades." -- Libyan leader Mu'ammar Al-Qadhafi http://www.memritv.org/Transcript.asp?P1=1121
Re: [linux-audio-dev] [ANN] aubio 0.3.0
Paul Brossier wrote:
> On Fri, May 26, 2006 at 10:25:57PM +1000, Erik de Castro Lopo wrote:
> > karsten wiese wrote:
> >
> > > >
> > > > As usual, the source code can be found at http://aubio.piem.org/ ,
> > > > and Debian packages are available from http://piem.org/debian/ .
> >
> > Errm, this looks really weird.
> >
> > @@ -41,7 +41,7 @@
> > aubio_sndfile_t * new_aubio_sndfile_ro(const char* outputname) {
> > aubio_sndfile_t * f = AUBIO_NEW(aubio_sndfile_t);
> > SF_INFO sfinfo;
> > -AUBIO_MEMSET(&sfinfo, 0, sizeof (sfinfo));
> > +AUBIO_MEMSET(&sfinfo, 0, sfinfo);
> > sfinfo.format = 0;
> >
> > f->handle = sf_open (outputname, SFM_READ, &sfinfo);
> >
> > Are you sure you don't have diff direction wrong?
>
> no, stefan's patch is correct. the macro reads:
>
> #define AUBIO_MEMSET(_dst,_src,_t) memset(_dst,_src,sizeof(_t))
What compiler are you using that didn't call
SF_INFO sfinfo;
memset (&sfinfo, 0, sfinfo) ;
an error? Even without any warnings turned on, gcc-3.3 and gcc-4.0
refuse to compile this and give an error "incompatible type for
argument 3 of `memset'".
> this also explains the 'strange'
> sndfile behavior i found on powerpc, wrongly 'fixed' with the
> sfinfo.format = 0 line.
No it doesn't. Every compiler I can find refuses to compile the
above line because it simply doesn't make sense.
Erik
--
+---+
Erik de Castro Lopo
+---+
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
Re: [linux-audio-dev] compiler problem?
Gene Heskett wrote: > Greetings; > > Since I can't get any of the common VoIP things to work due to a lack of > duplex function in my lappy's chipset, and my inability to convince the > person bugtrack assigned to my bugzilla entry that its not my fault, I > thought I'd try zfone next. > > Unforch, the first step, ./configure, fails with 2 stanza's of this: > checking linux/byteorder/little_endian.h usability... no > checking linux/byteorder/little_endian.h presence... yes > configure: WARNING: linux/byteorder/little_endian.h: present but cannot > be compiled Is this a device driver or a user space program. Basically no user space program other than libc should be using kernel header files. Erik -- +-----------+ Erik de Castro Lopo +---+ `[Microsoft] are in the business of giving customers exactly what they ask for, which sounds like a nice idea until you realize that most Microsoft customers are idiots.' --- Eugene O'Neil on comp.os.linux.development.system
Re: [linux-audio-dev] [ANN] aubio 0.3.0
karsten wiese wrote:
> >
> > As usual, the source code can be found at http://aubio.piem.org/ ,
> > and Debian packages are available from http://piem.org/debian/ .
Errm, this looks really weird.
@@ -41,7 +41,7 @@
aubio_sndfile_t * new_aubio_sndfile_ro(const char* outputname) {
aubio_sndfile_t * f = AUBIO_NEW(aubio_sndfile_t);
SF_INFO sfinfo;
-AUBIO_MEMSET(&sfinfo, 0, sizeof (sfinfo));
+AUBIO_MEMSET(&sfinfo, 0, sfinfo);
sfinfo.format = 0;
f->handle = sf_open (outputname, SFM_READ, &sfinfo);
Are you sure you don't have diff direction wrong?
If you have a macro called X_MEMSET with very similar arguments
to the standard C function, the macro should have the same
symanics as the function it wraps. If you don't, you will confuse
people.
Erik
--
+-------+
Erik de Castro Lopo
+---+
"Lumping configuration data, security data, kernel tuning parameters,
etc. into one monstrous fragile binary data structure is really dumb."
- David F. Skoll
Re: [linux-audio-dev] all-purpose xplatform audio decoding library?
Leonard \ wrote: > http://www.mega-nerd.com/libsndfile/ > no ogg support Ogg support has been "in progress" for about 2 years now: http://www.metadecks.org/software/libsndfile/ Feel free to ping Conrad Parker about this. Erik -- +-------+ Erik de Castro Lopo +---+ "Being completely naked during the act of coitus annuls the marriage." -- Rashad Hassan Khalil, a former dean of Al-Azhar University's faculty of Sharia (or Islamic law)
Re: [linux-audio-dev] libsndfile and WAVEX
Alfons Adriaensen wrote:
> You obviously need access to the channelmask when reading or creating
> multichannel files.
>
> As to the GUID, there are e.g. special GUIDs for Ambisonics files,
> see <http://dream.cs.bath.ac.uk/researchdev/wave-ex/bformat.html>.
>
> BTW I don't understand the relation between the definition of
> the GUIDs on that page
>
> SUBTYPE_AMBISONIC_B_FORMAT_PCM {0001-0721-11d3-8644-C8C1CA00}
> SUBTYPE_AMBISONIC_B_FORMAT_IEEE_FLOAT {0003-0721-11d3-8644-C8C1CA00}
>
> and the example representation of the first one further down:
>
> {0x0001,0x,0x0010, {0x80,0x00, 0x00,0xaa,0x00,0x38, 0x9b, 0x71}}
>
> Does it make sense to you ?
Sorry, no it doesn't. Thats why I suggested joining the libsndfile-devel
list.
I didn't implement the WAVEX stuff. The guy who did is on the libsndfile-devel
list but not on this one.
Erik
--
+---+
Erik de Castro Lopo
+---+
"I invented the term Object-Oriented, and I can tell you I
did not have C++ in mind." -- Alan Kay
Re: [linux-audio-dev] libsndfile and WAVEX
Alfons Adriaensen wrote: > I've gone through the docs a number of times, but can't find > a way to read / write the channelmask and guid in a WAVEFORMAT > extensible file. I thought the guid was determined by the data encoding ie once you decide to write PCM data, you have to use a specific guid. > Is it possible ? Not currently. If you want to discuss this further maybe you should bring it up on the libnsndfile-devel list: http://www.mega-nerd.com/libsndfile/lists.html Erik -- +-----------+ Erik de Castro Lopo +---+ "I could never learn to use C++, because of the completely overwhelming desire to redesign the language every time I tried to use it, but this is the normal, healthy reaction to C++." -- Erik Naggum
Re: [linux-audio-dev] fast linear resampling on ARM - suggestions?
Andrew!!! How's life post-Farilight? What are you up to now? Maybe off list :-). Andrew Cannon wrote: > I suggest using a Kaiser-window based interpolation algorithm. This is > the best filter method to use for sample rate conversion. You can get > decent results with 8 taps or even fewer. For example you can get a 6dB > bandwidth of about 2.8kHz (at Fs=8kHz) with 50dB alias rejection. (of > course you need more taps for high-quality results) By way of comparison, the fastest of my three sinc based converters has a 3dB bandwidth of 3.2kHz with reference to Fs of 8kHz. Erik -- +-----------+ Erik de Castro Lopo +---+ "A mouse is a device used to point at the xterm you want to type in." -- Kim Alm, a.s.r
Re: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
Stefan Westerfeld wrote: > First algorithm: upsample by factor 2 (you can use my code as it is), > then use linear interpolation. Why this is better than plain linear > interpolation? Because low frequency signals can be better approximated > by lines than high frequency signals, and after upsampling by factor 2 > your signals will tend to be low frequency signals. > > Second algorithm: perform factor N upsampling (for instance factor 16 > upsampling), then use linear interpolation. The quality should become > even better. The performance will not suck as badly as "factor 16 > upsampling" sounds, because you only need to compute those sample values > that you need to do linear interpolation. Upsampling followed by linear resampling can be a good approach. Linear resampling can produce high quality results if you can guarantee that the input signal is strictly band limited well below half the sample rate. I even have some rough figures for this on page 11 of this paper which was given at the Audio Miniconf attached to 2005 Linux.conf.au : http://www.mega-nerd.com/tmp/secret_rabbit_code.pdf For the case of upsampling from 44100Hz to 48000Hz, with the source signal consisting of a single sine wave, I got the following SNR values: Sine FreqSignal to Noise ratio 333 Hz146.0 dB 666 Hz115.8 dB 1332 Hz103.8 dB 2664 Hz 49.8 dB 5328 Hz 38.7 dB 10656 Hz 28.4 dB 21312 Hz 19.5 dB However, beware that the upsample followed by linear resampling will only work correctly when the output sample rate is greater than the input sample rate. When this is not the case, extra filtering is needed on the input side which complicates things somewhat. > As for quality, I'd really like to know what quality can be attained by > this approach at what speed. Could it even outperform libsrc on both, > quality and performance, under some circumstances? Linear resampling can outperfrom the best resampler in libsamplerate under some conditions. That still doesn't make linear resampling a good idea unless you can be 100% sure that your data *always* fits the specific conditions where linear resampling performs well. I'll say it again, libsamplerate is a *general purpose* resampler. For any pair of constant input and output sample rates, it has a well specified worst case behaviour of greater than 96 db SNR. On top of that, it *also* handles the case where the ratio between input and output sample rates is not constant. Erik -- +-------+ Erik de Castro Lopo +---+ "Unix and C are the ultimate computer viruses." -- Richard P Gabriel
Re: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
Stefan Westerfeld wrote: > Measuring the same example with libsamplerate with SRC_SINC_FASTEST > gives a throughput of 1233140 samples/second, which means that my code > is about 41 times faster. Are you comparing apples to apples here? What is the bandwidth of your resampler? >From the comments in the code it seems that your resampler is not an abritrary resampler like mine but an 2 times upsampler. Its not really a fair comparison to compare a general time varying resampler like mine to a 2 times upsampler. Erik -- +-------+ Erik de Castro Lopo +---+ Pastafarianism : http://www.venganza.org/ The intelligent alternative to 'Intelligent Design'.
Re: [linux-audio-dev] Re: fast linear resampling on ARM - suggestions?
Kjetil S. Matheussen wrote: > Don't get me wrong, I appreciate your work very much, but this > particular issue is irritating. There are situations where linear > resampling is useful, for example when resampling xx sounds at once. I'm rather busy, but I'll have a look at it. Erik -- +-----------+ Erik de Castro Lopo +---+ The Myth of Islamic Tolerance http://answering-islam.org.uk/Shamoun/badawi_tolerance.htm
Re: [linux-audio-dev] Re: fast linear resampling on ARM - suggestions?
Kjetil S. Matheussen wrote: > Was this with the linear resampler lib libsamplerate? In case, you should > know that its terrible slow. Last time I tried, the fastest sinc resampler > in CLM was almost as fast as the linear resampler in libsamplerate. > (Erik, you should do something about that...) Maybe I haven't made myself clear. IMHO linear resampling sucks for audio. It is included in libsamplerate purely so I can show how bad it actually is. Erik -- +-------+ Erik de Castro Lopo +---+ "I do have a policy of mandatory evisceration where the crime of whitespace in filenames is perpetrated on my systems. This has inspired a new range of designer colostomy bag covers in corduroy, velvet, and the ever popular denim." -- jdub on the SLUG mailing list
Re: [linux-audio-dev] linear resampling is crap ? (was: fast linear resampling on ARM - suggestions?)
[EMAIL PROTECTED] wrote: > On Wed, Mar 29, 2006 at 11:47:30PM +1000, Erik de Castro Lopo wrote: > > Tobias Scharnberg wrote: > > > > However, please do not use linear resampling; its just too crappy. > > urgh... i just switched my local copies of alsa_in and _out to linear > resampling, because SRC_SINC_FASTEST was eating CPU juice. Just out of curiosity, what kind of hardware are you running this on and what sort of performance would you find acceptable for your application. An estimate that provides: - input and output sample rates - samples per second per channel throughput wrt the output rate would give me the best idea of what you are after. Erik -- +-----------+ Erik de Castro Lopo +---+ Question #2459: Ruling on shaking hands with the opposite sex http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=2459&dgn=4
Re: [linux-audio-dev] fast linear resampling on ARM - suggestions?
Tobias Scharnberg wrote: > Hello List, > I'm trying to find a library or code-snippet in order to do audio > resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to > resample the data in realtime - resampling a buffer of data, not a > soundfile. The quality doesn't need to be good so I guess the best > solution might be linear audio resampling. The device to do the > resampling on is an ARM CM-X255 running at 400MHz. > > I tried out libsamplerate so far but when I tested it with the > soundfile conversion test program it needed 3,5 secs to sample from > 8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me. libsamplerate uses floating point calculations and most ARM CPUs don't have an FPU. Julius O. Smith's original resample program used integer arithmetic and would therefore be a better choice. However, please do not use linear resampling; its just too crappy. Erik -- +-----------+ Erik de Castro Lopo +---+ "I have never met anyone who can do Scheme, Haskell, and C pointers who can't pick up Java in two days, and create better Java code than people with five years of experience in Java." -- http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
Re: [linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.9rc1
fons adriaensen wrote: > OK, but for floats the situation could be more complex. In libsndfile I use a 32 bit end swapper on floats and a 64 bit endswapper on doubles. > Will either rule produce consistent results on all > platforms ? The above does produce consistent results across platforms (tested on x86, ia64, ppc and mips). Erik -- +---+ Erik de Castro Lopo +---+ Oh my god! They killed init! You bastards!
Re: [linux-audio-dev] Re: Which widgets?
Albert Graef wrote: > /me wrote: > > To make this thread go totally off-topic, here's the same in Q: > > Sorry, I forgot one equation: > > intersect Xs [] = []; > intersect Xs [Y|Ys] = [Y|intersect Xs Ys] if any (=Y) Xs; > = intersect Xs Ys otherwise; Ah yeah, like Haskell and Erlang would do it. I do prefer the Ocaml way :-) Erik -- +-----------+ Erik de Castro Lopo +---+ "Perl as a language has less a design than a thousand special features flying in close formation." -- From the c2 wiki
Re: [linux-audio-dev] Re: Which widgets?
Carlo Capocasa wrote: > > > Ah, the sign of a good programmer. :) > > There are actually people who still count, when > > for (int i=0;i cout << i << endl; Shouldn't you put parentheses around on or the other of those left shift operators? :-) > is in itself a work of pristine beauty, immense practicality, and you > can spend a lot of time lying around while the machine approaches n. If you want pristine beauty, you should have a look the function to find the intersection of two lists in Ocaml: let rec intersect lst = function [] -> [] | head :: tail -> if List.mem head lst then head :: intersect lst tail else intersect lst tail Erik -- +-----------+ Erik de Castro Lopo +---+ "They should make peace with those who make peace, and wage war against those who wage war, and wage jihad against those who stand in the way of spreading the message of Islam and causing it to prevail of earth." http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=26721&dgn=4
Re: [linux-audio-dev] Which widgets?
[EMAIL PROTECTED] wrote:
> I'd prefer not to have to move my app from C to
> C++ just to implement the interface, so that's quite a few out of the
> window.
I'm sure that I dislike C++ even more than you do and I can completely
understand why you'd want to keep you app as C.
However, GUIs is actually one of the few applications where IMHO
C++ may actually have some benefits over C. It would definitely
be possible to do a C++ GUI which communicates with a C backend
but it would be necessay place a clothes peg over one's nose
while doing the C++ stuff.
That said, I have done GUIs in GTK+ (which is C) and it is doable,
especially if you spend some time wrapping the the GTK+ trivialities
into something more managable. So for instance, it you need 5 buttons
that are basically the same bar button names etc, instead of doing
button1 = gtk_new_button("button1 name") ;
gtk_fiddle_with (button1) ;
button2 = gtk_new_button("button1 name") ;
gtk_fiddle_with (button2) ;
...
button5 = gtk_new_button("button1 name") ;
gtk_fiddle_with (button5) ;
do something like:
struct button_s
{ const char * name ;
int xpos, ypos, xsize, ysize ;
} ;
static struct button_s deez_buttons [] =
{ { "button1_name", 0, 0, 20, 20 },
{ "button2_name", 0, 0, 20, 20 },
{ "button3_name", 0, 0, 20, 20 },
{ "button4_name", 0, 0, 20, 20 },
{ "button5_name", 0, 0, 20, 20 }
} ;
and then write a function that takes an array of button_s structs
and does whatever is required to make them happen.
I also like to have all button messages pass back through one
callback. Each button will have a unique identifier so that in
the callback I can just switch on the button identifier.
This can easily be extended to have all GUI callbacks passing
through the one callback function and them make the whole thing
a model controller view thing.
> I don't really want huge dependencies for a knob, text box and a
> button, either.
Most GUI widget toolkits have a huge set of dependancies regardless :-).
GTK+ is no different in this regard.
> And something that's installed as default in most distros would be
> good, too.
GTK+ is shipped with most distros.
Erik
--
+---+
Erik de Castro Lopo
+---+
"Perl as a language has less a design than a thousand special features
flying in close formation."
-- From the c2 wiki
Re: [linux-audio-dev] xt2 coming to linux
Lee Revell wrote: > The Linux kernel is a GPL'ed application yet Nvidia gets away with > linking into it. It's widely acknowledged to be illegal, but as the > linking is done by the end user, it's the user who violates the GPL, not > Nvidia. The end user would only be violating the GPL if they distributed the kernel with the Nvidia kernel. The GPL bestows more freedom to the user than it does to the distributor of GPL software. Erik -- +-------+ Erik de Castro Lopo +---+ "Allaah has forbidden the believers to take the kaafireen (disbelievers) as friends, and He has issued a stern warning against doing that." -- http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=59879&dgn=4
Re: [linux-audio-dev] libsamplerate question
David wrote: > Yes, so what is the cleanest : malloc'ing an additionnal frame and not > filling it or loosing a frame of data that should have come from the > SRC ? It realy doesn't make much difference. Feel free to do as you like :-). Erik -- +-------+ Erik de Castro Lopo +---+ "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" -- Tom Cargill
Re: [linux-audio-dev] libsamplerate question
David wrote: > I process my input data in one pass using src_simple() and I have to > compute the length of the output data buffer beforehand. So I did > somehting like this : > > out_len = (long int) ceil((double) in_len * ratio); > > It seems that my output buffer is always one frame too big (I checked > this by reading the output_frames_gen field of the SRC_DATA structure > after the processing is done). > > Is it safe to assume that using floor() instead of ceil() will not lead > to a too short output buffer in some cases ? The most you should ever loose is one sample. In addition, src_simple will not write beyond the length of the output buffer length that you specify in the output_frames field. Erik -- +-----------+ Erik de Castro Lopo +---+ "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -- Alan Kay
Re: [linux-audio-dev] Additional chunks in WAV files with libsndfile ?
fons adriaensen wrote: > Would it ? It solves the problem, and all other apps will - or > at least _should_ according to the WAV spec - just ignore it. > What problems would be created by adding a new chunk ? > The alternative would be a format that isn't standard at all. The problems are as follows: - There are many very broken WAV (and AIFF) file parsers. - There is no central registry of the chunk names and hence your chunk name may colide with a current or future chunk name defined by someone else. > > http://www.mega-nerd.com/libsndfile/api.html#string > > Yes, been there before I posted. It's probably a matter of taste, > but I don't find this much cleaner than adding a new chunk. It has the advantage of being robuts, future proof and usable now. Erik -- +-----------+ Erik de Castro Lopo +---+ C++: The power, elegance and simplicity of a hand grenade.
Re: [linux-audio-dev] Additional chunks in WAV files with libsndfile ?
fons adriaensen wrote: > Hi all, > > is there a recommended way to write / read additional chunks in > WAV files, using libsndfile (assuming it's possible at all - I > didn't find any hints to this in the docs) ? libsndfile already supports the addition of a number of specific chunk types like PEAK, strings in the INFO chunk etc. > What I need in particular is some way to calibrate the time > axis - i.e. to say frame #N corresponds to t = 0, and some > other similar info, mostly sample indices. There is no existing chunk type which does what you require. In addition, it would be a bad idea to define your own custom chunk type to do this. However, it would be possible to add a comment string containing the data you require as a text string. See: http://www.mega-nerd.com/libsndfile/api.html#string HTH, Erik -- +-----------+ Erik de Castro Lopo +---+ "The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code." -- Paul Graham
Re: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type
Frank Barknecht wrote: > You mean Steve, right? Yeah I do. Sorry Steve :-). > Ubuntu seriously lags behind (0.18), as unfortunatly seems to be the > norm with many packages I would be interested in. > > (Btw: Does anyone know the smoothest way to upgrade Ubuntu Breezy to > Debian testing? I'd like to get rid of U. on my laptop soon and run a > Real Programmer's Debian there as on my other machines.) I'm running Breezy too, and I just compiled the liblo package from Dapper and installed that. What you do is: - Go to your local Ubuntu mirror site. - Find /ubuntu/pool/universe/libl/liblo/ - Grab the three files: liblo_0.22-1.dsc liblo_0.22-1.diff.gz liblo_0.22.orig.tar.gz - Then do: dpkg-source -x liblo_0.22-1.dsc cd liblo-0.22/ dpkg-buildpackage -rfakeroot -b -uc cd .. sudo dpkg -i liblo*.deb And you're done. Probably a bit easier than converting your machine to Debian testing :-). Erik -- +-----------+ Erik de Castro Lopo +---+ "Do I do everything in C++ and teach a course in advanced swearing?" -- David Beazley at IPC8, on choosing a language for teaching
Re: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type
Frank Barknecht wrote: > Hallo, > > while trying to build Dave Griffith's fluxus, which uses liblo, on > Debian, I've hit a very strange error. It boils down to g++ not > finding the symbols exported in lo/lo.h. I stripped down the code, > where it fails to this supershort C++-file: Check your version of liblo. The version in Debian (even testing) and Ubuntu is a bit behibd what Dave has on his web site. Cheers, Erik -- +-----------+ Erik de Castro Lopo +---+ "They should make peace with those who make peace, and wage war against those who wage war, and wage jihad against those who stand in the way of spreading the message of Islam and causing it to prevail of earth." http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=26721&dgn=4
Re: [linux-audio-dev] Olypus voice recorder - codec?
David Santinoli wrote: > AFAICT the encoding should be (Adaptive Differential Pulse Code > Modulation). Don't know about the file container though... There are at least 50 different, mutually incompatible types of ADPCM. For instance, libsndfile supports: SF_FORMAT_IMA_ADPCM /* IMA ADPCM. */ SF_FORMAT_MS_ADPCM /* Microsoft ADPCM. */ SF_FORMAT_VOX_ADPCM /* OKI / Dialogix ADPCM */ SF_FORMAT_G721_32 /* 32kbs G721 ADPCM encoding. */ SF_FORMAT_G723_24 /* 24kbs G723 ADPCM encoding. */ SF_FORMAT_G723_40 /* 40kbs G723 ADPCM encoding. */ which is a mere drop in the bucket. Erik -- +---+ Erik de Castro Lopo +---+ Question #2459: Ruling on shaking hands with the opposite sex http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=2459&dgn=4
Re: [linux-audio-dev] dealing with complex numbers
Artemiy Pavlov wrote: > Hey everybody! > > This may be a little bit off-topic, but can anyone suggest me any reading on > how to use complex numbers in C or C++? Is there any library or ++ classes > for such computations? In C++: #include which is a template clase. You can then do: typedef std::complex dcomplex ; Erik -- +-------+ Erik de Castro Lopo +---+ Open Source and Free Software means that you never sacrifice quality of the code for meeting deadlines set up by people not participating directly in the software development process.
Re: [linux-audio-dev] Old tracks finaly recorded and mastered
Thorsten Wilms wrote: > The only problem was having to convert the 32bit float WAVs to > 16 bit for lame, as it doesn't recognize that format. There was a version of LAME that used the 0.0.X series of libsndfile for file I/O. I don't know hat happened to that. Its pretty trivial to update that code to use 1.0.X libsndfile. > I used > sndfile-convert for that. Too bad it doesn't take a flag for > the output format, but requires filenames for that. sndfile-convert understands -pcm16, -pcm24 and others. It only uses the file extension to figure out the desination file's container type (AU, AIFF, WAV etc). Erik -- +-------+ Erik de Castro Lopo +---+ "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp." -- Greenspuns Tenth Rule Of Programming
Re: [linux-audio-dev] Sound file format detection?
Mario Lang wrote: > Erik de Castro Lopo <[EMAIL PROTECTED]> writes: > > > BTW, the latest release of libsndfile supports FLAC via the same API > > as all the other formats. > > GREAT!!! I was s waiting for this! So now I'll be able to read > flac files in SuperCollider. > Now, if libsndfile only would do vorbis and mp3 too, I could just > use it as the backend for everything. Vorbis is coming. MP3 won't happen because of the legal issue surrounding MP3. Erik -- +-----------+ Erik de Castro Lopo +---+ Journalist: Microsoft CEO Steve Ballmer has finally said Linux is the No. 1 threat to Windows. What's your response to that? Linus : "Tag, you're it." I don't care. They've had a lot of enemies in their time. Let them fight one enemy that doesn't care for a change.
Re: [linux-audio-dev] Sound file format detection?
carmen wrote: > > I currently just blindly try to launch the decoder for either ogg, speex or > > mp3 in series. I'd like to add flac... > > a simple way - how about assuming files are properly named, eg theres no files > matching *.ogg which are actually .wav format? No, but Ogg is a container format and may contain audio data encoded as Vorbis, Speex or Flac. > it would be great if there was truly one solution to this, on Mac you just > use coreaudio API, on windows, you use ACM codec, but it seems each linux > app has to independently support and depend on flac/ogg/speex/wav/etc libs, > ad nauseum.. Yes, thats braindamaged. However, libsndfile now supports FLAC and work on Ogg Vorbis and Ogg Speex is underway. Erik -- +-----------+ Erik de Castro Lopo +---+ Linux, the UNIX defragmentation tool.
Re: [linux-audio-dev] Sound file format detection?
Mario Lang wrote: > Hi. > > My little time-compressing audio player yatm currently supports 3 different > audio formats, ogg and speex via the xiph libraries, and mpeg via libmad. > I currently just blindly try to launch the decoder for either ogg, speex or > mp3 in series. SO if the first fails, I try the second, and so on. Which > kinda works but is a bit ugly. I'd like to add flac support at some point, > which would make this even more ugly. > Additionally, libsndfile support wouldnt be that bad either, so, I am > wondering, is there a reliable way to detect a audio streams file > format just given some bits of the header? For the vast majority of file formats yes. > So that I could set the > appropriate decoder algorithm based on that analysis? Or is > there actually a library one step higher level than libsndfile which > does generic audioformat to PCM? Isn't that what libsndfile does? BTW, the latest release of libsndfile supports FLAC via the same API as all the other formats. Erik -- +-------+ Erik de Castro Lopo +---+ Spammer: Any of you guys looking for a permanent position in Scotland? Kaz Kylheku: No, I'm looking for a thug in Scotland who might be interested in beating up off-topic Usenet spammers, on a pro bono basis.
[linux-audio-dev] The Erik travelling roadshow
Hi all, I'm just about to go on holidays with my family. While I'm away I will have a little time here and there to meet up with some friendly linux audio types. I'm be in the following places on the following dates: London UK2-16 Oct Newcastle UK 16-19 Oct Copenhagen DK19-26 Oct Anyone who would like to meet up for coffee or a beer or something should email me at erikd AT my usual domain name. I'm up for a chat or being dragged along to a Linux user group type function. Cheers, Erik -- +-----------+ Erik de Castro Lopo +---+ "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" -- Tom Cargill
Re: [linux-audio-dev] convenient ogg vorbis wrapper
Richard Spindler wrote: > Hi, > > I'm looking for a convenient wrapper library for ogg vorbis, because > what I've found on the xiph.org pages looks a little overengineered to > me. > > I've used libsndfile most of the time, so this is the API Style that > I'd prefer, basically I need 4 functions I believe: Conrad Parker has been working on adding Ogg Vorbis and Speex support to libsndfile. Its been very close to working for some time now :-). Erik -- +-----------+ Erik de Castro Lopo +---+ "C++ has its place in the history of programming languages. Just as Caligula has his place in the history of the Roman Empire." -- Robert Firth
Re: [linux-audio-dev] OT: Licensing conflict
Christoph Eckert wrote: > Hi all, > > > > I just started to learn some C++. Currently I'm working on some Qt MIDI > tools. > > I've found some code which makes life for me much easier. The code is > licensed under a MIT license and can be found here: > > http://www.music.mcgill.ca/~gary/rtmidi/index.html#license > > > The free Qt version I use is under GPL. > > I wonder if I'm allowed to distribute a Qt application as a GPL > application even if I include the classes mentioned above, or if I need > to implement my MIDI connectivity by myself. According to the FSF, the MIT License (also known as the X11 license) is GPL compatible. See: http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ Oh my god! They killed init! You bastards!
Re: [linux-audio-dev] WAVE-EX File Format Spec
Fred Gleason wrote: > This is pretty much the approach I had in mind. Rivendell is at a crossroads > right now where I need to add two key features: > > Surround-sound support (hence WAVE-EX) WAVE_EX should be working now. If its not, I'm sure that David Veins (who supplied the patch to add it) and I would be happy to fix it. > OggVorbis and OggFLAC FLAC/flac works in a pre-release, and OggFlac is close, but has a couple of bugs that need to be worked out. Same for OggVorbis but that is probably even closer to working. > So, it sounds like this could be a strategic point to make the switch. Would > you accept patches to add BWF functionality? I've accepted patches before. I'll accept them again but I often do ask for minor changes or bash on them myself before they go in. There's a libsndfile-devel mailing list for working on this sort of stuff: http:/www.mega-nerd.com/libsndfile/ If you have a patch to post, don't bother about waiting around to get a feel for the list. Just dump it on us :-). Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "C++ is the only current language making COBOL look good." -- Bertrand Meyer
Re: [linux-audio-dev] WAVE-EX File Format Spec
Fred Gleason wrote: > I've been eyeing Libsndfile for the past couple of years. It looks quite > solid. We've been using the Secret Rabbit for some time now, and are very > pleased with it. The only thing that really has kept us from > enthusiastically adopting Libsndfile as well has been lack of Broadcast Wave > File (BWF) support. I've been extremely busy for some time working on an improved converter for Secret Rabbit Code (as well as life in general). Since the Rabbit actually earns me a modest income it has priority over all other free time coding. When I get a bit of time (yeah right :-)) I'll take a look at the BWF stuff. > Given your > long-standing policy of non-support for MPEG, I was not sure if this was > something you would be interested in adding to libsndfile. MP3 has patent problems. The encoder is patented and the patent holder does send the ocassional nasty-gram to people distributing MP3 codecs without a license. Even if I personally could avoid this issue, having MP3 support in libsndfile may make it impossible for the big Linux distributions to ship libsndfile with their offerings (or at least without stripping the MP3 code). However, since you already have a hardware MPEG codec (where the hardware manufacturer pays the licensing fees), you might want to look at the sf_read_raw/sf_write_raw interfaces: http://www.mega-nerd.com/libsndfile/api.html#raw The warning about reading/writing compressed format being undefined is mainly warning about mixing raw read/writes with standard read/ writes which use libsndfile's internal codecs. This would not be an issue for your case. Maybe we can come up with something that allows you to use your external MPEG codec with libsndfile (time permitting). Erik PS : Libsndfile is very close to having full Ogg Vorbis support (Conrad ???). Would that be enough for you to drop or at least partially replace MP3? -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman
Re: [linux-audio-dev] WAVE-EX File Format Spec
Fred Gleason wrote: > Howdy Folks: > > Would anyone happen to have a link to and/or copy of the WAVE-EX file format > spec handy? I've tried Googling, but closest I come is a (now broken) link > to one of the M$ sites. Searching M$ directly didn't work either. Libsndfile can read/write WAVE-EX files. It uses the SF_FORMAT_WAVEX format type to distinguish it from SF_FORMAT_WAV. http://www.mega-nerd.com/libsndfile/ Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "There are only two things wrong with C++: The initial concept and the implementation." -- Bertrand Meyer
Re: [linux-audio-dev] [OT} : Anyone read Finnish?
Erik de Castro Lopo wrote: > I joined the damn thing and logged in but I can't create a new topic > and I can't relpy to an existing topic. OK, I finally figured this damn thing out :-). > However, I did find an email address for the person who is hosting > the actual binary on his web site. The guy has removed the offending binary and I'm now working on a way to make it possible for foobar2000 users to use a Secret Rabbit Code based resampler and allow me to maintain the dual license and make a small income from this code. Thanks to everyone who responded with help on contacting these websites. Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Java, the best argument for Smalltalk since C++." -- Frank Winkler
Re: [linux-audio-dev] [OT} : Anyone read Finnish?
Alexandre DENIS wrote: > There is a forum dedicated to Foobar2000 3rd Party Plugins at > http://www.hydrogenaudio.org/forums/index.php?showforum=33 OMFG web based forums are fscing *LAME*. > It looks as if it is already used as a medium for communication between > plugins authors and the webmaster of > http://pelit.koillismaa.fi/plugins/dsp.php. I guess you can post a > message on this forum to get into contact with the webmaster of the > offending website. I joined the damn thing and logged in but I can't create a new topic and I can't relpy to an existing topic. However, I did find an email address for the person who is hosting the actual binary on his web site. Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "C++ is a language strongly optimized for liars and people who go by guesswork and ignorance." -- Erik Naggum
[linux-audio-dev] [OT} : Anyone read Finnish?
Hi all, I've got someone violating the license on Secret Rabbit Code. The offending binary-only download is listed here: http://pelit.koillismaa.fi/plugins/dsp.php but I'm having trouble getting a contact email address for pelit.koillismaa.fi and/or koillismaa.fi. I've attempted a whois which directs me to: https://domain.ficora.fi/ but I still can't find an email address. Any help that someone may be able to offer would be appreciated. Cheers, Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ The main confusion about C++ is that its practitioners think it is simultaneously a high and low level language when in reality it is good at neither.
Re: [linux-audio-dev] please help: enumerating library requirements
Leonard \ wrote: > the out-of-the-box ogg vorbis lib e.g. chooses the amount of samples it > dispenses based on the number of frames it had decoded. if you want to read > blockwise, that is: based on a blocksize that _you_ want, you have to chop up > and merge the blocks that the lib gives you. libsndfile does not have this limitation for other file formats (including FLAC) and it won't have it for Ogg either. It looks like libsndfile will be a significantly better API for handling Ogg Vorbis once its finally working :-). Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "The lusers I know are so clueless, that if they were dipped in clue musk and dropped in the middle of pack of horny clues, on clue prom night during clue happy hour, they still couldn't get a clue." --Michael Girdwood, in the monastery
Re: [linux-audio-dev] please help: enumerating library requirements
[EMAIL PROTECTED] wrote: > On Saturday 23 July 2005 00:29, Erik de Castro Lopo wrote: > > then libsndfile does all of the above except 1) and 2) and possibly > > 5). What exactly do you mean by "realtime streaming". > > if 2) is missing that wouldnt hurt. i dont like mp3 anyway. > > realtime streaming means that it should be possible to stream audio in very > small chunks of data e.g. 64 samples per frame. Que? That sounds like a function of the file format not the API. With libsndfile you can read a single frame (1 sample for every channel) or more per read/write. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "OS X is great that way. I put a copy of OS X on my coffee table, and it hasn't been hacked yet. Yes, I am using it as a server. I serve several meals on it every week." -- Anthony Minkoff
Re: [linux-audio-dev] please help: enumerating library requirements
Oliver Frommel wrote: > How much is a license anyway? Way too much for a Free Software developer like me. And how would I recover the costs? > Couldn't the companies > making money off Linux get together and buy like > a general Linux MP3 codec license? Yes, they could but why would they? Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "It's pretty simple. [Large companies are] allowed to own either a content creation empire - a studio or label - or a playback device empire (Walkmans, or PCs). But ... can't have both." -- Andrew Orlowski
Re: [linux-audio-dev] please help: enumerating library requirements
Lars Luthman wrote: > Couldn't someone in a country without software patents code an MP3 write > module that could be distributed as a patch That would never work; the libsndfile internals change often enough to make this impossible. > or separate version of libsndfile? Sure, anyone who wants to could do it. > Although the only reason I can think of for writing MP3s is to export > files to old hardware audio players that don't support Vorbis. Exactly. And anyone on this situation can just use the LAME encoder. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Therapists typically base the nuttiness of a patient on the strength of their convictions, on which basis this 43,000 word opus alone stands as a kind of testament to Bill's (Gates) madness." - The Register
Re: [linux-audio-dev] please help: enumerating library requirements
[EMAIL PROTECTED] wrote: > Audio Codec Host > >1. Should support reading/writing Ogg Vorbis >2. Should support reading/writing Mp3 >3. Should support reading/writing FLAC >4. Should support reading/writing RIFF WAVE (.WAV) >5. Should provide realtime streaming capabilities >6. Should be seekable by sample index >7. Should provide an abstraction that is independent of the format If you are willing to go for a pre-release: http://www.mega-nerd.com/tmp/libsndfile-1.0.12pre10.tar.gz then libsndfile does all of the above except 1) and 2) and possibly 5). What exactly do you mean by "realtime streaming". Ogg Vorbis (as well as Ogg Speex) is being worked on and is pretty close to working (Conrad). Mp3 is problematic because of the MP3 patent issue. I haven't investigated it fully, but I may be able to offer MP3 as a format that can be read but not written. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "The reasonable man adapts himself to the world; the unreasonable one persists to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw (1856-1950)
Re: [linux-audio-dev] Proffessionals?
[EMAIL PROTECTED] wrote: > Hi everyone, > > Can anyone give me any examples of Free audio software being used by > professionals? http://mstation.org/deprogram.php Nick Mainsbridge is a proffessional engineer and producer and uses Ardour and Jack when the session allows it. Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Windows was created to keep stupid people away from UNIX." -- Tom Christiansen
Audio APIs GNOME & KDE (was Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?))
Damon Chaplin wrote: > GNOME & KDE are complete development platforms, so they need to support > the development of audio applications. > > I'm not saying they should develop new libraries. Just that they need to > standardize on particular APIs/libraries that all work together OK. > > (I think both GNOME & KDE are considering switching audio APIs at the > moment, so now is a good time for the linux-audio community to get > involved.) Have you considered Polypaudio: http://0pointer.de/lennart/projects/polypaudio/ The Ubuntu people are looing at replacing ESD with this one. In their scheme, Polypaudio would use ALSA's dmix rather than direct ALSA. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "There is no reason why anyone would want a computer in their home" Ken Olson, DEC, 1977
Re: [linux-audio-dev] Re: Looking for fast integer resampling code
Alfons Adriaensen wrote: > On Mon, Jun 13, 2005 at 10:49:38PM +1000, Erik de Castro Lopo wrote: > > > The SNR and bandwith cannot be determined by reading code. > > Measurement is the only option. > > It's perfectly possible to calculate this, and it isn't even > very difficult. In the case of a sinc filter, everything is > determined by the window on the complete sinc function that > defines your filter, and the ratio of the two sample rates. > > In fact the 'measurement' you describe in the presentation > you referred to is not really a measurement. It is 100% > numerical and there's nothing physical involved. So it's in > fact a long winded way to do the calculation. Yes, but if you meaure the SNR the way I do, you are also ensuring the absence of bugs in the implementation of the algorithm. As you are probably aware, looking at code is not the best way to find bugs in the implementation but testing actually works quite well. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement." -- Drew Olbrich
Re: [linux-audio-dev] Re: Looking for fast integer resampling code
Kjetil Svalastog Matheussen wrote: > I was primarily testing speed, but both libraries where using the sinc > routine, so... Yes, but you can design a sinc filter with 10 coefficients and one with 1. The one with 1 coefficients will have a steeper transition band and a better signal to noise ratio. > When I compaired mus_src with width=5, and libsamplerate with > SRC_SINC_FASTEST, the first one is much faster, I don't know what kind of > SNR/Bandwidth you get with your way of measuring when using mus_src with > width=5, but the source is easy to read so I guess you can figure it out. The SNR and bandwith cannot be determined by reading code. Measurement is the only option. Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "To me C++ seems to be a language that has sacrificed orthogonality and elegance for random expediency." -- Meilir Page-Jones
Re: [linux-audio-dev] Re: Looking for fast integer resampling code
Olivier Guilyardi wrote: > Jackbeat is useful for my composition needs OK, I've had a look at the webpage. Firstly I see that its basically a drum machine. Drum hits are relatively we behaved when linear sample rate converison is used. Secondly, why don't you just do the sample rate conversion on sample load time and sort the converted version in memory. This will mean that you do the conversion once for each drum sound rather than on all tracks all the time? Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" -- Tom Cargill
Re: [linux-audio-dev] Re: Looking for fast integer resampling code
Olivier Guilyardi wrote: > I believe libsamplerate, as a general purpose sample rate conversion library, > should be able to run very fast if needed. After including your library into > Jackbeat (http://www.xung.org/jackbeat) I was pretty sad to see 40% of my > 700Mhz > Duron load dedicated to processing only six tracks with libsamplerate's > SRC_LINEAR converter. Because the quality of linear converters is so poor, I have not even attempted to optimise or even profile it. I notice that it runs about 5 times faster than SRC_SINC_FASTEST and on reflection, it should probably be 20 times faster. However, I really didn't even expect anyone to use SRC_LINEAR. It was added for completeness, to show how bad linear converters are. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "C++ is history repeated as tragedy. Java is history repeated as farce." -- Scott McKay -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Java is, in many ways, C++--." -- Michael Feldman
Re: [linux-audio-dev] Re: Looking for fast integer resampling code
Alfons Adriaensen wrote: > What do you mean by 'signal to noise ratio' of a resample algo ? > I see no reason why it should produce noise, so it's probably not > what the words suggest. All sample rate conversion algorithms produce unwanted artifacts. These artifacts are usually highly correlated with the input signal, but sometimes do in fact sound like noise. I gave a handwavey guide to measuring the SNR of a converter in these slides presented at the Audio Miniconf associated with LCA 2005. The slides are here: http://www.mega-nerd.com/tmp/secret_rabbit_code.pdf The measuring os SNR is on pages 16-19 inclusive. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "I consider C++ the most significant technical hazard to the survival of your project and do so without apologies." -- Alistair Cockburn
Re: [linux-audio-dev] Re: Looking for fast integer resampling code
Kjetil Svalastog Matheussen wrote: > > I recently did a lot of benchmarking between libsamplerate and mus_src > in clm/sndlib. My result was quite interesting, the fastest mus_src sinc > resampler where a lot faster than the fastest libsamplerate resampler. I think most people would agree that speed is not the most important aspect when measuring the quality of a sample rate converter. > I don't have the results available right now, but I remember that mus_src > performance wasn't very far from beating the linear resampler in > libsamplerate. Did you test anything other than speed? > I did not hear any difference in soundquality, but I guess there might be > a difference. If you pick the right kind of source signal and/or chose the right source and destination sample rate, then even a linear converter can sound good. However, a converter that sounds good in that example may not sound good with other real world signals that converters have to handle. With libsamplerate, I can state that the three sinc based converters have the following characteristics: SNRBandwidth SRC_SINC_FASTEST 102.42 dB 80.23 % SRC_SINC_MEDIUM_QUALITY 98.99 dB 90.68 % SRC_SINC_BEST_QUALITY 97.43 dB 96.96% where SNR is signal to noise ratio and Bandwidth its a percentage of the theoretical best bandwidth (ie half of the minimum of the source and desination sample rate). > A third program is the original sinc-resampler from Julius Smith: > http://ccrma-www.stanford.edu/~jos/resample/ > I don't know how this one performs compaired to the other two though. libsamplerate the same algorithm as this one. I think Julius O. Smith developed this algorithm. However, the JOS has a filter that is calculated at run time and is not optimal while libsamplerate has pre-calculated filters that are near optimal for a given quality of conversion. When I tested libsamplerate against the JOS converter and tweaked the JOS converters parameters to get the same SNR and Bandwidth, then libsamplerate as about 10-20% quicker. The bottom line is that doing sample rate conversion well requires CPU. If you find a converter that is fast, it is unlikely to be good. Measuring converters is not that difficult. See the test programs distrubuted with libsamplerate for information on how to test them. Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "There are only two things wrong with C++: The initial concept and the implementation." -- Bertrand Meyer
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time toomany
David Cournapeau wrote: > [EMAIL PROTECTED] wrote: > > > > >I was under the impression that there was bounds checking going on with > >vectors. Is this not the case? > > > > > > > Not necesserally: if you are using operator (), yes, if you use operator > [], no. I think you are all guessing. At least wil C arrays you kopw exactly what you get :-). Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." -- Kent Pitman
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Christian Schoenebeck wrote: > Es geschah am Sonntag 05 Juni 2005 04:18 als Erik de Castro Lopo schrieb: > > I also find Ocaml a better high level language than Python because > > it is strictly and statically typed as well as compiling to native > > binaries which come close to the speed of C. The (very flawed IMO) > > language shootout puts Ocaml compiled to native binaries as faster > > than C++ but slower than C. > > Hooo, that is a very brave claim, Not my claim. The claim is here: http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&sort=fullcpu I believe that this shootout is somewhat flawed in that the examples are all relatively short pieces of code unlike anything that even approaches real world code. It should be noted that the benchmark attempts to use the technique most approriate for the language. So, for the count words example, the C++ version uses std::vector from of the STL: http://shootout.alioth.debian.org/benchmark.php?test=wc&lang=icpp&id=0&sort=fullcpu while the C version uses standard C arrays: http://shootout.alioth.debian.org/benchmark.php?test=wc&lang=icc&id=0&sort=fullcpu Are you surprised that C arrays are faster than std::vector? Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Baldie is such a wonderful villain The Linux/OSS community could not possibly ask for a better villain than our man Baldie. He is absolutely perfect for the part. Just look at his creds: 1) Physically repulsive; 2) Morally bankrupt; 3) Megalomaniacal; 4) Possessed of a truly nasty, abusive disposition; 5) Prone to Hitlerian ranting; 6) Stalinesque paranoia... The list just goes on and on. The man has the gift of true despicability, no doubt about it. If it weren't for Baldie we'd be stuck with Bilgatus' merely vacuuous and creepy persona for an anthropomorphization of the Evil Empire -- tepid at best." -- Matthew Alton in LinuxToday.com on Steve Balmer
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Tim Goetze wrote: > To be honest, I don't know if it's undefined behaviour; I don't read > ISO compiler ABI standards (if they exist in the first place). I was > simply trusting that common sense would always allow this > cross-language subclassing, apparently I was wrong. Trusting that unspecified/undocumented characteristics will remain the same across versions is asking for trouble. > > > Can I sell you an Ocaml: > > > >http://www.ocaml.org/ > > Does it give me inline assembly, realtime-safeness and the performance > of C/C++? Well I really like to separate the C and C++. C is unashamedly a low level language. C++ OTOH tries to be both low level and high level. In comparison to C, C++ is a poor low level language. Compared to Python or Ocaml, C++ is a poor high level language. So to answer your question, Ocaml will not give you the low level stuff that is available in C (inline asm etc), but it is a much better high level language than C++. I also find Ocaml a better high level language than Python because it is strictly and statically typed as well as compiling to native binaries which come close to the speed of C. The (very flawed IMO) language shootout puts Ocaml compiled to native binaries as faster than C++ but slower than C. Linking low level C code to Ocmal is about the same complexity as doing the same for Python. > Browsing the site, the tutorial shows code lines ending with two > semicola and assignments using a 'let' operator; first bitter pills > to swallow for a friend of code brevity to be sure. The syntax does have a few warts, but IMO no more than C++. However, you should look at the big picture instead of the minor details. Ocaml's bevity comes from it being a true high level language like Python, not some psuedo high level constructs grafted onto a low level language like C++. I've done quite a bit of Ocaml over the last 9 months or so and I find that for the tasks I was working on I can get a job done in less lines of Ocaml code than it would take to get the same task done in Python. That is brevity. In adition, unlike Python my chances of getting run time errors are reduced to almost zero because of Ocaml's strict, static type checking. Errors that are runtime errors in Python are almost always compile time errors in Ocaml. > It does look like it has its sweet spots after some more tutorial > browsing, however I'm afraid my ideal it is not. I have done some seriously difficult code in Ocaml; tasks that in C or C++ would a nightmare of complexity and/or endless futzing about with trivial minor details. It is not the ideal programming language, but for some kinds of tasks it beats every other programming language I've ever seen. You might also find that Ocaml combined with C is a better option than C++. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "The growing and dangerous intrusion of this new technology, threatens an entire industry's economic vitality and future security." -- Jack Valenti (MPAA president) on the video cassette recorder, 1982.
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Tim Goetze wrote: > Frailty, thy name is GCC > > A Modern Drama in Three Scenes. > > Dramatis Personae: An ardent programmer and a popular C++ compiler > > -*- > > Prologue: > > Appalled by the rat race commonly known as the proprietary software > business, our young and gifted hero joins the light side, deeply > inspired by the manifold yet subtle qualities of free software. > > Scene I: > > Our hero in day-and-night-long sessions optimizes the hell out of a > SSE2-based n*4-band IIR equalizer. Of course in assembly, and mixed > with C++ templating. The final code is about 10% faster than floats on > AMD, probably a fair bit quicker yet on P4 systems. > > Enter gcc version 3, which drops multi-line inline assembly support. > Said assembly code becomes effectively unusable and dies a quick and > unsung death. > > Scene II: > > Our hero puts years of work into an all-round realtime audio and MIDI > library that expands the Python programming language. While having its > flaws, it's a versatile, surprisingly stable and immensely capable > system, partly thanks to a very clever (according to our hero) design > that subclasses Python's C types in C++. Sound to me like that was relying on "undefined behaviour". > Enter gcc version 3, moving the vtable member to memory offset 0 of a > derived type even if the base type is in C which doesn't know about > vtables. Relying on undefined behaviour will, sooner or later, result in tears. > Scene III: > > Our hero bundles his DSP efforts into a free plugin library, once > again saving himself much work and improving code readability by using > C++ templates, resulting in quite an elegant object system and source > code, hethinks. > > Enter gcc version 4, which requires the templated types' constructor > code be rewritten in the most nonsensical, misleading and ugly fashion > possibly imaginable this side of Hungary and Redmond, WA, according to > our (now not so very young anymore) hero. Hmm, C++ bites again. I know little about C++, but maybe this last change was due to some requirement of some C++ standard. > Our hero has completely and permanently lost his faith in the popular > compiler. Two out of the 3 above were C++ related and did not affect the GNU C compiler. > Disillusioned and indecisive, he resigns himself to > henceforth reluctantly write C++ only to support his miserable life. Can I sell you an Ocaml: http://www.ocaml.org/ Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "... a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god." -- Thant Tessman
Re: [linux-audio-dev] Mixing signals
Richard Spindler wrote: > It's some evil black magic that tries to avoid disortion. I'm not sure > whether it's the right way to do, but I was inspired by some website, > but i don't have the link anymore. > The original code-snippet performed a similar operation on integer-data. I can (possibly) see why one ***might*** want to do something like that for ints, but for floats its just not a good idea. Using what you currently have you are more likely to add distortion than if you just add the two values. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Some people don't want genitalia shoved down their throats." -- Rex Mossop, Australian football commentator and morals crusader
Re: [linux-audio-dev] Mixing signals
Richard Spindler wrote:
> On 5/23/05, Viceic Predrag <[EMAIL PROTECTED]> wrote:
> > Could someone please help with this apparently simple problem?
>
> I'm not a "professional" either, but this is what I do:
> if (*p_A<0 && *p_B<0) {
> *p_output =(*p_A+1)*(*p_B+1)-1;
> } else {
> *p_output =2*(*p_A+*p_B+2)-(*p_A+1)*(*p_B+1)-3;
> }
Why? What is this supposed to achieve and what's wrong with:
*p_output = *p_A + *p_B;
Erik
--
+-------+
Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid)
+---+
"Using Java as a general purpose application development language
is like going big game hunting armed with Nerf weapons."
-- Author Unknown
Re: [linux-audio-dev] Mixing signals
Viceic Predrag wrote: > Hi all, > > I'm the author of Freecycle, one of the younger FOSS audio projects out > there. > I have a problem that may astound by it's simplicity, so I barely dare to ask > for help... > > Freecycle provides some LADSPA functionality, and as there are lot of great > but mono ladspa effects, I need a very simple way of sending stereo audio to > mono input.. Is there any reason why you don't just start up two instances of the plugin and send each channel through its own plugin? You could replicate the control parameters for each channel. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn
Re: [linux-audio-dev] Evolutif
On Fri, 29 Apr 2005 15:26:12 +0200 "J_Zar, Gianluca Romanin" <[EMAIL PROTECTED]> wrote: > How can I re-use Jack, Ardour and alsamodular as a full audio engine library? Jack is an audio routing daemon. From what I hear, it is equivalent to rewire on win32. Multiple programs can connect to Jack, and using Jackctrl, the outputs of one program can be routed to the inputs of another and finally, the jack output can be routed to the audio outputs. All of the programs are sample locked. Please do look at this before you even start to think about writing any code. http://jackit.sourceforge.net/ Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan
Re: [linux-audio-dev] Evolutif
On Fri, 29 Apr 2005 14:06:17 +0200 "J_Zar, Gianluca Romanin" <[EMAIL PROTECTED]> wrote: > Hi all, > > I would like to know if someone knows if the Evolutif Audio > ( http://evolutif.sourceforge.net/ ) project is alive I'd never heard of it before reading your email. > (no CVS, no releases from 2003). I think the answer is no. > If not, is there any other similar audio project actually in > running? I read the web page and the blurb is so general that I'm still not sure what it does. T > I'm thinking to extend this code stuff (Evolutif) and I would like to parse > possibilities and efforts. The only files I can find for this project are two windoze binary zip files. Even if you found the source for Evolutif its unlikely that it would do more than Jack, Ardour and alsamodular synth can do. Why not take a look at those projects instead. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "You don't have make it your sole purpose in life, but could you at least sacrifice a rubber chicken upon the altar of literacy?" -- TackHead on Slashdot
Re: [linux-audio-dev] jack_process and pitch-shifting
On Fri, 22 Apr 2005 17:13:47 +0200 Olivier Guilyardi <[EMAIL PROTECTED]> wrote: > Hi, > > In Jackbeat, I want to include support for realtime pitch shifting. One > of the option is to use a quality resampler as libsamplerate's > SRC_SINC_BEST_QUALITY converter. Err, the only think you can do with libsamplerate alone that even comes close to pitch shifting is the vary speed effect (change the playback speed and the pitch changes). Secondly, for any real time operation, SRC_SINC_BEST_QUALITY is complete overkill. I would honestly suggest SRC_SINC_FASTEST. > In the future, I may add support for > libsoundtouch1 (http://sky.prohosting.com/oparviai/soundtouch/index.html). Libsoundtouch can do constant pitch time stretching. If you combine that with libsamplerate's vary speed capabilities then you get pitch shifting. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live." -- Martin Golding
[linux-audio-dev] This is what its all about.
Hi all, As some of you may know Linux.conf.au is on in Canberra, Australia at the moment and that today we had an audio mini-conf followed by a performance night. The standout tonight was a duo called Deprogram: http://www.deprogram.net/ who performed some great electronica with live keys and vocals over prerecorded tracks. The backing tracks had been recorded on and were being played back using Ardour running on a Linux laptop. The performance was simply stunning. The fact that Ardour, Jack and other linux software was used in its production and performance is a *huge* validation of what we have been doing all these years. Congratulations to everyone involved in making audio on Linux happen and thanks to Nick and Mary of Deprogram for showing us how its good this stuff actually is. Cheers, Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ Saying Python is easier than C++ is like saying that turning a light switch on or off is easier than operating a nuclear reactor.
Re: [linux-audio-dev] LCA2005
On Sat, 16 Apr 2005 17:13:51 -0400 Dave Robillard <[EMAIL PROTECTED]> wrote: > Hi all, > > Anyone going to LCA2005? (note that's LCA in Australia, not LAC in > Germany!) Yeah, I'll be there. > I'd like to see if I can find a keyboard controller and/or guitar for my > presentation (not to mention the jam session afterwards). I'm flying in > from Melbourne and can't bring any of that stuff. Keys in particular > would be /really/ nice to have, if there's any Canberra folks around. Better to ask on the lca-audioconf list at lca-audioconf AT lists dot linux dot org dot au Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done." -- Erik Naggum
Re: [linux-audio-dev] GPL concerns
On Wed, 06 Apr 2005 14:56:19 -0500 Shane <[EMAIL PROTECTED]> wrote: > Jan, > > Thank you for your comments. I should clarify from the perspective of > an independent software developer with no previous relationship to the > company issuing the NDA that may or may not be valid or legal... > > First of all, the (hypothetical) NDA requires that the copyright to any > work rendered for the company based on the codebase in question be > retained by the company. Thats the case with all work for hire situations. > Some parts are developed in house, some are > GPL. The NDA also essenstially asks that I surrender my right under the > GPL or other applicable licenses to redistribute any part of this work. This is till work for hire right? If you were working for microsoft, would you expect to be able to redistribute the stuff you wrote for them? > While this company has stated that they will release the entire codebase > under GPL into the public domain Careful, GPL and public domain are two different things. GPL means that someone owns the copyright but gives the user the rights allowed by the GPL. Public domain means that the original author has given up any claim to copyright. > Would this have any change on the legal status of such an agreement?? That sounds sensible. > Or > is it simply an individually binding agreement between the company and a > developer? I would go for this interpretation. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "OS X is great that way. I put a copy of OS X on my coffee table, and it hasn't been hacked yet. Yes, I am using it as a server. I serve several meals on it every week." -- Anthony Minkoff
Re: [linux-audio-dev] GPL concerns
On Wed, 06 Apr 2005 00:31:15 -0500 Shane <[EMAIL PROTECTED]> wrote: > Hey everyone. I have a bland but important question for everyone. Say > hypothetically a company is developing an audio product using lots of > GPL source, but for whatever marketing reasons asks for NDA concerning > the codebase. Lots of GPL work is referenced and at least dynamically > linked, and though the company has directly stated that it will release > the codebase publicly with the product release (once it is complete). > > I am curious as to the general feel in the community on such practices. > Would this 1) be a violation of the GPL, Yes. > 2) if it is how tolerant would > the OSS community be, considering the general good intent of the > project, and If any of my code is involved, I will prusue the matter. > 3) if I were asked to sign such a NDA would that document > be a binding agreement even if the NDA itself might be a violation of > the GPL since it is inherently counterintuitive to the intent of the > GPL. The GPL is pretty clear about this. The GPL comes into action when the binaries or code derived from GPL code is **distributed**. That means that you and the company can hack on whatever GPL code you like as long as they don't release a binary (under NDA or not). Erik -- +-------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Therapists typically base the nuttiness of a patient on the strength of their convictions, on which basis this 43,000 word opus alone stands as a kind of testament to Bill's (Gates) madness." - The Register
Re: [linux-audio-dev] Re: Any interest in DVD-Audio?
On Mon, 14 Mar 2005 20:49:03 +0200 Jussi Laako <[EMAIL PROTECTED]> wrote: > Typical newsgroup FUD. The paper referenced is this one: http://sjeng.org/ftp/SACD.pdf by Lipshitz and Vanderkooy, two absolute *GIANTS* in the field of digital audio theory and practice. > First of all, most of current A/D and D/A converters are delta sigma > modulators. Yes, but from what I've heard, with modern delta-simga converters, the minimum bit width is 4 bits, not one bit. > If you record something at for example 24-bit 192 kHz (using > typical delta sigma converter), The A/D converters now use a minimum of 4 bits. > do some editing (in float format) Ie it gets convertered to PCM. > and > then output the master as PWM for SACD. They *may* be some advantage here in that you can pay for a very expensive PCM -> SACD converter at the mastering stage and the playback system becomes simpler. However, Sony is pushing SACD as a complete solution for the whole audio chain. Sony and others are working on SACD multi track recorders and so on. It is this in particular that Lipshitz and Vanderkooy and trying to address. Erik -- +-----------+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Linux is produced to be used, whereas the others are produced to be sold" -- Bobby D. Bryant
