From: <John.Maloney at svjconnections.com>
> Folks,
> I did an experiment with multi-track recording this weekend. I was able to
get
> output buffer. I then recorded myself singing rounds and other multipart
music.
I've done a couple songs like this, and even with my $5 mike and crude
software, I was able to get nice results.

> I did notice that the background noise tends to build up as you add
tracks.
If anyone is trying this, there are a few things that will help reduce the
noise.
-The sampling rate should be pretty high( >= 44 khz), at least in the
original tracks, otherwise the aliasing effects above the Nyquist frequency
builds up very quickly. My sound card doesn't seem to filter these out for
me. The Windows sound recorder has a default of 22 khz, and it sounds quite
bad when more than 2 or 3 tracks are mixed.
-I bought a pro microphone this weekend, and although generally it does
greatly reduce the "hiss", it also picks up background noise, like my noisy
computer fan. That can build up with multiple tracks too, along with that
darn 60hz line hum that sneaks in everywhere.
-My particular sound card, SB Live, seems to work at 48 khz and downsamples
for everything else. I'm not convinced it does this very well.

> pretty similar. I guess one big reason to buy a professional sound card
> is to capture a less noisy signal.
I wimped out on getting a multi track sound card this weekend, but
eventually I will find some excuse to get one!

> My experiment was very crude. To do a real multi-track recorder in Squeak,
> one would want to add:
>   2. disk-based sound tracks (I did everything in RAM with large Squeak
heap.)
I think to this end, we might consider looking at how Squeak deals with
sound files, formats, etc.
-audio file formats should probably get their own classes, like the
ImageReadWriters. This has been done for a few file formats, and we should
keep going in this direction.
-The notion of data representation could be separated from the file format.
Right now, all uncompressed sound is stored in SoundBuffers. We might try
creating a new SoundCodec, PCMCodec (that's what uncompressed sound is,
right?) which can store its data in different types of buffers, such as
unsigned 16bit, 32 bit float, etc.
-To support large files, these buffers could optionally operate from disk,
and keep in memory only a small portion of themselves. This would involve
the buffer and/or codec being smart enough to go to their AudioFileFormat to
fetch or store. I like the idea of sounds being able to transparently take
care of on-disk operations, but I'm not yet sure how the codec and file
format can communicate cleanly. For compressed file formats like mp3, this
would be harder; that's one reason that this ability would be optional.
-The current 16 bit sound in/out is good enough for me; if you really need
more than this, you'll probably be using more specialized IO anyway.

These things are still fuzzy to me, so feel free to elaborate!

Eddie