Audio Library

Status
Not open for further replies.
Today I committed the first installment of converting over from hard-coded DMA numbers to using DMAChannel.h. The I2S objects are using it, but the ADC, DAC and PWM still need to be updated.

I only have hardware for testing I2S master mode. Does anyone have a WM8731 connected in slave mode?
 
None of my mics are suitable for that interface, can't help there sorry (they are all condenser mics).

As people watching GitHub will know, I sent in a couple of pull requests that add a WAVEFORM_PULSE with static pulseWidth. I'm now working on a PulsePWM oscllator (basically a triangle that is then compared to the incoming audio steam for pulse width modulation, to give dynamic PWM).
 
I have some unpleasant news. I need to make a change in DMAChannel.h for the audio library.

The unpleasant result is going to be a dependency on the unreleased core library on github. I'll make a 1.20-rc3 release early next week with this change. In the meantime, there will be compile errors for anyone who gets the latest audio library without also updating hardware/teensy/cores/teensy3/DMAChannel.h and hardware/teensy/cores/teensy3/DMAChannel.cpp.

Briefly, this problem is known as the C++ static initialization order fiasco. I tried several workarounds yesterday. I found one that works, which you can see in the audio code on github today. But if you use "objdump -d" to look at the code the compiler is generating, it's horribly inefficient. If it were only in initialization, I wouldn't be too concerned, but this is burdening the timing critical DMA interrupt code.

A better workaround is needed, and unfortunately this is going to require abandoning 1.20-rc2 compatibility. This truly is a necessary change to pave the way for a long-term stable API for the 1.0 release.
 
I have an audible click and/or pop at the end of each audio track playing. Everything is on a breadboard currently, so I'm trying to see if this is software/hardware. I recall reading somewhere on these forums that it was suggested to add an 1.5 second silence at the end of each wav file, but that did not work. wav.stop() does work, but then that is not a solution for me. Any idea what could solve this issue?

Code: 
#include <Audio.h>
#include <Wire.h>
#include <SD.h>
#include <SPI.h>

// Create the Audio components.  These should be created in the
// order data flows, inputs/sources -> processing -> outputs
//
AudioPlaySdWav     wav;
AudioOutputI2S     dac;

// Create Audio connections between the components
//
AudioConnection c1(wav, 0, dac, 0);
AudioConnection c2(wav, 1, dac, 1);

// Create an object to control the audio shield.
// 
AudioControlSGTL5000 audioShield;


void setup() {
  // Audio connections require memory to work.  For more
  // detailed information, see the MemoryAndCpuUsage example
  Serial.begin(38400);//usb - serial port
  Serial1.begin(9600); //headset - master
  Serial2.begin(9600); //phone - slave must initialize before serial2 port remaps to be able to use serial 2 while using audio
  CORE_PIN9_CONFIG = PORT_PCR_MUX(6);//required to remap pins for audio to play at same time as serial two
  CORE_PIN10_CONFIG = PORT_PCR_MUX(1);//required to remap pins for audio to play at same time as serial two
  CORE_PIN26_CONFIG = PORT_PCR_MUX(3);//required to remap pins for audio to play at same time as serial two
  CORE_PIN31_CONFIG = PORT_PCR_MUX(3);//required to remap pins for audio to play at same time as serial two

  AudioMemory(5);

  audioShield.enable();
  audioShield.volume(.7);

  SPI.setMOSI(7);
  SPI.setSCK(14);
  if (SD.begin(10)) {
    wav.play("050SHOTY.WAV");
    delay(1000);
    wav.stop();
    wav.play("050SHOTY.WAV");
    delay(1000);
    wav.stop();
    wav.play("050SHOTY.WAV");
    delay(1000);
  }
}

void loop() {
//  float vol = analogRead(15);
//  vol = vol / 1024;
//  audioShield.volume(vol);
//  delay(20);
}
 
PaulStoffregen said:
Can you upload those 3 WAV files somewhere, maybe dropbox?
Click to expand...

https://app.box.com/s/yr3r15jvqaor6qcuwuds

Link above, I think it works OK when I convert to RAW files, no click/pop, just when using WAV format at closing. It also seems unable to play rapid fire fluidly (stutters now and then) such as under 80ms, not very fluid on repeat (IE, auto-fire shotty), but maybe I just need to use file indexing like I used to rather than making it call the file name.
 
