Teensy 3.2 for multichannel delay unit?

Status
Not open for further replies.
ZTiK.nl over here says he's getting a write speed of 1311.09 KB/sec with an SD card.

Don't you only need (758,000 * 16)/8 = 768kB/s?

Yes, per channel -- but I need to read from and record to the same memory -- N channels reading while 1 channel writing, where N would (ideally) go as high as 8.

That gets into the issues Paul has mentioned on his site re: SD card random-access performance is much worse than sequencial-access performance. (Although I've never checked that, I only know what I'm told.)

OTOH, if I could access 8 SD cards in parallel, none of them would read & write at the same time & all access could be sequential ...
 
Hmmm, maybe this chip could work?

http://www.cypress.com/documentation/datasheets/cy62177esl-mobl-32-mbit-2-m-164-m-8-static-ram

It's also not cheap, $43 for TSSOP or $31 for BGA at Digikey, and also not quite enough (4 MByte) for the original goal... but pretty close. There's also a 8 MByte version, without the 8 bit data option, at appox $60.

http://www.cypress.com/documentation/datasheets/cy62187ev30-mobl-64-mbit-4m-x-16-static-ram

Either of these would need mux chips to deal with the large number of address pins. But at least they're async interface that could "easily" be used from microcontroller pins.
 
... for the SD-Card idea:

I think you could save some time (some milliseconds) without a filesystem and use blocknumbers instead.
It would be insteresting to know how much channels would work, this way..
Then, for a bit more speedup, you could try to find really old SD-cards in the 512MB -size range. Some time ago i played with some cards and found that they were faster* (perhaps due to simpler internal algorithms or simpler adressing..)
The problem with SD-Cards is adressing blocks - this takes a long time.


Edit:
*for random-access (they were some 100us faster)

edit:
..but i don't believe that more than 2 channels with concurrent read+writes are possible. maybe only one.
 
Last edited:
The BE MICROMAX 10 is a FPGA Evaluation Board for 30$ with 8MB RAM:
  • Adopts Altera's non-volatile MAX 10® FPGA built on 55-nm flash process
  • Powered by Altera's Enpirion® Power SoCs
  • Includes 8MB SDRAM, accelerometer, digital-to-analog converter (DAC), temperature sensor, thermal resistor, photo resistor, LEDs, pushbuttons and several different options for expansion connectivity
  • Embedded USB-Blaster for use with the Quartus® II Programmer
  • Expansion headers include – two 6-pin PMOD, two 40-pin prototyping headers, one 6-pin analog input header and one 80-pin BeMicro card edge connector

https://www.arrow.com/de-de/products/bemicromax10/arrow-development-tools#page-1
 
Last edited:
To tell the truth, that Axoloti Core board actually looks almost perfect for this. The CPU is apparently a variant of the same ARM chip as the Teensy -- the variant with a memory controller. The board comes with 8mb SDRAM installed, plus the audio IO connectors already built in.

The Axoloti project, actually, seems in many ways to be approaching the same vision as the Teensy Audio Lib: there's a visual UI configuration tool you use to set up the route of audio through the system, then that gets compiled down to C code which is compiled & installed on the board. The Axoloti config is a Java app instead of a web-app, but it actually creates a UI that talks to the compiled firmware & controls it live -- something that I think Paul has talked about doing eventually.

On the other hand, I dug around their github ... the Axoloti software architecture looks way more complex than Teensy Audio; it's daunting. And Axoloti's Java UI has poor usability compared to the Teensy Lib's web UI; all the controls are so tiny on my screen, selecting anything is a pain. There seem to be a decent number of Axoloti users, but in github I don't see any major contributors beside the inventor and one other person. I'm a little wary to base a project on a software platform that's well-understood by only two people, and not particularly well-documented either.

Really, I wonder if I could get the Teensy Audio Lib to run on the Axoloti hardware! Is that possible? I imagine there was a lot of complexity in getting the Arduino environment to target the Teensy's ARM chip instead of an Atmel in the first place ... and I don't really know what the Teensy Loader does at all ... but I'm more comfortable writing bare C code with avr-gcc and avrdude anyway. It seems like there's open-source code in the Axoloti project that I can use for working with the SDRAM & audio IO, and there's a Makefile that illustrates how to get it all compiling with gcc. I just don't know what hardware assumptions Teensy Audio is making, and how much would have to change for it to work on this other board.

Also, I'm not sure how Paul would feel about his Teensy-supporting code being ported to other hardware. =/
 
But the other way.. i just forked the code.
Interesting things there, that could be ported to Teensy.

Easiest are the 808-samples.. but there might other interesting effects too, which don't need so much ram.
 
... for the SD-Card idea:

