[linux-audio-dev] lad design patterns

[Eric Dantan Rzewnicki]

Fons Adriaensen wrote:
> On Sat, Jan 29, 2005 at 10:53:14AM -0600, Levi D. Burton wrote:
>>does the idea of documenting various lad design patterns make sense to anyone?
>>seems a lot of stuff is sort of voodooish.

denormals anyone?

> There is a lot of common sense involved, and usually a whole
> collection of different types of voodoo:
> - signal processing 
> - designing for real time
> - multithreading
> - system interfaces
> - event driven systems

So can you, or anyone else, give a few solid references for where to 
learn the fundamentals of each of those topics? (preferably with a focus 
on audio.)

> and of course this leads to some recurring patterns in
> all but the most trivial applications.
> It's a good thing to have some framework that is designed to
> be compatible with all these aspects. Given this, it doesn't
> matter so much how a particular pattern is implemented, but
> consistency and making simple things fit and work together 
> help a lot.
> For example, a recurring theme in more complex audio apps is
> the 'lock_free ring buffer' that is normally used to pass
> audio samples between two threads without ever blocking one
> of them.
> The JACK code provides an implementation of this, and many
> people use it. I don't, not because there is anything wrong
> with the code, but because if I use the ITC features of my
> threads lib in the correct way, I get the same effect without
> any extra code. The two implementations couldn't be more
> different, but it's still the same pattern.
> Because audio (and signal processing in general) programming
> involves this mix of disciplines, combining high (abstraction)
> and low (down to the hardware) level features and elements
> from audio engineering and DSP, many of the things you may
> learn on the way to a degree in IT could actually more of

Ahha! there. It's decided. I don't need to go back to school to get a 
comp sci degree. Fons said so. ;)

> a hindrance than a asset, unless you are capable of taking
> some distance from them. Forget 'extreme programming', and
> all the other 'hype of the day' that thrives in information
> engineering circles, and embrace common sense.

Are there some bodies of knowledge in published works that are more 
appropriate for the would be linux audio developer than other texts 
intended for the general programmer?

Currently I'm reading the linux-audio-dev archives ... I'm learning, but 
it's slow since the discussions between Paul Davis, David Olofson, 
Jaroslav, Benno, etc., etc. from back in 1999 include them working out 
what these design patterns would be. I can see hints of elements of 
ladspa and jack and dssi and alsa that evolved over the past 6 years and 
it's very interesting to me to read these discussions. But, at the rate 
I'm going I'll never catch up to the current state of affairs without 
quiting my day job and devoting myself full time to this study. I would 
love to do that, but it just ain't practical.

I've read K&R and Harbison and Steele ... so I have a decent grasp of 
the syntax of C. I use python and bash at work and at home, so I'm 
beginning to learn a little bit of how to program. But, I don't know 
where to go to learn "linux audio development". I'm not personally 
interested in coding gui's, writing web or accounting apps. I don't even 
have a burning need to have my own project. I want to have the 
conceptual knowledge to contribute to existing projects. At the moment 
I'm most interested in the drivers and tools for my sound card, jack, 
ladspa, dssi, ecasound and ardour.

Anyway, I'm not complaining. I know all the code is there to be read and 
is most likely the best possible resource for learning how this stuff 
works. I'm more just expressing "yeah, Levi, I'm right there with you."

BTW, Levi, your music rocks. :)

-Eric Rz.