I believe I found a bug. I have some time sensitive code and during the oscillation while an audio file is playing, the delayMicro() and micros() functions seem to return inconsistent times, causing my communications to have jitters and failures.

Code: 
#include <Audio.h>
#include <Wire.h>
#include <SD.h>
#include <SPI.h>

// Create the Audio components.  These should be created in the
// order data flows, inputs/sources -> processing -> outputs
//
AudioPlaySdRaw     wav;
AudioOutputI2S     dac;

// Create Audio connections between the components
//
AudioConnection c1(wav, 0, dac, 0);
AudioConnection c2(wav, 1, dac, 1);

// Create an object to control the audio shield.
// 
AudioControlSGTL5000 audioShield;


void setup() 
{
  // Audio connections require memory to work.  For more
  // detailed information, see the MemoryAndCpuUsage example
  pinMode(25,OUTPUT); //pin to oscillate

  AudioMemory(50);

  audioShield.enable();
  audioShield.volume(0.1);

  SPI.setMOSI(7);
  SPI.setSCK(14);
  if (SD.begin(10)) {
    //wav.play("01_16M.WAV");
  }
}

void loop() 
{
  for (byte x = 20; x >0; x--)
  {
    oscillationWrite(25, 1000); //send start bit, actually first bit
    delayMicroseconds(500); // wait
    oscillationWrite(25, 500); //send start bit, actually first bit
    delayMicroseconds(500); // wait
  }
  delay(500);
  wav.play("059AP.RAW");

}
void oscillationWrite(byte pin, int time) 
{
  for (byte i = 0; i < time / 26; i++) // time/26 = 38khz
  {
    digitalWrite(pin, HIGH);
    delayMicroseconds(6);  
    digitalWrite(pin, LOW);
    delayMicroseconds(20);
  }
}

You can test this w/ any wave or raw file, but you will need an oscilloscope to see that the timings are wrong. Sometimes when it goes high we have the correct amount, other times too short/long etc. Spacers are not always accurate either. A work around is to turn off audio during the oscillation phase to get proper timings w/ AudioNoInterrupts(); and back on at end with AudioNoInterrupts(). This is not ideal because it makes the audio very choppy for my purposes. I think this problem existed w/ waveHC and waveshield, but it was not as bad. I don't think file indexing will fix this but it might. Any other solutions? I'm using class 4 SD card.
 
And here is a more complicated example that shows the bad timings returned during multi-file playback. Again, you can substitute any sound file in here, they all do the same thing. 16 bit 44khz used, reports back about 67% audio max cpu usage, can change that pretty easily by adding more effects then the timings get really off.

DS1Z_QucikPrint16.jpg

Code: 
#include <Audio.h>
#include <Wire.h>
#include <SD.h>
#include <SPI.h>

// Create the Audio components.  These should be created in the
AudioMixer4        mix1;    // two 4-channel mixers are needed in
AudioMixer4        mix2;    // tandem to combine 6 audio sources

// Create Audio connections between the components
AudioPlaySdRaw     wav;
AudioPlaySdRaw     wav2;
AudioPlaySdRaw     wav3;
AudioPlaySdRaw     wav4;
AudioPlaySdRaw     wav5;
AudioOutputI2S     dac;
// Create Audio connections between the components
// order data flows, inputs/sources -> processing -> outputs
AudioConnection c1(wav, 0, mix1, 0);
AudioConnection c2(wav2, 0, mix1, 1);
AudioConnection c3(wav3, 0, mix1, 2);
AudioConnection c4(wav4, 0, mix1, 3);
AudioConnection c5(wav5, 0, mix1, 4);
AudioConnection c6(mix1, 0, mix2, 0);   // output of mix1 into 1st input on mix2
AudioConnection c7(mix1, 0, mix2, 1);
AudioConnection c8(mix1, 0, mix2, 2);
AudioConnection c9(mix1, 0, mix2, 3);
AudioConnection c10(mix1, 0, mix2, 4);
AudioConnection c11(mix2, 0, dac, 0);