I think you could save some time (some milliseconds) without a filesystem and use blocknumbers instead.
It would be insteresting to know how much channels would work, this way..
Then, for a bit more speedup, you could try to find really old SD-cards in the 512MB -size range. Some time ago i played with some cards and found that they were faster* (perhaps due to simpler internal algorithms or simpler adressing..)
The problem with SD-Cards is adressing blocks - this takes a long time.


Edit:
*for random-access (they were some 100us faster)

edit:
..but i don't believe that more than 2 channels with concurrent read+writes are possible. maybe only one.

I can sort of picture making *something* work using just 2 channels: one channel of writes, multiplexing all 8 channels of audio in parallel in each block, writing sequentially to the buffer, and one read channel that reads the same 8 channels in parallel, but from a different position in the buffer. Metaphorically it'd be like an 8-channel tape loop with the read & write heads at different positions.

Is that possible with SD? Has anyone benchmarked the speed of this direct-block writing/reading to SD, circumventing the filesystem?

On the other hand ... one job of the filesystem layer on a hard drive is to map out bad blocks. Do SD cards get bad blocks? Are they hardware mapped, or would they need to be mapped in firmware? Is read/write speed affected when that happens? Seems like that could be a source of glitches.
 
I want to stay focused on developing awesome features, but the difference in open source licenses is important.

Axoloti is GPLv3 with copyright assignment to Johannes Taelman.

Teensy Audio is MIT or MIT-like. Many people do embed Teensy inside products they sell, or they make their own PCB, sometimes with the chip we sell, sometimes without. My intention has always been to allow people to use the library for their commercial & proprietary purpose, even if they're making their own hardware without buying anything from PJRC. That's not the best or most profitable business decision, but if I only cared about profit I almost certainly wouldn't be making making dev boards and free software platforms. I'm willing to be flexible on license terms for contributed code, but I do want to stay in the permissive spirit of MIT for code people will embed inside microcontrollers. On the PC tool side, GPL is fine.

Please don't submit GPLv3 code for the Teensy Audio Library. Let's respect Axoloti's GPLv3 license.

Edit: but I'm happy to hear about any features Axoloti has that we should consider, and even the algorithms involved. Let's just make sure we're not copying Axoloti's code in violation of its license terms.
 
Last edited:
Has anyone benchmarked the speed of this direct-block writing/reading to SD, circumventing the filesystem?

Well, File > Examples > Audio > Recorder has a couple lines you can uncomment to see the write time. With just a small amount more code, you could print the file offset. If you know the FAT32 cluster size of the filesystem (something I'm sure you could find out with various PC-based utilities reading the card), you should be able to tell which writes are direct to the media and which ones are involving location or allocation of a new cluster.

You could also try File > Examples > SerialFlash > RawHardwareTest on a flash memory chip. It prints some benchmarks about the 256 byte page write time.

In fact, here's a test run on a Macronix MX25L25635FMI-10G (32 Mbyte) chip. 256 bytes writes in 469 us, and that's with the overhead of suspending the write once to read 8 bytes.

Code:
Raw SerialFlash Hardware Test

Read Chip Identification:
  JEDEC ID:     C2 20 19
  Part Nummber: (unknown chip)
  Memory Size:  33554432 bytes
  Block Size:   65536 bytes

Reading Chip...

Writing 32 signatures

Double Checking All Signatures:
  all 16384 signatures read ok

Checking Signature Pairs
  all 8191 signature pairs read ok

Checking Read-While-Write (Program Suspend)
  write 256 bytes at 512
  write time was 469 microseconds.
  read-while-writing: 00 00 00 00 15 F5 95 4B 
  test passed, good read while writing

Checking Read-While-Erase (Erase Suspend)
  erase time was 268634 microseconds.
  erase correctly erased 65536 bytes
  read-while-erasing: 00 00 00 00 15 F5 95 4B 
  test passed, good read while erasing

All Tests Passed  :-)

Test data was written to your chip.  You must run
EraseEverything before using this chip for files.
 
Please don't submit GPLv3 code for the Teensy Audio Library. Let's respect Axoloti's GPLv3 license.

Edit: but I'm happy to hear about any features Axoloti has that we should consider, and even the algorithms involved. Let's just make sure we're not copying Axoloti's code in violation of its license terms.

Sure.
I bet we need some more or less heavy modifications anyway.
 
The Axoloti licensing is definitely an issue for me as well. Right now I'm just trying to make something for myself, but if I do come up with something really handy, I'd like to be able to dream of someday selling it. =)

It sure would be awesome to be able to buy a Teensy shield with audio IO, midi IO, a memory controller and some RAM on it. But for now I think I'm going to play around a little with the Audio Shield & see what kind of raw block performance I can get out of SD cards. Sometimes limitations bring focus.
 
Status
Not open for further replies.
Back
Top