MiCom Bug Thread

Managed to finally get round to playing with this properly and now have a working prototype!
OS loaded on the Teensy board with zero errors and sounds etc are working as expected!! :slight_smile:

1 Like

Hoping someone may have some thoughts or solution on this.
My friend has been testing a unit and every now and then he says the audio kinda skips like a cd with a scratch in it.

He managed to get it on video which I’ve linked to below.

The audio is mono, 16bit, 41000.

**update - I recalled some audio config changes earlier in this thread that I just revisited.
I’m guessing this slipping (or clipping?) is related to it?

Is this a proffieboard or a Teensy-based unit?
Either way, this is pretty weird, because it’s not a type of glitch that I recognize.
My guess is that this is a bad SD card block, and replacing the SD card might fix it, but it could be something completely different…

It’s a teensey unit.

Ah interesting I didn’t think about the SD card.
I’ll look into that. Thankyou.

Is there any restrictions on what SD card should be used?
Or a recommended speed etc?

Unfortunately, what matters is the minimum speed, while SD card manufacturers only lists maximum speed.

Almost any new SD card should work, but there is always a chance you get a bad one. Personally I usually buy ā€œsandisk industrialā€ cards, but that’s based more on faith than science or specifications. The idea is that ā€œindustrialā€ cards might be optimized for long life, and that may also translate into reasonable minimum speeds. (Because usually, the thing that hurts speed is when some checksum doesn’t come out right and the card has to do complicated computations to correct it.)

Just following this up, I have some SanDisk cards arriving soon.
But I managed to catch the skipping in the serial monitor:
Do you know what the audio underflows is refering to?

unit = 1 vol = 0.50, Playing bank1/t7clk1.wav
channels: 1 rate: 44100 bits: 16

Audio underflows: 116
Audio underflows: 202
Audio underflows: 200
Audio underflows: 43

Playing bank1/t5hldl.wav

~1000 per second, the sound playing interrupt wakes up and reads 44 samples from each active wav player. If any of the active wav players fail to produce 44 samples, the underflow counter is increased.

Each sound player has a 512-sample buffer, and any time there is any space in that buffer, a software interrupt is scheduled to fill it up. This buffer only lasts 11.6ms.

With a slow SD card, or very large directory structures, reading data from the SD card can take more than 11.5ms, in which case underflows will definitely occur, and if more sounds are playing at the same time, the tolerances get smaller.

Now, when you see hundreds of underflows, then the SD card is either completely stuck, or it’s consistently too slow to be able to play sounds.
I recommend trying a different SD card.

Perfect, thankyou!
It’s kinda what I was thinking.
Appreciate the help!

So my SanDisk SD cards arrived just now so I did some testing via the serial monitor.

Old Card:
Time to open files: Average time: 12329.25 us
Time to read blocks: Average speed: 1626.42 kb/s, 18.44 simultaneous audio streams.

New Card:
Time to open files: Average time: 3249.41 us
Time to read blocks: Average speed: 1286.68 kb/s, 14.59 simultaneous audio streams.

That’s kind of weird.

This is terrible, and will definitely cause audio glitches.

This is fine, and in fact better than the other card.

It could be that the problem is in the file structure of the card. Formatting it and putting the files back might fix it. Either that or there is a bad block somewhere in a directory listing slowing things down.

Ok. Thanks.
Think I’ll
Just ditch the old ones. Haha

Hey, all! New MiCom developer here!

Running the following on MacOS 14.6.1 (Sonoma):

  • ProffieOS 7.14
  • Proffieboard manager 3.6
  • Teensy board manager 1.59.0

Here is my config file, similar to the other posted in this thread:

3bank_test_config.h (973 Bytes)

And I’m getting a handful of null pointer errors
errors.h (5.2 KB)

Thoughts?

Thanks in advance for any help!

All of these are warnings that can be ignored.
(I should fix these at some point. Last I checked the fix was rather ugly though.)

1 Like

Thanks!

I uploaded the code to a Teensy 4.0 with audio shield, but still not getting any output.

Confirmed the memory card directory structure and sound files work properly as I’m just switching the memory card from an older MiCom that works fine, but the newer one isn’t playing the boot-up sound or anything…

Any thoughts or additional information I could provide to help diagnose?

Well the obvious thing to test would be to the new code to the old hardware and see if it works or not. If it works, then the problem must be in the hardware somewhere, but if it doesn’t it must be in the code.

Unfortunately I’m not aware of a way to back up the programming on a teensy, so if the old one stops working, it would not work until the bugs are fixed I would think.

Yeah, I had the same thought but don’t want to risk bricking my working unit.

I’ll keep digging…

I tested ProffieOS 7.14 with teensyduino 1.59.0 on my micom prototype, and it seems to work just fine. The font I have doesn’t have a boot sound, so it doesn’t do anything when you boot it, but pressing buttons work and so does the ā€œbeepā€ command in the serial monitor.

Thanks! Which config file were you using?

This one: