Limits of delay effect in audio library

Paul,

thank you for the good explanation. My thought was that a buffer will help also in other functionalities where some more space could help. But in this case I may explore the functionality of the chip and when I will reach longer delays, I rethink the memory module. As I have a simple DIY SMD oven perhaps this might be a project to collect some experience.
 
Yes, i'm using the memoryboard for other purposes too, not directly for audio.
I use it for buffering data from the WLAN.
It can be used for many things.
Perhaps ask "onehorse", maybe he can build one/some for you ?

I have a LIB in development which allows DMA access to the board. This way you don't have to wait for spi-transfers to and from the board and can do them in the background.
i hav'nt had much time for this the last days, i'll publish it as soon as it is ready.
 
Last edited:
Frank B said:
I have a LIB in development which allows DMA access to the board. This way you don't have to wait for spi-transfers to and from the board and can do them in the background.
i hav'nt had much time for this the last days, i'll publish it as soon as it is ready.
Click to expand...


Frank, any news on your DMA LIB?
I've got two memory4 boards up and running, great job by the way, and I'd like to use them buffer data to/from an SD card.
 
Hi Paolo, yes and no :)
I must admit that I was distracted by other projects.. i have the DMA running smoothly, but it needs some work to make a lib with a good API.
But thank you for the reminder :) I'm a bit busy with non-hobby-things, but i think it is a good time to "reacitivate" this little lib.

As a buffer for SD card - hm, i don't think that this is a good idea. It may help to reduce access-times, but the transfer is not faster (20MHz max for the RAMs). Depends on your plans..
 
Last edited:
Paolo said:
Frank, any news on your DMA LIB?
I've got two memory4 boards up and running, great job by the way, and I'd like to use them buffer data to/from an SD card.
Click to expand...

I had this idea and tested it. All SPI use DMA (sram chip and SD card use DMA)
Problem is the limited number of SPI ports on teensy.
Example:
Assume the SD card blocks access for 10 data buffer, you have then to read data from sram to local ram and then push he data to sd. If at the same time new data are coming you have to push data to sram also. In order to recover delays the process fetch data from sram and push to SD card mast be at least twice as often than acquiring data. I know it is complicated, so let me write it differently

A typical spi sequence during recovery mode on Teensy 3.2 is
push new data to sram
fetch oldest data from sram
push these data to sd
fetch next data set from sram
push these data to sd
until all old data are stored on sd card
OR new data arrive.

One complication is that you do not want the sd card block the spi bus when new data arriving as you may loos them.
Also interrupt management is a nightmare, but feasible.

Overall consequence: using single SPI systems like teensy, overall data rate is reduced by at least a factor of 5 if you do not want to drop data.
If you accept to drop data, no sram card is needed.
Teensy LC is better, but too slow for me. With a 256 kB Teensy 4.0 no sram may be needed.
 
WMXZ said:
With a 256 kB Teensy 4.0 no sram may be needed.
Click to expand...
It might have a faster SD-Cards interface too (parallel) (and a second SPI?) :)

I could imagine to add some simple external logic that swaps the MISO & MOSI - lines on demand.
You could setup both, SD & RAM for the transfer, then swap the lines and do some dummy-reads. That would save half of the time, as the databytes are written "automagically".. :)
 
Last edited:
Frank B,

Here's what I'd like to do at a high level. Parts ordered, no code written yet.

A few dozen BMP images are stored on an SD card. For this example we'll say they are 288X512 24 bit images. A magnetic encoder on the Teensy I2C bus. Your Memory4 board. A strip of 288 APA102 LEDs. Load a BMP from the SD card into SRAM on the memory4 board. Use the encoder to 'select' which of the 512 lines to show on the LEDs, at a speed of 2 rev/sec. Load the next BMP into SRAM and repeat. Might have to have two pages of memory one being written while the other is read. Something tells me there's going to be a traffic jam on the SPI bus.

My math, this is the low end of what I'd like to do, ideally 2X these numbers.
288*24 (pixels*bits per pixel)(I'm not storing the brightness byte for each pixel hence 24 instead of 32)
6912*512 (bits per line*number of lines)
3,538,944*2 (bits per image*images a second)
7,077,888 (bits per second)
7.1 Mb/s

Ideally I'd like to read the images directly off the SD card but I'm not seeing the speed over SPI, and the 'advertised' speeds on SD cards are for the proprietary SDIO bus. This post notes 15 concurrent audio files at 16/44 which is close to the data rate I'd like to see but something tells me the I2S bus is part of the magic in those numbers.
 
Maybe it can work if you build special hardware, probably just a couple logic gates, so the bits coming out of the SPI RAM chips can directly drive the APA102.

So for each read, you'd assert the memory board chip select and send the few bytes the 23LC1024 needs to start the read operation. Then you'd assert another select for your buffer circuit, so it'll start driving whatever the memoryboard sends on MISO to the APA102. Then "read" the data, except you can just discard whatever you get, because the hardware will go directly from the memoryboard to the LEDs.
 
Hi, are there DIP equivalents to the 74LCX126MX and 74LCX138MX ICs used on this? I've love to make this, but don't have the skills or equipment to solder surface mount myself, and haven't been able to find anyone I can pay to do it for me either. I'm happy to make a big version on vero if there are suitable parts available. The RAM chips aren't an issue.

EDIT: Did some looking around, so far have found that this 74LS138 has a DIP variety. I can't see many significant differences other than the supply voltage needs to be pretty much 5V on this one, although I don't really know what I need to look out for. Maybe this will do?

Also for the 74???126 I found this 74LS126 which has a few differences to the 74LCX126MX.
 
Last edited:
No, 5V only 74LS parts will not work. This board must run on 3.3V.

After the voltage, propagation delay is the most important spec. LCX was chosen because it's fast. 74LCX138 has 1.5ns typical, 6.5ns worst case delay and 74LCX126 has 1.5ns typical, 6.0ns worst case delay, and 5.5ns worst case on the important path from input to output.

Short delay from input to output on the 74LCX126 buffers is particularly important for reading data. The SCK falling edge passes through one buffer (typ=1.5ns / worst=5.5ns), then the 23LC1024 chip has an access time (typ=unknown / worst=25ns), and then its data output goes through another buffer (typ=1.5 / worst=5.5ns), where it's then supposed to meet a setup time requirement (typ=unknown / worst=15ns) before the SCK rising edge. All those worst case delays already add up to quite a bit more than the 31.25 ns we're using. To fully accommodate the worst possible case, we really should limit the SPI clock to 9.8 MHz.

We're already depending on these chips to be significantly better than their worst case specs! If you use a much slower buffer chip, it almost certainly won't work at 16 or 20 MHz SPI clock speed.
 
Cool thanks. Speed is an interesting point, having mostly dealt with analog audio I've never considered just how much each buffer stacks up when you need high clock speeds for digital uses. So if SMD is the only option then SMD it is, Frank's memoryboard layout looks great, I'll order one and track down someone locally to solder it.
 
Last edited:
Just try to solder it :)
It was i first SMD board i ever soldered myself, and it was suprisingly easy (i need glasses to read!)
Use tweezers!
 
Frank B said:
I have a LIB in development which allows DMA access to the board. This way you don't have to wait for spi-transfers to and from the board and can do them in the background.
i hav'nt had much time for this the last days, i'll publish it as soon as it is ready.
Click to expand...

Hi Frank,

Has there been any movement on this? I'm looking to do some sampling based stuff with the teensy and I'm thinking the mem. board might be a good option?
 
flightlessturd said:
Is there some example code I could see that relates to addressing the memory so I have somewhere to start?
Click to expand...

This code in the audio lib uses Frank's memoryboard for audio delay.

https://github.com/PaulStoffregen/Audio/blob/master/effect_delay_ext.cpp

Using the memory for sampling ought to be pretty similar. The delay already writes incoming audio into the memory and plays the memory contents. You'll just need to make it start & stop at specific places instead of streaming continuously.
 
Hi, i have a question... if i use teensy 3.2 + audio board + frank memory board, how many pin of teensy are available for buttons and pots? And which?

2,3,4 for memory board only
7,12,14 for memory board and audio board (common)
6,9,10,11,13,15, 22, 23 for audio board
18,19 for i2c

