Serial1.print() causes Audio Library / Adapter Crackling.

Status
Not open for further replies.

mpinner

Member
Ive almost 6 audio adapters, sdcards, teensies, and xbee all working quite nicely together. it sounds and synchronizes surprisingly good.

audioTeensyXbee-sm.jpg

buttons on each teensy play sound files on all teensies. we're using Serial1 (pins 0 and 1) to write chars to an xbee.

when we:
Serial1.print() the audio clicks.
Serial.print() no click.
Serial2 breaks everything.

What do you recommend? Is there some internal shared timer thing going on? Is there a safer Serial for this?

thanks!

code: https://github.com/adellelin/SymphonicPicnic/tree/master/TeensyButtonXbeeSound_v2

Code:
// sending serial command to other Xbees + play file
void sendAndPlay(char command) {

  Serial1.print(command);
  Serial1.flush();

  log("sending :");
  log(command);

  // react
  playSound(command);

  return;

}
 
Are you using the serial for tx only ? If yes, it could help to lower the priority of the interrupt.
How long is the sent command ?
 
@Frank, Thanks for having a look. we are currently using both tx and rx to send button presses to all the other devices and receive button presses. these might have to be high priority to audio closely sync'd and minimize latency.

i'd be curious to try reducing the priority to see if it helps. what does that mean? how do i do that on Teensy3.2 for Serial1?

thanks!
 
reducing the priority by setting Serial1 to 255 didn't seem to make a difference:

Code:
  NVIC_SET_PRIORITY(IRQ_UART0_STATUS, 255); // 255 = lowest priority
  NVIC_ENABLE_IRQ(IRQ_UART0_STATUS);
 
Oh, maybe this is a SD library issue? The original Arduino SD lib wasn't designed for this demanding usage.

Please try editing SD_t3.h to turn on the experimental optimized version of the SD library. Hopefully that will help?
 
I tried this:
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

AudioInputUSB            usb1;           //xy=200,69
AudioOutputAnalog          i2s1;           //xy=365,94
AudioConnection          patchCord1(usb1, 0, i2s1, 0);
AudioConnection          patchCord2(usb1, 1, i2s1, 1);

void setup() {                
  AudioMemory(12);
Serial1.begin(9600);
Serial1.print(F_CPU);
}

void loop() {
  Serial1.print("Hello World");
}

Sound is ok without crackling. So it's no general problem, i think..
What's the processor-usage of your sketch ?

Edit: Processor-usage of audio-lib.... :)
 
Last edited:
Sorry, i meant the %-usage of the audio-library..

