Natami has a real huge chip memory.
This means you can off course store many mega-bytes long samples without any problem. Even storing 64 Megabyte long samples is no problem at all.

The tracker can tell the AUDIO DMA to play a 64k chunk of the sample - the tracker needs to update this DMA command regularly to play a long sample.
But a tracker does regularly update this information anyway, doesn't it?

A modplayer is called every vertical blank, this means its called every 1/50th second. It will then update the volume and the other directives for the audio DMA engine.
As long as the 64K length last for at least 1/50 of a second the 16bit length register is enough as the tracker will update this informations every vertical blank.

Does this make sense?

I think using a DSP which has to realtime mix the 32 channels, it would need a lot of chipmem access doing that. That works fine in a soundblaster, but with all other components (CPU, Blitter, Copper etc) using this memory too, it can happen quite easy that the sound stops when the blitter is doing a heavy task.

This is only a question of memory access priorities.
Audio mixing does actually not need that many memory accesses.
A sample with 16bit and 44 KHz is only 88KB/sec.
This means mixing 32 of these samples needs to load 2.8 MB/sec.

With the Natami memory interface we are looking at several hundred MB/sec memory throughput. So reading 1-3 Mb/sec for mixing the AUDIO is not an issue at all.

Does this make sense?

Cheers

I understand what you are writing, but isn't it some workaround to solve the limited sample length. We have some spare register positions I think at $0AE/$0BE/$0CE/$0DE which we could use this as the MSB part of the AUDIO-LENGTH.

But I agree it has not that high priority, because of the workaround.

Like Rob, I think option "A" sounds to be the most promising because it follows the original Amiga philosophy. Imagine 8, 16 or 32 DMA driven sound channels! 8 would be sufficient, 16 would be
fantastic and 32 would be - WOW!

Whatever the Natami Team decides - it will probably turn out to be great.

Something I've always liked with the Amiga is that there is no playback delay when playing sound samples. I hope this will be just as good with the Natami. I've always dreamt of a sound tracker where the patterns scroll perfectly smooth and with absolute no sound delays. This was never a big problem with Amiga or MS-DOS based trackers, but was introduced in Windows. These days things work quite well in Windows if you only have good ASIO drivers and a fast PC.

I believe - and hope the Natami can be even better than ASIO and Windows in this regard.

Someone who has any thoughts on this?

The Robin core will have about 5 or 6 threads going all of the time.  These may be going at only 33-40 MHz or so due to the way that the multithreading is implemented, but it will be reading its instructions from the Fast bus rather than the Chip bus most of the time so the bus traffic on the Chip bus will make very little difference.  I'm not familiar with ASIO but I think the Robin core will be able to handle most if not all of our needs since its threads will collectively total 200 MHz.

Also, DMAs are more expensive than processor power so we should keep the maximum at the number of speakers needed for the best surround sound.  I think 8 channels plus hardware mixing will make all the necessary differences for excellent sound handling.  The 64k sample limit only affects mod players who don't support mixing.  Nowadays most mod players do support mixing anyway.  The AHI drivers will be coprocessed through the Robin core on the Natami so we have little if anything to worry about with regards to mixing.

Actually I think the 64K limit is not a limit at all. :-)
When you do some GFX scrolling you update the screen every frame don't you?
On AMIGA you usually scroll my changing the plane pointer.
You change this pointer every vertical blank interrupt.

The same you do when you play audio.
You just scroll your Audio DMA pointer too.

Audio playback is basicly the same a GFX display.
The GFX DMA does also only display 1 picture per frame.

I think the 64K or 128K limit is only a imaginary limit not a real problem.

Also its in theory no big deal to increase the length counter to 24 or 32 bit.

I just don't think that its needed as 64K is always more than enough for a 1/50 second.

Cheers

I think it would be wery interesting to have an expansion port for Paula (if it's not incrase the price to much, of course).

Let me explain :

For most people having a 8 or 16 channels Paula with DSP will be very sufficient for game, music, video, etc etc

But for musicians having a local expansion slot on Paula with very-low latency would be very usefull. I think that make an audio module with midi and a few XLR (with good preamp) and perhaps more hardware audio channels for Paula on a little affordable FPGA would be possible and it will make a good solutions for musician without incrase the price of a "basic" natami for the others.

If the natami have some success (I hope and I think he will !) in the amiga market (and perhaps more), it is possible that a module like this would be product.

What do you think ?

I think the team is planning on making both a video and audio passthrough for the Natami.  Whether it will be digital or analog remains to be seen however.

EXTERNAL LINK 
This is why NatAmi must be designed to keep the title of World's Best Music Machine!

All of the Natami team have two hearts figthing in them.

On the one hand side we are designers and developers which want tp create the best possible design.
So this part of our soul wants to create a 256 voice audio DMA plus a Robin DSP core.

The other parts of us wants to again bring out an AMIGA to the public.
"To the public" implies also to be affortable by the public.
This part of us is telling us all the nasty comments like "don't do this, look for a cheaper solution - people can not afford a $5000 Natami.

So we have to be both "Designers" and also "Cost managers" ....

A well programmed software mixer on a DSP-like processor (robin) will have very very low latencies AND as the software mixer will be running without bothering on his own "core", there will be no dropouts. I fail to see the problem. This solution is very amigaesque IMO.

If the samplelength is easy to change, I'd do it. Why bother the CPU with setting up the correct values for a continuous playback of long samples, when a single command would be sufficient? I mean, you have to find the right point of the sample, where the last scanline command left the sample to continue without hickups. I guess it's not hard to do, but you have to do it. If an easy and cheap change could get rid of that, why not?

Besides, i wouldn't consider it a Amiga style system without a full chipset.
the problem with the USB i think will be that it isn't realtime nomatter what you do.
I explained it to my boss one's and he found it more important to be able to 'Save to disk' then realtime measurements on a ociloscope.
(sorry for the typo's)

NOW we´re talking :-)
Among the discussions what the NATAMI can maybe provide for "non-AMIGA-fans" that no other cumputer can do (even a Quad-Core-PC) the idea of an latency-less XLR-Output for hardware mixing and recording would be a outstanding point!
We are recording our Demosongs on a PC too and cause we wanna have an good, well balanced and clear sound, we have to spend a lot of money for a quite good soundcard WITHOUT XLR-Output, but with latecy-preventing technology bei Steinberg (CuBase).
Otherwise we are strungle with the speed, proper connections and the abilities of that machine at all - and its not really an slow vintage-PC!

So this could be a corner without contenders for the NATAMI - if it would not raise the costs too much of course...