I have available only:
5,8,16,17,20,21 and A10,A11

it's all right?

Thank you.
 
Danixdj,

there are different ways to extend the number of I/Os.

- Use the pads on the bottom for 12 additional IOs. There are some solutions - one is using a board like this (solder it directly to the Teensy) : https://pcbs.io/share/46718
- Use extenders with I2C Chips
 
Frank B said:
Danixdj,

there are different ways to extend the number of I/Os.

- Use the pads on the bottom for 12 additional IOs. There are some solutions - one is using a board like this (solder it directly to the Teensy) : https://pcbs.io/share/46718
- Use extenders with I2C Chips
Click to expand...

Yes my favorite system is by MCP23009 or MCP230017 over i2c but my question is only for direct pin, i like use encoders and they work fine only by direct pin...

I think that the better way is the pads on the bottom :)

5,8,16,17,20,21 and A10,A11 are available? + bottom pads
 
danixdj said:
Hi, i have a question... if i use teensy 3.2 + audio board + frank memory board, how many pin of teensy are available for buttons and pots? And which?

2,3,4 for memory board only
7,12,14 for memory board and audio board (common)
6,9,10,11,13,15, 22, 23 for audio board
18,19 for i2c

I have available only:
5,8,16,17,20,21 and A10,A11

it's all right?

Thank you.
Click to expand...

Pins 0/1 are available. Unlike the Arduino Uno, the USB connection does not use the primary serial UART (which is Serial1 on the Teensy).

I put together this spreadsheet to show what pins are used by what microprocessor or shield (note, it is best on a wide screen, or you will need to do horizontal scrolling):

This board done by FrankB is the easiest to solder to your Teensy 3.2 to get access to the bottom pins on the Teensy:

On the bottom pads you have:
  • 10 additional digital pins (digitalRead, digitialWrite)
  • 6 of the digital pins can also be used in analogRead
  • 3 of the digital pins can also be used in touchRead
  • 2 of the digital pins can also be used as PWM pins for analogWrite
  • if you used 9/10 already, there are 2 of the digital pins that are alternate RX2/TX2 pins for Serial2
  • 2 analog input only pins that cannot be used for digitalRead/digitalWrite
  • Extra 3.3v and ground pins.

Note, you listed A10 and A11. These can only be used for analogRead.

And of course if you need even more pins, there are the Teensy 3.6/3.5 boards. Not counting the pins underneath the Teensy 3.5/3.6 you have:
  • 16 additional digital pins on the outside rows
  • 9 of the digital pins can also be used for analogRead
  • an additional analog input/output pin (and the first DAC was moved in location, so you have 2 DAC's, but with the audio shield, you are probably better going with the shield rather than using DACs)
  • 6 of the digital pins can be used for PWM output
  • On the 3.5, there are an additional 2 analog input pins on the inside row that is the 2nd USB header on the 3.6
  • Underneath the Teensy 3.5/3.6 there are 18 more digital pins.
  • The Teensy 3.5 has 2 analog input pins (no digital) on the insider header that is used for the USB header in the Teensy 3.6

Note, the digital pins on the 3.6 are NOT 5v tolerant. The digital pins on the 3.5 are 5v tolerant.
 
Last edited:
Apologies if this is old news, I am a newbie on this site.

Has anyone tried the Cypress SPI ferroelectric RAM chips? They're available in SOIC 8 pin package with a standard serial RAM pinout. Up to 4Mbit is available.
Datasheet here: http://www.cypress.com/documentation/datasheets/cy15b104q-4-mbit-512-k-8-serial-spi-f-ram-datasheet

I imagine it would be achievable to port the existing delay code. I'm particularly interested in this because I would like to make an ambient reverb effect which requires a total delay memory of approximately 2 seconds for the various filter stages.
 
Last edited:
Good news, also for a long delay effect without audio memory board... using delayExt object and the chip may be added on the bottom side of teensy audio board directly.... right?
 
should be easy but more expensive...

1 x CY15B104Q = 25€
6 x 23LC1024 1 mbit + memory board and his components = 15€ !
 
You must log in or register to reply here.
Back
Top