PDA

View Full Version : Serial1.print() causes Audio Library / Adapter Crackling.



mpinner
07-05-2016, 07:54 PM
Ive almost 6 audio adapters, sdcards, teensies, and xbee all working quite nicely together. it sounds and synchronizes surprisingly good.

7550

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



// 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;

}

Frank B
07-05-2016, 08:44 PM
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 ?

mpinner
07-05-2016, 08:47 PM
@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!

PaulStoffregen
07-05-2016, 08:54 PM
The hardware serial interrupt priority setting is here:

https://github.com/PaulStoffregen/cores/blob/master/teensy3/serial1.c#L43

Maybe try a lower priority (larger number) than 64?

mpinner
07-05-2016, 09:21 PM
reducing the priority by setting Serial1 to 255 didn't seem to make a difference:



NVIC_SET_PRIORITY(IRQ_UART0_STATUS, 255); // 255 = lowest priority
NVIC_ENABLE_IRQ(IRQ_UART0_STATUS);

PaulStoffregen
07-06-2016, 12:27 AM
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?

mpinner
07-07-2016, 03:46 AM
Thanks @Paul

i tried building with the SD_t3.h :
#define USE_TEENSY3_OPTIMIZED_CODE

i still hear the clickings upon Serial1 sending. i'll try to isolate further by playing from memory instead of the sdcard, but i'd need the sdcard working eventually (they're going to times square public gaming next week) : http://www.timessquarenyc.org/times-square-arts/projects/at-the-crossroads/playtimessquared/index.aspx

PaulStoffregen
07-07-2016, 06:36 AM
Are you still in Portland? Might be easiest to just bring it over here. Maybe early next week?

mpinner
07-08-2016, 10:01 PM
@Paul, if you have the time, i'm totally game to meetup near/around portland.

We've been able to reproduce the issue with your tutorial example for playing sounds from memory by adding a Serial1.print:
https://github.com/adellelin/SymphonicPicnic/tree/master/TSPicnic_memorySounds

thanks again!

-matt

Frank B
07-08-2016, 10:10 PM
I tried this:


#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.... :-)

mpinner
07-08-2016, 10:24 PM
96MHz optimized.

Frank B
07-08-2016, 10:27 PM
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) ?

mpinner
07-09-2016, 02:08 AM
@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 B
07-09-2016, 08:23 AM
@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");

alien
07-09-2016, 08:12 PM
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


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.

mpinner
07-11-2016, 10:15 PM
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

defragster
07-11-2016, 10:33 PM
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.

Frank B
07-11-2016, 10:38 PM
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 ?

KurtE
07-11-2016, 10:59 PM
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:


while (!(UART0_S1 & UART_S1_TDRE)) ; // wait until Uart has room
UART0_D = command;

Again may have entered this wrong, but...

mpinner
07-11-2016, 11:32 PM
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:
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.

thanks, matt

mpinner
07-11-2016, 11:34 PM
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

mpinner
07-11-2016, 11:43 PM
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...

PaulStoffregen
07-11-2016, 11:55 PM
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.

KurtE
07-11-2016, 11:57 PM
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:
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;

mpinner
07-12-2016, 04:10 PM
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.

KurtE
07-12-2016, 04:27 PM
@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?
As I mentioned better answered by Hardware people. Me being a software guy, I have a tendency to try something and hope it works. Like maybe having a couple of reasonable large polcaps on both sides of voltage regulator like maybe 33uf (probably overkill), plus a few other decoupling capacitors, like .1uf. Again I might have one on both sides of Voltage regulator, plus maybe 1 right at the connections to XBee...

But again there are others up here who are much much much more hardware experts!