//// Create the Audio components.  These should be created in the
//// order data flows, inputs/sources -> processing -> outputs
////
//AudioPlaySdRaw     wav;
//AudioOutputI2S     dac;
//
//// Create Audio connections between the components
////
//AudioConnection c1(wav, 0, dac, 0);
//AudioConnection c2(wav, 1, dac, 1);
//
//// Create an object to control the audio shield.
//// 
AudioControlSGTL5000 audioShield;


void setup() 
{
  // Audio connections require memory to work.  For more
  // detailed information, see the MemoryAndCpuUsage example
  pinMode(25,OUTPUT); //pin to oscillate

  AudioMemory(150);

  audioShield.enable();
  audioShield.volume(0.1);

  SPI.setMOSI(7);
  SPI.setSCK(14);
  if (SD.begin(10)) {
    //wav.play("01_16M.WAV");
  }
}

void loop() 
{
  for (byte x = 20; x >0; x--)
  {
    oscillationWrite(25, 1000); //send start bit, actually first bit
    delayMicroseconds(500); // wait
    oscillationWrite(25, 500); //send start bit, actually first bit
    delayMicroseconds(500); // wait
  }
  AudioProcessorUsageMaxReset();
  delay(150);
  wav.play("059AP.RAW");
  delay(130);
  wav2.play("059AP.RAW");
  delay(125);
  wav.play("059AP.RAW");
  delay(120);
  wav2.play("059AP.RAW");
  Serial.println(AudioProcessorUsageMax());

}
void oscillationWrite(byte pin, int time) 
{
  for (byte i = 0; i < time / 26; i++) // time/26 = 38khz
  {
    digitalWrite(pin, HIGH);
    delayMicroseconds(6);  
    digitalWrite(pin, LOW);
    delayMicroseconds(20);
  }
}


Once we can get rid of the issue w/ delayMicro()/micros() not reporting properly while audio playback, I think we can move forward with pre-production models.
 
Last edited:
zachtos said:
I believe I found a bug. I have some time sensitive code and during the oscillation while an audio file is playing, the delayMicro() and micros() functions seem to return inconsistent times, causing my communications to have jitters and failures.
Click to expand...

I have tried everything I can think of and am stumped on this, 30+ hours trying to work around this bug. This is the only thing holding me back from pre-production. I have tried timerOne library, it calls a function that interrupts every 100uS and increments a counter (uses different timer than audio library). Same thing, timings were dead on while AudioNoInerrupts() but as soon as I turned them back on during oscillation, it caused broken timings. I am using 1.20rc2 teensyduino now and the v1.19 audio library. Maybe the newer audio library you are working on can help?
 
Some of the timing issues you're seeing are probably unavoidable. Every 2.9 ms, the audio library interrupt runs. If you've got a substantial amount of stuff, it takes CPU time. There's functions to estimate the CPU usage.

For example, if you're at 25% CPU usage, then every 2.9ms, the library will consume CPU for 0.725 ms. During those 725 us, the main Arduino sketch doesn't run. Timing where you look at micros() or delayMicroseconds() will suddenly lose 725 us when the audio stuff runs. There's nothing that can be done about that.

Most interrupt should have much higher priority than the audio library. For example, IntervalTimer and even TimerOne should run at reliable timing.

However, the audio library does use tiny amounts of CPU time at higher priority. These should be under 50 us. They are needed when the DMA transfer complete.

You can try using NVIC_SET_PRIORITY(irq, priority) to raise the priority level of your timing critical interrupt. See kinetis.h for the IRQ numbers. Lower numbers are higher priority, so use 0 for the highest.
 
PaulStoffregen said:
Some of the timing issues you're seeing are probably unavoidable. Every 2.9 ms, the audio library interrupt runs. If you've got a substantial amount of stuff, it takes CPU time. There's functions to estimate the CPU usage.

For example, if you're at 25% CPU usage, then every 2.9ms, the library will consume CPU for 0.725 ms. During those 725 us, the main Arduino sketch doesn't run. Timing where you look at micros() or delayMicroseconds() will suddenly lose 725 us when the audio stuff runs. There's nothing that can be done about that.

Most interrupt should have much higher priority than the audio library. For example, IntervalTimer and even TimerOne should run at reliable timing.

However, the audio library does use tiny amounts of CPU time at higher priority. These should be under 50 us. They are needed when the DMA transfer complete.

You can try using NVIC_SET_PRIORITY(irq, priority) to raise the priority level of your timing critical interrupt. See kinetis.h for the IRQ numbers. Lower numbers are higher priority, so use 0 for the highest.
Click to expand...

