And there is one more important thing - PROPER low pass filtering.
Paula just holds sample values for sample period on each channel.
This produces aliasing, and global low pass filter is used as a crude fix. This was great for 1985, but not for 21 century.

The proper is to convert given sample rate for each channel to maximum rate by simple repeating, then apply digital narrow band low pass filter to each channel centered at half the channel's sampling frequency.

Thomas Richter wrote:

Adjusting the volume mid-term at a *precise* sample position robustly requires a second audio channel. Or at least a second DMA channel if you can leave the design constraints of the current hardware.

That's what i'm trying to say since the beginning, but, as Gunnar will not believe me, i'll try to really implement it and then we'll see.

But would mixing so many channels not waste a lot of memory bandwidth?
If you read 500 channels to mix them down to 2 Stereo channels.
Would it be much  cheaper to mix them down in advance, store a 2 channels stereo signal and just play it back?

This sounds to me 250 times cheaper.

 
BTW How would you mix the 500 channels anyway internally?
Lets say you have 16bit samples and 8 Volume per channel.
And lest say we have a 24bit DAC.

How would you sum up the channels without loosing precision?

Another solution for stereo would be to use 4 channels and swap channels at each interval by cross fading them.(Volume)
But this can cause a echo effect...

Ugh compromise compromise. :(

However, this requires more computing power - which *may* be available on Natami. It is clearly possible on a PC.

Greetings,

Thomas

Realistically, I don't think 500 channels are necessary, or possible, or plausible. Having more than 4 would be nice, I guess ~32 would be a realistic option. With volume & frequency modulation you still had 8 channels for the audio output.

Greetings,
Thomas

How BIG would a .wav file be, if that much data was provided for playback??? It can't be the conventional music files used, surely?

Music files on a CD are about 700K Bytes per second, so that would make 500 channel music take up what per second, of real estate?

You can see that I don't quite get what's happening here, but I can see A LOT of DATA, and it's coming from somewhere.

Thomas Richter wrote:

Having more than 4 would be nice, I guess ~32 would be a realistic option. With volume & frequency modulation you still had 8 channels for the audio output.

Wojtek?

If you read 500 channels to mix them down to 2 Stereo channels.   Would it be much  cheaper to mix them down in advance, store a 2 channels stereo signal and just play it back?

Why do you have for example .mod's at all so?

global volume should be settable.

I wish to interject here that perhaps your concept may be flawed with respect to needing hundreds of channels to generate realistic instrument sounds. But I will also admit that I haven't followed this thread in detail; nor do I know any of the nuts and bolts of this scheme, but I'd like to refer you to this link: EXTERNAL LINK  (that's h t t p : / / p i a n o t e q . c o m ) and urge you to listen to the demo sounds and download the demo program and see if that changes your viewpoint. I'm thinking there may be some technology/concepts that can be leveraged in what they are doing; they describe it as the "4th generation piano". Perhaps you may find you don't have to reinvent the wheel, hmm? :-)

I'm listening to to some samples even as I write. Very realistic. I don't think my computer (iMac, intel) has hundreds of channels, does it?

I've mentioned this before, but I am a piano technician and a pianist. I've also done a considerable amount of midi sequencing with a Peavey DMP-2 synth. I also have several Amiga music programs, such as Dr. T's "Tiger Cub" (a very excellent sequencer program, and I'm still looking for something as good for the Mac, and GarageBand just doesn't cut it). I also have "SuperJam!" for the Amiga. SuperJam could generate some pretty decent sound (using Turbosounds) even with the classic Amiga's limited hardware resources. I was disgusted when Microsoft bought the program and mothballed it, no doubt to eliminate the competition and/or rob the software kernel for their own use.

So, I'm contemplating that maybe it's not the number channels that is the issue, but instead it's the sound generation model or software "engine". After all, think what you can do via an ordinary stereo system with just two channels. The crux lies in creating the complex waveform to generate the audio.

Example: I am also a ham radio operator. My son and I recently wrote a program in Amiga HiSoft BASIC to recreate the authentic sound of a landline railroad telegraph. That was in large part because we were asked to volunteer to man the railway station telegraph at the local museum's public events. I was surprised to learn that here in continental North America the railroad telegraphers never did adopt the international code (which the hams do use) but stayed more or less with Samuel Morse's original code. It was referred to as "Railroad Code" or also referred to as "American Morse". To make a long story short without the details of hows & whys for doing it, we wanted to write a tutorial and practice program for Railroad Morse. We decoded samples of telegraph audio, and extracted enough of the useful portion of the waveforms to synthesize the telegraph audio on the amiga audio channels within Basic. Because the clicks and clacks are so short we were able to produce some pretty decent and realistic telegraph-sounder audio. We set the frequency of the waveform to coincide with the sample rate and length of the telegraph audio. And it worked! I think it equated to something like 16 milliseconds of audio at 16 kHz sample rate for the click or clack duration. But what a horrible sound if we tried to increase the duration of the sound beyond the length of the array! Then you start getting repetitions of your array with a frequency of its own that corresponds to multiples of the sample repetition rate  - something like 1000 ms divided by 16 ms = about 62.5 Hz and multiples thereof (I'm just describing this off the cuff from memory; I'd have to go back through the code again to verify the numbers).

So in conclusion, as I see it the greatest limitation is not the number of channels (or lack) but rather lies in language limitations such as the 255 element limit that BASIC imposes for any waveform array. For instance, with Amiga Hi-Soft BASIC (and others) it's not possible to create true "white noise" because the language doesn't allow defining a waveform array that's large enough to hold sufficient waveform data to truly recreate a realistic sound.

I'm nowhere near a software expert as Thomas Richter or Gunnar, nor hardware knowledgeable as Marcel, but hopefully some of my thoughts here might steer you in a useful direction.

-Ernest

Again, this "channel thing" is coming from a different tradition: Today, you create audio by downmixing sound effects in advance creating an audio track you just play, and you only need channels for mixing the SFX with background music with a voice channel. Thus, a small number of channels is sufficient.

In the 80's "old school" coding, each individual note required an individual channel, thus the more complex the sound, the more channels you needed.

The use case changed, and thus I don't see a reason to demand more audio channels than probably eight usable (times 2 for volume control under DMA, times 2 for frequency control under DMA, giving my estimate of 32 channels).

So long,
Thomas

But isn't volume control and frequency control be done with 1 channel, right?

So long,
Thomas

so 50MB/s is less than 2%. And most channel will not be used at 16-bits.

OK, maybe I value 50MB more than you.

But this is not the key question.

The key question is:
How can you MIX 512 channels without loosing the quality

I've asked you this now three times.
You said mixing the channels is easy, so do you have an answer to this question?