Starting up... again... for the 3rd time, please, need help

[williamk]

Ok, guys, I'm finally giving it another go, for the 3rd time, as so far I had tons of problems and couldn't get much done, sadly.

Now a local company needs my help, and I need to figure out if XMOS would do the trick. ;-)

First, I need to know which chip is the easiest one to handle, so we can make our own PCBs and solder by hand. (yup!)

What I need is to make a simple polyphonic sample-playback device. It will play 16 bit sound at 44.1 khz. Each sound has a start and a loop area. (some may be one-shot) And a Release envelope, nothing else.

So I need to figure out the math of how many random-access data I can get from a SD Card, or if I will need external RAM and how to handle that.

I have a XC-1A board here for testing.

Any help will be MUCH appreciated.

Best Regards, WilliamK

[williamk]

One detail, I'm thinking that we will need our own boards using multiple chips, to keep things easy to solder and also low-cost, so purchasing the boards from Xmos would be too expensive, considering that we need tons of polyphony, and I'm pretty sure one single chip won't do it. Unless working with external parallel RAM is fast and easy to handle. But maybe one solution is to use a SD card per single-core chip doing less voices, but multiple chips+sd_cards combos. The quad-core chip would be great, but we can't make our own boards with that, the the XC-1A board would be too expensive for us to import. (we are in Brazil - South America) Importing chips is much easier. (we have a $ 50 USD cap on all imports before we have to pay 80% custom taxes on the declared value, eeeekkkk)

[Berni]

Wow 80%, and i thought we had a high import tax.

Anyway how much of polyphony you need? Like 8 sounds at the same time? Also does it need to be 44.1 16bit, since if its not going to be listened to trough a proper pair of speakers its going to sound pretty much the same in 22KHz 8bit (Thats 4 times less data per second)

For a lot of polyphony you are likely going to need some extra RAM on your board to cache your samples in.SD cards have a significant seek time so jumping between say 8 locations on the card while playing back will probably not work.In any case you should not use a FAT filesystem on the card as it adds extra overhead work. There is windows software that can write to a drive in raw hex form so you can get that to get your raw audio samples on there without any filesystem.

[williamk]

Thanks. And yes, the import tax sucks...

Ok, I'm working on 2 projects actually. One require around 20 notes of polyphony, 16 will do, but they are stereo sounds, so I'm thinking 32 notes total. The other is BIG, 256 to 512 notes of polyphony, so we are using a computer instead for now. But would be nice if we could use a bunch of XMOS chips instead.

Do you have any idea on the seek time of a SD Card? What if I used multiple SD Cards?

Still researching for this project...

EDIT:
One thing I'm wondering, what if each thread on the single-core xmos chip would talk to a separated SD Card? So we would have 4 x SD Cards? Would that work or I'm just day dreaming? ;-)

EDIT:
Another thing to keep in mind is that it would be possible to read the SD Card in blocks of 8 or 16 bytes, to speed things up, since the XCORE has some memory to handle that. Why so low? Keep in mind that we want as many voices as possible, so each voice requires a buffer. ;-) So, lets say we manage to get 16 voices from a thread, that's 16 x buffer. So, for 16 voices per thread, at a 16 bytes buffer, we will use 1K of memory already. Now, if we have more free memory, we could use more for the buffer. The advantage is that the SD transfer will be much faster then. Using parallel SD Cards could also speed things up. But why use it instead of RAM chips? Well, size of the samples. Using just SD Cards would allow large samples to stream from the SD Card, therefore, not having any size limitations. Otherwise, we would need to use a 512 Mega Bytes (8-bits) based chip. Is there such thing available and easy to attach to the XMOS? If so, it would work too.

EDIT:
And another idea is to keep one thread for SD Card buffering and the other 3 threads for the actual voices + envelopes and the mixing done in the last thread. Maybe it will be more like this:

1) SD Card Buffering
2) Voices
3) Voices
4) Mixer and DAC Output


Moderator edit: Do not double post, use the edit button!

[Berni]

Yes multiple SD cards greatly help the matter, but wow 512 sound polyphony? That is massive, what is triggering the sounds to trigger so many at once? Im having a hard time imagining an application for this.

In any case your best bet is to load the samples from the SD card in to some external RAM and then play them from there since you have a few nanosecond accesses times to the data there while SD cards can really take there time fetching it at times(many many microseconds).

The only was you can do 512 sound polyphony is using a FPGA connected to a DDR2 stick of ram to use as a buffer. The transfer rate for 512 CD quality audio streams is a whooping 720Mbit/s, even hard drives would have a problem reading a continuous stream of data that fast, let alone the seek times to get to 512 different locations in memory so quickly (This reduces the read speed to just a fraction of the continuous read speed) so even doing something like this on a PC would require it to be nicely optimized to work.

[lilltroll]

Do you need resampling/interpolation as well, or do you have one sample for each possible tone ? E.g. is it a synthesizer or a sampler.

[williamk]

I don't need all voices from the same SD Card/RAM, so I could use multiple 32 or 64 voices blocks with multiple sets of chips, etc ...

I only need 4 point hermite interpolation, which is kind of a simple code, or at least linear interpolation.

In any event, I may start up with a simpler project first, with just a few voices, like 16 or 24, and grow from there. ;-)

[Berni]

Well playing back 16 CD quality audio tracks from a L1 chip is gonna be pushing it quite a bit. The average data rate alone is likely going to be so high that you need a high speed card to get that in the easy SPI interface mode.

Also as you said with so many tracks there is not much room for buffers and that is a problem. Cards being disk drives you can only read them in 512 byte sectors at a time, but trust me you do NOT want to read only 512 bytes at a time from a SD card cause the seek time before each read is going to drive the average read speed in to the ground.The way to do it is to read a heap of sectors in one bulk read command as that only needs a seek time before the first sector. So in order to get a decent speed you have to read like 2KB to 16KB at a time while the L1 just doest have the memory for that. Keep in mind that 2KB is only about 10ms worth of audio and in that time you have to seek to and read all the other 15 tracks before you can get back to this one to top up its buffer.

And btw how many different tracks do you want to have stored on the SD card and about how long.

[lilltroll]

I know SRAM is not "low-priced", but consider to use something like this and read in the wavetables into from the SD-card.

http://www.issi.com/pdf/61WV102416ALL.pdf
or any "magnetic" RAM, MRAM.

You could use the L1-128 with the P32A[0..19] to the adress line, a P16B port for the data line, and still have acess to XLA & XLB (5W) to transfer the data to other XMOS L chips.

10 ns SRAM would be wise @ 400MHz chip and 8 ns SRAM @500 MHz.

Use a 3.3V compliant SRAM chip with parrallell data transfer. The price may vary a lot. Try to find something low priced.

For DDR1,DDR2,DDR3 you need an external memory controller, as a FPGA or an ASIC.

[lilltroll]

A way to reduce the amount of needed external SRAM is to only store the first n milliseconds of each possilble sound in external SRAM.

When you need to play the samples, you start to read it from external SRAM, and in parrallel you start reading large chunks of SD-Card data into XMOS-SRAM for the rest of the actual sound played. This can hide the latency for reading a large chunk of data from the SD-Card.
The trick is of course to use so much data in external SRAM so it covers the time to read in the SD-card data for the worst case senario.