Thanks, I'll keep trying. Not sure if I'll be able to solve it then. I've tried interval timer and timerOne, both had the same issue while audio is playing back w/ messing up oscillation timings in above example. The 50 uS delay you speak of should not be enough to matter, but many of the timings are severely off in the example above. If you have time to test any of the sample code above, I would love the input. Otherwise I'll keep chipping away my week on it.

-timings work fine if the SD card is removed, not sure if it's still sending data/interrupts etc, or if that points to SPI lag? (also tested class 10 SD card, waveform was slightly different, but still very off on timings)

-cpu says 88% w/ the audio max option, depends on the wave/raw file used. 4 for memory. maybe if it would work better if the files could have option to be processed as mono, 22khz like I used to w/ waveHC library? Some files w/ more timing sensitive operations I ran at a different frequency w/ lower audio quality.
 
Last edited:
How many files are you playing simultaneously? Are the mono or stereo?

Edit: quite likely 2 factors are happening... limited SPI bus bandwidth to the SD card, and slowness in the Arduino SD library.

Yes, perhaps the WAV player needs more code to play & upsample 11 and 22 kHz WAV files. The memory player has this, so it's not a huge leap, but they it's also more code that won't write itself. I'll probably work on this after a 1.0 release is made, unless of course someone else does it first.
 
Last edited:
I also have been experimenting with AudioPlaySDWav and AudioPlaySDRaw. I am able to play 2 files simultaneously and they sound great. I start to hear noise when I play 3 simultaneously, and its pretty distorted when I play 4 simultaneously. These are 44 kHz 16 bit Mono files. Tested both WAV and Raw formats. Sorry I don't have my code to paste, but it is exactly the same as the WavFilePlayer.ino example, except with more AudioPlaySD* instances and more AudioMemory. My SD card is a Toshiba class 10 and I benchmarked it's read speed at 20MB/s.

BTW -- whatever bug fixes you have been doing have greatly improved the performance of AudioEffectDelay in my LaborDayDelay patch from a couple weeks ago. I can use longer delay times without distortion or drop outs. Sounds way better.
 
I'm glad the delay is working great.

When the 3 files are playing, can you look at AudioProcessorUsageMax() to see what the worst case CPU usage is?

On the SD card, 20 MB/s is probably for sustained reads. For playing multiple files, the card is being read 1 block at a time from 3 different files, plus random accesses within the FAT each time a cluster boundary is crossed. Some programs like CrystalDiskMark have benchmarks for small size random reads. Even those are usually for 4K blocks rather than 0.5K sectors, but such a benchmark is far more realistic for this type of access pattern. Some cards are pretty good, but many with great sequential performance are quite dismal for random seeks with small reads.

Maybe I should improve the speed test example to do a test with reading from several files?
 
PaulStoffregen said:
How many files are you playing simultaneously? Are the mono or stereo?

Edit: quite likely 2 factors are happening... limited SPI bus bandwidth to the SD card, and slowness in the Arduino SD library.

Yes, perhaps the WAV player needs more code to play & upsample 11 and 22 kHz WAV files. The memory player has this, so it's not a huge leap, but they it's also more code that won't write itself. I'll probably work on this after a 1.0 release is made, unless of course someone else does it first.
Click to expand...

I'm currently playing 3-4 sound effects at a time (mono), but I noticed I still get 50-90%cpu usage during oscillation no matter how much code I comment out, and maybe only 70-80% usage when only one effect. But, the timing issue still persists even w/ only one sound at a time.
 
PaulStoffregen said:
I'm glad the delay is working great.

Maybe I should improve the speed test example to do a test with reading from several files?
Click to expand...

yes, anything you can do to help would be great. I really want to move to the next phase of production as soon as I figure out this audio timing bug while playing back sounds off SD cards. We really do feel good about buying boot-oader chips to help sustain teensyduino development once we move to custom PCB layout.
 
I've been trying to setup interrupt priority based on the chart shown in kinetis.h for teensy 3.1. Not sure If I'm doing it right, but basically just want to give timer1 a high priority so perhaps it returns accurate values or will increment every 50uS no matter what, which does not work while audio is playing. I still get odd timings when audio is playing, but perfect when I turn it back off. Tried a variety of SD cards. It seems so close, but every now and then the wave form will double.

