Audio underflow when OLED active

Proffieboards
1

I’ve been trying to troubleshoot why the speaker has been “popping” every few seconds and have narrowed it down to the OLED. It seems like every time a new animation is played the audio will pop. Disabling SSD1306 fixes everything.

Currently running 7.7 but I have tried 6.9 and 7.6 also.

GND => GND on board
VCC => SD Power (3.3v pad did not work)
SCL => SCL
SDA => SDA

Serial Monitor

Playing OB4_High/swingh/swingh2.wav
channels: 1 rate: 44100 bits: 16
Playing common/on.bmp
Audio underflows: 16
Playing cEVENT: Clash ON millis=96710
unit = 1 vol = 0.50, Playing OB4_High/clsh/clsh8.wav
channels: 1 rate: 44100 bits: 16
Playing common/clsh.bmp
unit = 3 vol = 0.00, Playing OB4_High/swingl/swingl1.wav
channels: 1 rate: 44100 bits: 16
unit = 2 vol = 0.00, Playing OB4_High/swingh/swingh1.wav
channels: 1 rate: 44100 bits: 16
Audio underflows: 27
Playing common/on.bmp
Audio underflows: 22
Battery voltage: 3.49
Playing OB4_High/swingl/swingl1.wav
channels: 1 rate: 44100 bits: 16
Playing OB4_High/swingh/swingh1.wav
channels: 1 rate: 44100 bits: 16
Playing common/on.bmp
Audio underflows: 15
EVENT: ?48 ON millis=107655
EVENT MENU TURN LEFT
Playing OB4_High/hum.wav
channels: 1 rate: 44100 bits: 16
Playing common/on.bmp
Audio underflows: 18

sdtest

Time to read blocks: Average speed: 1058.16 kb/s, 12.00 simultaneous audio streams.

Common folder has bare minimums. Also tried different .bmp images. All fonts effected. Does it have something to do with using SD Power for VCC?

2

Are your images in the font folder itself or in a common folder?
Does it make a difference one way or another?
Do you have the font organized into subfolders for sounds with multiple files, and the images in them as well?
ie:
font/blst/blst01.wav
font/blst/blst02.wav
font/blst/blst03.wav
font/blst/blst.bmp

3

images in common

fonts in folders with subfolders

even tried removing everything except what was necessary

also tried with just 1 simple blade style incase it was a cpu issue, have 4 blade styles usually. (is there a way to monitor cpu usage?)

4

Typically Audio Underflows are SD read speed problems.
It sounds like the OLED and audio are having a competition for priority.
The question is why?
I may have experienced it, although I may have assumed small underflow numbers without audible pops was “normal”, which I guess really isn’t.

5

This isn’t the fastest card available, but it should be fast enough.
It looks like you’re also seeing some audio underflows when opening wav files too in some cases.

It could have something to do with the actual BMP files. Normally BMP reading is supposed to have lower priority than wav file reading to prevent this sort of thing, but if there is something odd going on with the BMP files, it could end up doing more reading than is strictly required. Can you post your “on.bmp” so I can check it?

It may also have something to do with the SD card structure. Have you tried copying all the files on the SD card, formatting the SD card and putting all the files back? It sounds like hokus-pokus, but sometimes the SD card directory structure gets overly complicated because of files that used to be on the sd card, but are not there anymore.

Of course, it wouldn’t hurt to try a different SD card, even if this one really ought to be fast enough.

Yes there is: top

I’m going to go take a look at the code itself and see if I have any ideas.

6

Well, I see two things I can do:

  1. after opening a file (but before reading from it) I can check if we need to read some wav files before continuing.
  2. I can make it so that if we’re opening the same file again, we can just leave the file open and seek to the beginning instead of re-opening the file.

The first one might actually fix the problem, the second one would just make it less common.

I don’t think I have time to try this out today, but maybe this weekend.

7

Oh, and one more question:
When you run sdtest it also tells you how long it takes to open files.
What does that say?

8

on.bmp (20.1 KB)
attached the bmp

Time to open files: Average time: 2339.19 us

9

I think is a fairly normal time, so that’s likely not the problem.

10

I tried a few more SD cards but results were all the same and speed was +/- a few %. Going to dig through drawers to see if I can find more to test

11

Ok, so I checked in a potential fix for this on github master.
Please try it out and let me know if it helps.

12

Didn’t seem to help but only tested it quickly last night. Still had underflows. When I get a chance later though I’m going to try maybe a static on image to rule out if the animations just too long

13

That’s odd. I expected it to at least help a little.

Can you check that you have my fix?
(Line 810 in display/ssd1306.h should say return true;)

14

Yep I had the right one. I think its the on.bmp might just be too big. I tried a shorter image (10kb in size) and its working fine. First paste below is the fix + large on.bmp, Second is fix + small on.bmp

