Setting audio out to external DAC (which is not connected) causes constant right-arrow-like behavior

[tomvanbraeckel]

The Fri3D Camp 2024 Badge has a "Communicator Addon" which has an external DAC and speaker (and much more), so I would like to compile in support for the external DAC, which may or may not be connected at times.

I added the configuration to targets/fri3d-2024/config.h but when I activate it in the settings, or it starts with this setting (while no DAC is connected on the 3 pins), retro-go starts rapidly cycling through all the emulators, as if I'm constantly pressing the right arrow. It's might really be that though, because when I go into the menu, it's not increasing the volume % as you would expect from a right press.

This also happens on the upstream "mainline" retro-go dev branch. I tried configuring all DAC pins to a known input PIN (RG_KEY_B GPIO_NUM_40) to see if that changes anything but it remains. If I switch it back to a different audio out configuration in the menu, it stops the DAC configuration and start the other one (dummy/buzzer) but keeps doing the rapid cycling until I reset the device. I'm unable to test with an actual DAC as they will arrive in ~7 days.

The serial doesn't show anything unusual, just:

[info] rg_audio_init: Audio ready. sink='Ext DAC', samplerate=32000, volume=60

I didn't dig deep yet but wanted to ask first; did you notice this behavior before? Any idea what might be causing this?

Somehow initializing the DAC when it's not connected causes a weird/bad state...

[tomvanbraeckel]

PS, here's my code: https://github.com/tomvanbraeckel/retro-go-fri3d/commit/433402790c2c6a18cf6475e8f693372788815d71

[ducalex]

I haven't seen this behaviour and a quick look at the documentation doesn't tell me anything obvious that could cause this. I'm not seeing any conflict in your pin mapping either (but my browser is very laggy right now so I didn't look up all the adc to gpios and might have missed something).

But my guess is that it will happen even with the DAC connected. Because all three signals are outputs so it really doesn't matter if something is attached or not, as far as the driver is concerned.

I think what I'd do first is make the input task print the raw value of adc1 chan0, then see how it changes when you enable Ext DAC? Might give some clues as to what's going on.

         int value = adc_get_raw(mapping->unit, mapping->channel);
+        RG_LOGI("%d %d: %d\n", mapping->unit, mapping->channel, value);
         if (value >= mapping->min && value <= mapping->max)

[tomvanbraeckel]

Thanks, I added that and it doesn't show any difference between Dummy, Buzzer and Ext DAC:

[info] rg_input_read_gamepad_raw: 0 0: 1803
[info] rg_input_read_gamepad_raw: 0 0: 1733
[info] rg_input_read_gamepad_raw: 0 2: 1882
[info] rg_input_read_gamepad_raw: 0 2: 1911

Hint: it somehow seems that buttons stay "pressed" and don't release, because if I press START and then some time later SELECT, it triggers my "START+SELECT reboot into MicroPython" code, which it normally doesn't trigger. I don't think my changes are to blame because the issue is also present on the dev branch (without the START+SELECT reboot of course).

I can dig in further later in the weekend :-)

[tomvanbraeckel]

I found the issue!

In the i2s_pin_config_t that's passed to i2s_set_pin in components/retro-go/drivers/audio/i2s.c, .mck_io_num is not initialized to GPIO_NUM_NC, so it defaults to 0. Which matches the GPIO that the Fri3D Camp 2024 Badge is using for the START button, resulting in "START" being pressed all the time, which causes it to loop through the emulators constantly :-)

[tomvanbraeckel]

Fixed in https://github.com/ducalex/retro-go/pull/147