Code: 
#include <Audio.h>
#include <Wire.h>
#include <SD.h>
#include <SPI.h>
#include <TimerOne.h>

// Create the Audio components.  These should be created in the
// order data flows, inputs/sources -> processing -> outputs
//
AudioPlaySdRaw     wav;
AudioOutputI2S     dac;

// Create Audio connections between the components
//
AudioConnection c1(wav, 0, dac, 0);
AudioConnection c2(wav, 1, dac, 1);

// Create an object to control the audio shield.
// 
AudioControlSGTL5000 audioShield;
long IR_timestamp;
volatile unsigned long timer = 0;
unsigned long start_time = 0;

void setup() 
{
  // Audio connections require memory to work.  For more
  // detailed information, see the MemoryAndCpuUsage example
  Timer1.initialize(50);//microseconds);
  Timer1.attachInterrupt(waitIR);//Run a function each time the timer period finishes.
  NVIC_SET_PRIORITY(68,128);//(irq, priority); 
  NVIC_SET_PRIORITY(94,0);//(irq, priority); 
  NVIC_SET_PRIORITY(69,0);//(irq, priority); 
  NVIC_SET_PRIORITY(87,0);//(irq, priority); 
  NVIC_SET_PRIORITY(70,128);//(irq, priority); 
  NVIC_SET_PRIORITY(71,128);//(irq, priority); 
  Serial.begin(38400);
  analogWriteFrequency(25, 38000); // Teensy 3.0 pin 3 also changes to 375 kHz
  analogWriteResolution(10);//10	0 - 1023	46875 Hz
  pinMode(25,OUTPUT); //pin to oscillate

  AudioMemory(20);

  audioShield.enable();
  audioShield.volume(0.2);

  SPI.setMOSI(7);
  SPI.setSCK(14);
  if (SD.begin(10)) {
    //wav.play("01_16M.WAV");
  }
}

void loop() 
{
  // AudioNoInterrupts(); //enable this line to fix waveform
  for (byte x = 12; x >0; x--)
  {
    oscillationWrite_new(25, 1200); //send start bit, actually first bit
    IR_spacer(25,600);
    oscillationWrite_new(25, 600); //send start bit, actually first bit
    IR_spacer(25,600);
  }
  // AudioInterrupts();  //enable this line to fix waveform
  wav.play("050SHOTY.RAW"); //play the sound effect, can use any sound here w/ same results
  delay(100);
  ///memory debug code below//
  //byte cpu = AudioProcessorUsageMax();
  // Serial.println(cpu);
  //byte mem = AudioMemoryUsageMax();
  //Serial.println(mem);
  //AudioProcessorUsageMaxReset();
}

void oscillationWrite_new(byte pin, int time) //only 20% duty cycle allows you to push the LED harder then normal
{
  analogWrite(pin, 300);
  start_time = timer;
  while(timer - start_time < time/50)
  {
    //main_loop();
  }
  analogWrite(pin, 0);
}

void IR_spacer(byte pin, int time)
{
  analogWrite(pin, 0);
  start_time = timer;
  while(timer - start_time < time/50)
  {
    //main_loop();
  }
}
void waitIR(void) 
{
  timer++;  // increase when LED turns on
}

DS1Z_QucikPrint20.jpg
this is correct waveform w/o audio playback during timings

DS1Z_QucikPrint21.jpg
this is what the waveforms do during audio playback from SD card
 
Just to give you a realistic expectation, it'll probably be early next week when I can really look into this timing issue.

Right now, I really have to work on a 1.20 release, since Arduino (finally) released version 1.0.6.
 
PaulStoffregen said:
When the 3 files are playing, can you look at AudioProcessorUsageMax() to see what the worst case CPU usage is?
Click to expand...

Funny, I am able to play 4 files now without distortion, just a periodic click. The CPU usage is high though. I hear the click at the same time the memory usage drops from 2 to 1. I'm logging usage every 1 millisecond here. The samples are about 3 seconds long each. This is nothing urgent for me, just reporting my findings.

