[Bug]: Crashing when adjusting sound above 20% in standalone RetroPie emulators

[StonedEdge]

Describe the bug

1. Open a standalone emulator in RetroPie, such as DraStic or PPSSPP
2. Adjust volume above 20% in Alsamixer
3. Emulator begins to lag - eventually crashes and file system becomes read-only
4. Doesn't happen with the headphone drivers, only speaker drivers

Expected behavior

The speaker drivers should allow me to drive the volume of the speakers. I have them connected to 5V on my PCB as per the datasheet.

Platform

• Device: [e.g. Raspberry Pi CM4]
• OS: [e.g. RetroPie 32bit kernel version 5.10.63-v71+]

Relevant log output

No response

[HinTak]

why did you close this? Even you realize it is an unrelated issue, it would be nice to write it down before closing...

[StonedEdge]

why did you close this? Even you realize it is an unrelated issue, it would be nice to write it down before closing...

Hi HinTak.

I closed it as I probably realized that this issue more relates to RetroPie than the seeed development team... or maybe not, I don't know. Last time I asked I was told that they dont provide support to RetroPie users... However, just for some pre-context, the RetroArch audio drivers seem to be using alsathread (which I have no issue with running games), however as soon as I try any X11 based backend emulator, it seems to crash due when the speaker outputs go above 20%. No problem if you cant tackle the issue, I thought it might have been a simple fix, for example changing the audio driver used on the emulator side...

[StonedEdge]

I dont particularly think this will help, but here's an image of the crash error:

And here's what my .asoundrc file contents looks like currently. This is the stock .asoundrc file that is pre-loaded in RetroPie within the /home/pi/ directory, which seems to differ from the file packaged in the seeed GitHub. Should I make some changes to it? I dont think this is the problem as this just sets the default card settings and allows sound to be output.

It's more like the CPU cannot keep up with the video, almost as if the audio buffer is being choked - i.e the Pi is unable to process audio frames as quickly as they are being produced...

pcm.!default {
  type asym
  playback.pcm {
    type plug
    slave.pcm "output"
  }
  capture.pcm {
    type plug
    slave.pcm "input"
  }
}

pcm.output {
  type hw
  card 0
}

ctl.!default {
  type hw
  card 0
}

Here's a video of the issue I've described: https://youtu.be/smb-yKcNMOw

And here's another error when trying to restart after a crash:

[StonedEdge]

I guess no one has any idea then... :( Is there any way I can provide a log after the crash, for example?

[StonedEdge]

I am powering the speakers on 5V rail compared to 3v3 on my PCB. Do I need to change anything in the code to accommodate for the higher voltages?

[HinTak]

The fat message means your sd card got corrupted. I really suspect a power issue - your power supply is not strong enough?

[StonedEdge]

The fat message means your sd card got corrupted. I really suspect a power issue - your power supply is not strong enough?

Hmm, I guess it could be that. The boost regulator I'm using is the TPS61232, perhaps it cannot handle the 2A+ transient spikes from the speakers. I don't have the inductors/low pass filters on the speaker output rails, like the seeed PCB schematic shows. I'll send over my schematic shortly, but I suspect the issue is not power related, because there is no problem in libretro core based emulators.

For what it's worth, the PPSSPP emulator SDL and Qt builds of PPSSPP just use SDL audio rather than ALSAthread like the libretro core emulators. Not sure if this would be the source of the issue or not. Perhaps it's causing compatibility issues with the seeed audio drivers.

[StonedEdge]

Is anything writing to the SD card in the code? I find that when my SD card becomes a read-only file system after the inevitable crash, everything speeds up considerably but I can't figure out why that would be the case. I'm also driving two speakers instead of one, which is what is done on the seeed HAT PCB. Do you have any idea why this would happen?

[StonedEdge]

I will also add that driving the headphones works completely fine with zero lag, however as soon as I switch back to the speakers l, slowdowns happen.

[StonedEdge]

And finally, my schematic, FWIW

[HinTak]

speakers draw more power than headphone - so it sounds like a power issue?

[StonedEdge]

Don't think so. Checked the power supply ripple and transient noise near the speakers with my scope, as well as the regulator output when I raise the volume and it looks fine. Is there anything that I need to manipulate in the code to drive two speakers or should they just work "out of the box"? FWIW, muting the "Right Output Mixer PCM" in Alsamixer removes any issues I have if that helps.

[HinTak]

'muting the "Right Output Mixer PCM"' works around the issue, that's interesting. If I could find time would be useful to see what that does at the code level.

[StonedEdge]

'muting the "Right Output Mixer PCM"' works around the issue, that's interesting. If I could find time would be useful to see what that does at the code level.

That'd be great. I'll keep debugging my hardware, and I'm sorry to ask you for help again on this. Forgive me if it is my hardware...

[StonedEdge]

'muting the "Right Output Mixer PCM"' works around the issue, that's interesting. If I could find time would be useful to see what that does at the code level.

Here's a video of the issue by the way, just in case: https://youtu.be/XeDUuK9mMEA

[StonedEdge]

@HinTak I apologize. Turns out the issue is hardware related, with me pairing the high speed SDIO clock signal right next to the analog signals of the right channel, which is causing my problem. I apologize about this.

• Stoned

[HinTak]

Thanks for letting me know! Good it is resolved!