Hm, did you try to overclock a bit more ? 120 or 144 MHz ? Does this change anything ? Or, the other way round..72MHz? Might be interesting - do you get more or less crackling with other F_CPU (or does'nt that change anything) ?
 
@Frank, Im not seeing in your code where you call play(...)

From my experience an call to play and Serial1.print will crackle.
playMem1.play(AudioSampleSnare);
Serial1.println("hello");

Thanks for the cpu tip. I'll try that when i get home.

thanks again!
 
@Frank, Im not seeing in your code where you call play(...)

From my experience an call to play and Serial1.print will crackle.
playMem1.play(AudioSampleSnare);
Serial1.println("hello");

Thanks for the cpu tip. I'll try that when i get home.

thanks again!

Usbaudio does not need play().
Anyway, do you call play in a loop ? That will not work.. the sound will be restarted and might result in crackling.

if (!playMem1.isPlaying()) playMem1.play(AudioSampleSnare);
Serial1.println("hello");
 
Hi Frank, I am working on the same project.

The crackling sound appears at the point of the Serial1.println("hello") and not the play();

We have tested putting a delay between the the two commands

Code:
  playMem1.play(AudioSampleSnare);
  delay(1000);
  Serial1.write(command);

and that only pushes the crackling a second out.

Overclocking to 120 or 144 Mhz didn't really change the audio much.

Changing the baud rate to 57600 and 115200 made the crackling a little more intermittent, which is a bit of an improvement.
 
any new ideas on this? it seems odd that Serial1 would have such an effect when Serial does not. I'm not even sure where to dig in to start understanding this.

Perhaps I'll try soft serial on these pins or use serial1 with other pin mapping to add some data to the issue.

-matt
 
If the receiving end of Serial1 can take it you can double the Serial1 baud rate from Teensy another time or two - up to 2Mbit, it can run at 4 or above but the returns can diminish.

'Serial' is a misnomer for USB - and that is a different set of code that behaves differently from the hardware Serial1.
 
any new ideas on this? it seems odd that Serial1 would have such an effect when Serial does not. I'm not even sure where to dig in to start understanding this.

Perhaps I'll try soft serial on these pins or use serial1 with other pin mapping to add some data to the issue.

-matt

I took a quick look at your (linked) code in post #1. With all these audio-objects, AudioMemory(8) is a bit too less, i think.. Did you try much higher numbers ? Try AudioMemory(40)..
Where does this 8 come from ?
 
Sorry, if I am maybe reaching... But have it verified that it was the Serial.write() and not maybe the XBee connected to pins 0,1? i.e. if you remove the connection from the XBee, do you still get this sound?

If you do, you might try hacking the code and instead of doing the Serial1.print(command) and flush, you might try output direct to the hardware registers without interrupts. But... Don't mix this with doing other Serial.write...

Something like:
Code:
  while (!(UART0_S1 & UART_S1_TDRE)) ;    // wait until Uart has room
  UART0_D = command;
Again may have entered this wrong, but...
 
KurtE,

Removing the XBee did in fact fix the issue! of course i cannot communicate now without my xbee attached.

What does this all mean? is the power draw too much for twiddling the xbee data pins? or does the xbee serial buffers somehow slow things down?

i tried the software serial (instead of hardware) attached to these xbee pins and got the same crackling.

here is the circuit in case that helps:
Screen Shot 2016-07-11 at 6.31.02 PM.jpg

i tried the direct serial manipulation via registers, but it dint work. i think i need to better understand the underlining setup for this to work.

thanks, matt
 
frank,

Great catch. The AudioMemory(8) was just copy/paste. Good to better understand this now. It didn't seem to help with this particular crackling, but as we dial-up the complexity and layering of sounds it'll be good to watch this one moving forward.

thanks again!

-matt
 
i tried to run wire from the Serial1 pins (0,1) directly to a second boards Serail1 pins and they're working without the xbees. hmmmmmm? i bet im missing some passives somewhere...
 
That makes a lot more sense. The audio library is designed to tolerate quite a lot of interrupt latency, and the serial interrupts are designed to impose very little. Some libs, like NeoPixel and FastLED with WS2812 do impose a lot of latency and have caused audio glitches, but serial really shouldn't.

But analog issues like ground loops are tough.

As a quick test, perhaps try powering the Xbee from its own 3V battery, or a 3V power supply you know is floating (not earth grounded). Maybe put 1K resistors in series with the signals, so only GND is directly connected between the floating XBee and Teensy. The idea is to keep the XBee from drawing any power or ground current through any of the wiring that might impact the analog signals.
 
Removing the XBee did in fact fix the issue! of course i cannot communicate now without my xbee attached.

What does this all mean? is the power draw too much for twiddling the xbee data pins? or does the xbee serial buffers somehow slow things down?

i tried the software serial (instead of hardware) attached to these xbee pins and got the same crackling.
Probably a question for some more hardware oriented people up here. But my two guesses are:
1) power draw when the XBee sends the message, causes voltage drop? or Noise on the voltage lines... (add caps?)
2) Interference - the RF of the XBee is causing some form of noise... (Move XBee and/or Antenna make a difference?
here is the circuit in case that helps:
View attachment 7608

i tried the direct serial manipulation via registers, but it dint work. i think i need to better understand the underlining setup for this to work.
I probably slightly goofed on the doing the registers, in that if you called: Serial.print(1), it will not output 1 but will output an Ascii 1.

Now assuming that you have less than 9 (or 10) commands, could change the one line to: UART0_D = '0' + command;
 
powering the xbee separately worked great! (i'll re-name this thread)
i ended up powering the teensy from usb and the xbee via the 3.3v regulator. the grounds were tied together.

@kurtE, forgive my ignorance here, i understand in theory how "adding caps" can smooth out power draws or provide more available current for these heavy draw spikes.

in practice there are many types and values for caps. can you elaborate a little or help with links/keywords that might help me fix my current boards?

thanks all!

such a strange path to troubleshooting this one. i'll be able access an oscope and logic analyzer later this evening with hopes of characterizing this a bit further.
 
Status
Not open for further replies.
Back
Top