Code: 
Proc = 90 (131),  Mem = 2 (5)
Proc = 96 (131),  Mem = 2 (5)
Playing clip 3
Proc = 95 (131),  Mem = 1 (5) <-- CLICKY SOUND HERE
Proc = 92 (131),  Mem = 1 (5)
Proc = 89 (131),  Mem = 1 (5)
Proc = 87 (131),  Mem = 1 (5)
Proc = 85 (131),  Mem = 1 (5)
Proc = 93 (131),  Mem = 2 (5)
Proc = 95 (131),  Mem = 2 (5)
Proc = 93 (131),  Mem = 2 (5)
Proc = 95 (131),  Mem = 2 (5)
Proc = 93 (131),  Mem = 2 (5)

Here's the sketch I'm testing with:

Code: 
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>

// GUItool: begin automatically generated code
AudioPlaySdRaw           playRaw1;       //xy=247,205
AudioPlaySdRaw           playRaw3;       //xy=249,281
AudioPlaySdRaw           playRaw2;       //xy=250,242
AudioPlaySdRaw           playRaw4;       //xy=250,319
AudioMixer4              mixer1;         //xy=423,231
AudioOutputI2S           i2s1;           //xy=597,232
AudioConnection          patchCord1(playRaw1, 0, mixer1, 0);
AudioConnection          patchCord2(playRaw2, 0, mixer1, 1);
AudioConnection          patchCord3(playRaw3, 0, mixer1, 2);
AudioConnection          patchCord4(playRaw4, 0, mixer1, 3);
AudioConnection          patchCord5(mixer1, 0, i2s1, 0);
AudioConnection          patchCord6(mixer1, 0, i2s1, 1);
AudioControlSGTL5000     sgtl5000_1;     //xy=411,423
// GUItool: end automatically generated code

void setup()
{
  AudioMemory(12);
  Serial.begin(9600);

  sgtl5000_1.enable();
  sgtl5000_1.volume(0.5);

  SPI.setMOSI(7);
  SPI.setSCK(14);
  SD.begin(10);

  mixer1.gain(0, 0.3);
  mixer1.gain(1, 0.3);
  mixer1.gain(2, 0.3);
  mixer1.gain(3, 0.3);

  // Initialize processor and memory measurements
  AudioProcessorUsageMaxReset();
  AudioMemoryUsageMaxReset();

}

unsigned long last_time = millis();
void loop()
  if (!playRaw1.isPlaying()) {
    Serial.println("Playing clip 1");
    playRaw1.play("FLOWERS1");
  }

  if (!playRaw2.isPlaying()) {
    Serial.println("Playing clip 2");
    playRaw2.play("BLIND2");
  }

  if (!playRaw3.isPlaying()) {
    Serial.println("Playing clip 3");
    playRaw3.play("BLIND1");
  }
  
  if (!playRaw4.isPlaying()) {
    Serial.println("Playing clip 4");
    playRaw4.play("MILK1");
  }

  if(millis() - last_time >= 1) {
    Serial.print("Proc = ");
    Serial.print(AudioProcessorUsage());
    Serial.print(" (");    
    Serial.print(AudioProcessorUsageMax());
    Serial.print("),  Mem = ");
    Serial.print(AudioMemoryUsage());
    Serial.print(" (");    
    Serial.print(AudioMemoryUsageMax());
    Serial.println(")");
    last_time = millis();
  }
}
 
Last edited:
I've updated the SdCardTest example to perform a better benchmark.

This led to the unpleasant discovery that the recent SPI transaction patch in the SD library was causing the SPI clock to default to only 8 MHz, rather than 24 MHz.

I've updated the SD library. Here's the file to grab:

https://github.com/PaulStoffregen/SD/blob/master/utility/Sd2Card.cpp

Please give the new SdCardTest benchmark a try. It does a much better test, to give you a good idea of your SD card's actual performance when reading multiple WAV files.

For example, here's a 8GB Kingston card:

Code: 
SD Card Test
------------
SD card is connected :-)
Card type is SDHC
File system space is 7813.99 Mbytes.
SD library is able to access the filesystem

