samplig rate conversion

robert bristow-johnson wrote:
> 
> one thing i would have to say, Erik, while i respect the technical merit of
> your code (i've only looked at libsndfile), it is awfully opaque to read. 

Funny thing is, I have had a number of people dive into the libsndfile
code and add significant chunks of functionality, and then sending
me a patch. The first I hear of it is a the patch arrives in my
my inbox. Many of those people have also said that the libsndfile
code base was rather easy to work on.

> a
> few years ago, i tried extracting the salient functions out of it to include
> in a simple C program i was writing to do some (undefined) music/sound
> processing on some .wav files.  whenever i did, it left so many undefined
> symbols and such that i ended up writing a simple .wav file reader from
> scratch.

Like any large piece of code, libsndfile has had a bunch of 
common functionality abstracted away into internal helper functions
and then called from throughout the rest the code. This is commonly
considered good software engineering practice. This and the 
concientious use of test driven development has made the libsndfile 
code base extremely robust and reliable.

libsndfile is extremely widely used. It is installed on a large
proportion of Linux systems and is used for file I/O on Mac
Win32 and Linux) in CSound5, SuperCollider3, Chuck and a number 
of other widely used pieces of sound software. Even with this 
wide usage, bug reports are extremely rare and are fixed with
a very short turn-around.

Part of the reason for the relatively bug free nature of libsndfile
is the use of internal helper functions. This also makes it
difficult to pull a single file out of libsndfile and hope to
compile it into something else. I don't apologize for that.

> i'm just an EE who is a code minimalist

As am I. If I wasn't a minimalist libsndfile would be written
in C++ with deeply nested class heirarchies and templates and
the standard template library throughout. As if it is, 
libsndfile uses little code outside the ISO C99 standard.

> your code looks
> like something written by a hard-core professional 

I'l take that as a compliment :-). I do make my living
writing code in projects of 100k plus lines.

> working in a big company like Micro$oft. 

But that is not. If it wasn't you rbj, I'd take that as an
insult :-).

> that may be good, in some regards, but it is not transparent.

May its a culture thing. For experienced software engineers
working in C on Linux, libsndfile does not look all that strange,
especially if they have had some experience in writing device
drivers on Linux.

For someone coming from outside that culture, the libsndfile
may look rather opaque.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"There are two kinds of large software systems: those that 
evolved from small systems and those that don't work."
-- Seen on slashdot.org, then quoted by amk

Randy Yates wrote:
> 
> If Einstein were a software developer, I'm sure his philosophy would be
> 
>   "Write code as simple as possible, but no simpler."


And I'd agree with that as long as "simple as possible" includes
proper testing of corner cases, error returns from functions,
proper validation of untrusted input etc.

I seen statistics somewhere that for any significnt piece of
code, up to 50 percent of the code (by line count) was input 
validation and error handling

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"C++ : You won't live long enough to learn it all from 
experience." -- Peter Miller (author of Aegis)