Battery voltage: 4.00
EVENT: Power-Pressed#1 millis=87913
EVENT: Power-Pressed millis=87913
EVENT: Power-Released#1 millis=88099
EVENT: Power-Released millis=88099
EVENT: Power-Shortclick#1 millis=88099
EVENT: Power-Shortclick millis=88099
Ignition.
unit = 0 vol = 0.00, Playing Vader/hum/hum01.wav
channels: 1 rate: 44100 bits: 16
unit = 1 vol = 0.50, Playing Vader/out/out07.wav
channels: 1 rate: 44100 bits: 16
humstart: 1800
unit = 2 vol = 0.00, Playing Vader/swingl/swingl08.wav
channels: 1 rate: 44100 bits: 16
unit = 3 vol = 0.00, Playing Vader/swingh/swingh08.wav
channels: 1 rate: 44100 bits: 16
Playing common/on.bmp
Audio underflows: 20
Playing common/on.bmp
Audio underflows: 12
Battery voltage: 3.84
Playing common/on.bmp
Audio underflows: 12
Playing Vader/swingl/swingl08.wav
channels: 1 rate: 44100 bits: 16
Playing Vader/swingh/swingh08.wav
channels: 1 rate: 44100 bits: 16
Playing common/on.bmp
Audio underflows: 11
Playing Vader/hum/hum01.wav
channels: 1 rate: 44100 bits: 16
Playing common/on.bmp
Audio underflows: 15
Playing common/on.bmp
Audio underflows: 12
Battery voltage: 3.83
EVENT: Power-Pressed#1 ON millis=121027
EVENT: Power-Pressed ON millis=121027
EVENT: Power-Released#1 ON millis=121179
EVENT: Power-Released ON millis=121179
EVENT: Power-Shortclick#1 ON millis=121179
unit = 1 vol = 0.50, Playing Vader/in/in01.wav
channels: 1 rate: 44100 bits: 16
Playing common/idle.bmp
No sounds found: pstoff
Unmounting SD Card.
Amplifier off.
Booster off.

EVENT: Power-Pressed#1 millis=87351
EVENT: Power-Pressed millis=87351
EVENT: Power-Released#1 millis=87529
EVENT: Power-Released millis=87529
EVENT: Power-Shortclick#1 millis=87529
EVENT: Power-Shortclick millis=87529
Ignition.
unit = 0 vol = 0.00, Playing Vader/hum/hum01.wav
channels: 1 rate: 44100 bits: 16
unit = 1 vol = 0.50, Playing Vader/out/out07.wav
channels: 1 rate: 44100 bits: 16
humstart: 1800
unit = 2 vol = 0.00, Playing Vader/swingl/swingl03.wav
channels: 1 rate: 44100 bits: 16
unit = 3 vol = 0.00, Playing Vader/swingh/swingh03.wav
channels: 1 rate: 44100 bits: 16
Playing common/on.bmp
DISPLAY WAKEUP
Display initialized.
Playing Vader/swingl/swingl03.wav
channels: 1 rate: 44100 bits: 16
Playing Vader/swingh/swingh03.wav
channels: 1 rate: 44100 bits: 16
Playing common/on.bmp
Playing common/on.bmp
Battery voltage: 3.86
Playing common/on.bmp
Playing Vader/swingl/swingl03.wav
channels: 1 rate: 44100 bits: 16
Playing Vader/swingh/swingh03.wav
channels: 1 rate: 44100 bits: 16
Playing Vader/hum/hum01.wav
channels: 1 rate: 44100 bits: 16
Playing common/on.bmp
Playing common/on.bmp
EVENT: Power-Pressed#1 ON millis=117461
EVENT: Power-Pressed ON millis=117461
EVENT: Power-Released#1 ON millis=117601
EVENT: Power-Released ON millis=117601
EVENT: Power-Shortclick#1 ON millis=117601
unit = 1 vol = 0.50, Playing Vader/in/in01.wav
channels: 1 rate: 44100 bits: 16
Playing common/idle.bmp
No sounds found: pstoff
Unmounting SD Card.
Amplifier off.
Booster off.
15

Interesting, the size really shouldn’t matter much.
Although BMP files are stored upside down, so we have to seek to the end I think… maybe that’s why? Formatting the SD card with a larger cluster size might help if that is the case… The other potential fix would be to use PBM files instead of BMP. (PBM files aren’t stored upside-down.)

I think I’m going to add some code that times how long it takes to open and read the file…
That will tell me what I need to optimize.

16

Ok, I added a piece of code that times how long ReadImage takes.
Get the latest github master, and add #define VERBOSE_READIMAGE_TIMING to your config file, and then try again, ideally both with the big and the small on.bmp.

17

So strange thing, everything’s working now. Here are the results though. First one was the good one and second was the bad. But everything seems to be working fine all of a sudden

Playing common/on.bmp
ReadImage took 1955 us
ReadImage took 1709 us
ReadImage took 1770 us



Playing common/on.bmp
ReadImage took 1603 us
ReadImage took 1591 us
ReadImage took 1594 us
ReadImage took 2181 us
ReadImage took 1710 us
ReadImage took 1502 us
ReadImage took 2213 us
ReadImage took 1534 us
ReadImage took 1601 us
ReadImage took 1512 us
18

That’s more than a little weird. Gremlins?
The times shown are pretty reasonable, which I guess makes sense if it’s working.
ReadImage times over 3000 would be concerning, and could potentially cause audio underflows.

19

only thing I can think of is I did empty the .Trashes osx leaves

20

Some have found that removing hidden files that MacOS puts on the SD card has helped speeds.
You could do find . -type f -name '.*' -delete before ejecting to clear them out.