Reading SDTEST1.WAV:
  Overall speed = 0.67 Mbyte/sec
  Worst block time = 1.44 ms
    49.77% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV:
  Overall speed = 0.51 Mbyte/sec
  Worst block time = 3.28 ms
    113.12% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV staggered:
  Overall speed = 0.51 Mbyte/sec
  Worst block time = 2.75 ms
    94.72% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV:
  Overall speed = 0.50 Mbyte/sec
  Worst block time = 4.98 ms
    171.54% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV staggered:
  Overall speed = 0.50 Mbyte/sec
  Worst block time = 3.91 ms
    134.80% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV:
  Overall speed = 0.49 Mbyte/sec
  Worst block time = 6.67 ms
    229.86% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV staggered:
  Overall speed = 0.49 Mbyte/sec
  Worst block time = 5.08 ms
    174.99% of audio frame time

Here the same test run on a 16GB Sandisk Ultra card (the red+gray one):

Code: 
SD Card Test
------------
SD card is connected :-)
Card type is SDHC
File system space is 15923.15 Mbytes.
SD library is able to access the filesystem

Reading SDTEST1.WAV:
  Overall speed = 1.29 Mbyte/sec
  Worst block time = 1.74 ms
    60.01% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV:
  Overall speed = 1.29 Mbyte/sec
  Worst block time = 1.57 ms
    54.08% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV staggered:
  Overall speed = 1.29 Mbyte/sec
  Worst block time = 1.20 ms
    41.26% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV:
  Overall speed = 1.29 Mbyte/sec
  Worst block time = 2.34 ms
    80.62% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV staggered:
  Overall speed = 1.29 Mbyte/sec
  Worst block time = 1.59 ms
    54.97% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV:
  Overall speed = 1.30 Mbyte/sec
  Worst block time = 3.11 ms
    107.23% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV staggered:
  Overall speed = 1.30 Mbyte/sec
  Worst block time = 2.00 ms
    68.76% of audio frame time
 
I'm looking at the code on #884, but I do not have the file 059AP.RAW.

My general policy is not to waste time trying to reproduce problems when anything is missing.

However, looking at the code, this appears to be attempting to create a IR remote waveform by bit-bashing. That's never going to work from the main program with interrupts enabled and interrupt-based libraries like Audio running. You really need to use something like the IRremote library, or build you own based on the CMT timer or even IntervalTimer (which would burn a lot of CPU time at 76000 interrupts per second).
 
PaulStoffregen said:
I'm looking at the code on #884, but I do not have the file 059AP.RAW.

My general policy is not to waste time trying to reproduce problems when anything is missing.

However, looking at the code, this appears to be attempting to create a IR remote waveform by bit-bashing. That's never going to work from the main program with interrupts enabled and interrupt-based libraries like Audio running. You really need to use something like the IRremote library, or build you own based on the CMT timer or even IntervalTimer (which would burn a lot of CPU time at 76000 interrupts per second).
Click to expand...

059AP.RAW - Here is a link to the RAW file, but it seems to perform the same timing issues regardless of what file I playback. I actually already have been trying to solve this using IntervalTimer and timerOne libraries without luck. Correct, I am bit-banging IR output and it works fine as long as audio is disabled during the brief 30ms transmissions, which makes audio choppy while rapidly transmitting, even w/ the interrupt methods...
 
Each audio frame is 2.9 ms. Disabling interrupts for 30 ms means you'll drop about 9 or 10 frames.

Bit-bashing I/O like this simply isn't an option when using the audio library. I could investigate in detail here, but if the only problem is your bitbash waveform has gaps, that's definitely going to fall into "not a bug" in the audio library.

I actually already have been trying to solve this using IntervalTimer and timerOne libraries without luck.
Click to expand...

This really is the way to go.

Perhaps start a new thread, just about that technique. As always, the forum rule is complete code to demonstrate the problem. It doesn't need to be your whole commercial application, but if you want real help on this, you're going to have to write a small demo for just that part, with just the audio lib playing files at the same time.
 
Hi guys

i would like to ask you for advice. I am strugling with project wireless audio stream. I have done one prototype (with arduino+nRF24L01 -> nRF24L01+arduino with PWM output) but its only 8b with fs=24kHz and quality for music is very bad. I found this audio shield for Teensy 3.1 and i suppose it would be better to use this concept. So, i would like to know (or be more sure, cos i will spend and money and time) if this idea is feasible to sample audio signal 16b/44.1Khz maybe make some effects with data (with acceptable processing latency) and then via SPI sent it to TX(nRF24L01) and receive it on the other RX . Thnx in advance
 
Status
Not open for further replies.
Back
Top