FreqMeasure oddities with Adafruit_VS1053.h playing music

Status
Not open for further replies.

peaceman

New member
Hey,

I am working on a (for me) rather complex Arduino Uno R3 (328) project with the intent to sync up mp3/aac playback to a running Super 8 projector. Since most of these projectors are really old and don't keep their frequency very well, lip sync is impossible to achieve. I started with the VS1053 part and got Adafruits BoB running fine. I managed to load VLSI patches and can adjust the sampling rate registers on the fly without cracks or pops or other perceivable artifacts. So far, so good!
To measure the projector's running speed, I have wired up a fast photo diode via a TIA Opamp and get a nice, clean square signal from there (these projectors have a 3-segment rotary blade, so at 18 fps I get 54 Hz square signal on Pin 8.

I copied the guts from the Example Sketch to my sketch and get perfectly plausible (and valid) results -- you can see the projector warming up :)
Here are measured values (averaging taken out to make the effect more visible):

Code:
54.89604
54.98112
54.95751
54.83583
54.92280
54.94166
54.86423
54.92337
54.96129
54.83771
54.93524
54.96676
54.87175
54.97602
54.99075
54.84655
54.93072
54.99794
54.90188
55.01212
55.02555
54.91488
55.03710
55.08011
55.01363
55.07954
55.08542
54.97507
55.07461
55.13781

So far so good -- but now I have a problem: As soon as I start playback on the Adafruit VS1053 BoB via musicPlayer.startPlayingFile("test.m4a"); I get very weird results from FreqMeasure:

Code:
55.01193
55.08068
54.98168
55.02574
55.01590
54.94071
72.06201
5270.09228
44.95898
70.75420
55.06020
55.03615
70.96886
inf
55.03218
55.01439
54.89491
71.94860
233.05609
55.06267
70.84317
71.06090
55.07252
54.95619
55.11901
71.23236
71.09658
55.14085
55.19182
71.00256
55.19716

The measured freqs are higher, vary much more and there are occasional weird values in.
Since it is 100% reproducible by starting VS1053 playback, I guess there is some conflict with interrupts. The question is – is there a way to make this work at all simultaneously?

Regarding the VS1053 playback part, my code is basically derived from the examples, with two changes:
a) I replaced SD.h with SdFat.h
b) I changed BREAKOUT_DCS (The VS1053 Data/command select pin (output) form Pin 8 to Pin 2, since FreqMeasure needs Pin 8. Playback was not affected by this.

So this is the resulting setup:
Code:
#include <SPI.h>
#include <Adafruit_VS1053.h>
#include <FreqMeasure.h>
#include <SdFat.h>
SdFat SD;

#define BREAKOUT_RESET  9      // VS1053 reset pin (output)
#define BREAKOUT_CS     10     // VS1053 chip select pin (output)
#define BREAKOUT_DCS    2      // VS1053 Data/command select pin (output)
#define CARDCS 4     // Card chip select pin
// DREQ should be an Int pin, see http://arduino.cc/en/Reference/attachInterrupt
#define DREQ 3       // VS1053 Data request, ideally an Interrupt pin

const byte eyePin = 8; // amplified Photo Diode on Digital Pin

My suspicion is that DREQ can be blocking rather long, causing the wrong measurements -- but it is a wild guess since I am not savvy yet with Interrupts and Timers on AVR. Is there any hope that another pin config might help here? Or any hint how I can find out what causes these weird measurements?
 
Last edited:
My suspicion is that DREQ can be blocking rather long, causing the wrong measurements

That'd be my guess too.

It's too bad Uno doesn't have priority nested interrupts like ARM. FreqMeasure defaults its interrupt to a fairly high priority level, so it automatically works even when other lower priority interrupts take a long time.

On Uno, perhaps with a *lot* of work you could redesign Adafruit's library to allow other interrupts while it spends so much time using the VS1053.
 
Thanks, Paul.
Moving to (or: learning) ARM is unfortunately out of scope for this project (I only got a few days off) but on my agenda for 2017 :)

I consider now to use two UNOs, one for pitched mp3 playback and one for freq measurement -- connected via I2C. Do you foresee interrupt problems with FreqMeasure and I2C too? Or might this be a viable path? :)
 
On Uno, the Wire library also uses interrupts. Probably less time, so perhaps it will work better for low frequencies, but still a possible problem.

ARM isn't hard to learn. Just use Arduino like you do now. But a lot of things that fail on Uno work great on Teensy 3.2.

If using Teensy 3.2, you can also use the audio lib and Frank's MP3 lib to do all the MP3 decoding without any VS1053. ;)
 
Okay, that sounds tempting indeed. Will look around for a Teensy distributor in Germany (and keep trying to proceed on the UNO until it's shipped...)

Thanks, Paul.
 
Status
Not open for further replies.
Back
Top