Sound over HDMI crashes

[probonopd]

On RPi 3, MiniDexed crashes if it is configured to output sound over HDMI rather than i2s, in the main branch as of 0583421

# Sound device
#SoundDevice=i2s
#SoundDevice=pwm
SoundDevice=hdmi
SampleRate=22000
#ChunkSize=256
DACI2CAddress=0x0
#DACI2CAddress=0x98
ChannelsSwapped=0
MasterVolume=32

[Banana71]

I don't think it's exclusively an HDMI issue. My Raspberry Pi 4 with an I2S DAC also crashes at a sample rate of 22050, even with older miniDexed versions (e.g., "bfca612" from January 12, 2025).

[Banana71]

Does the HDMI audio output work with a sample rate of 48000Hz?

[probonopd]

With SampleRate=44800 it also crashes in soundbasedevice.cpp.

[probonopd]

With SampleRate entirely commented out, it doesn't show the crash message on HDMI but freezes after CPU core 2 started. (To be retested, not 100% sure on this one; I do not see this on RPi 2 Zero but there I have no HDMI cable attached...)

[soyersoyer]

Do you mean SampleRate=44100?

[Banana71]

A question for clarification: I understand that it should work with other frequencies, but why a sample rate other than 48000?

The sound quality is significantly better at 48 kHz than at 22.05 kHz. Even in the wiki we recommend leaving the sample rate at 48000.

---

Smartass mode on: 😄 common sampling rates in Hz for digital audio equipment:

• 22050
• 24000
• 44100
• 48000
• 88200
• 96000
• 192000

Smartass mode off:

[probonopd]

My bad, I have not used one of the "common" sampling rates; will need to retest with those.

Ideally, we make this hardcoded and not configurable. One variable less to worry about. Or at least accept only the ones posted above.

[soyersoyer]

Reverting Commit f546448 ("Update circle to Step49") the HDMI works.

[probonopd]

@Banana71 48000 also crashes.

[probonopd]

Reverting Commit https://github.com/probonopd/MiniDexed/commit/f546448371c4d630fff2d66ac2083711dc0e63bc ("Update circle to Step49") the HDMI works.

Wow, how did you find the culprit so quickly?

Does this look like it needs to be fixed in Circle?

[soyersoyer]

I thought this was the 3rd most likely. Yes, I think the problem is in Circle.

[soyersoyer]

This is the first bad commit within Circle: https://github.com/rsta2/circle/commit/f986fa501c33ed45d98bf7ff9af0e7762843de58

Could it be that the change involved was not implemented in CHDMISoundBaseDevice?

[probonopd]

@rsta2 trying to use HDMI audio hangs MiniDexed (apparently since Step49), is there a good/easy way to verifiy whether HDMI audio still works in Circle? Or maybe you already have a clue as to what this might be causing this?

[probonopd]

@soyersoyer

Could it be that the change involved was not implemented in CHDMISoundBaseDevice?

I do not understand the meaning of this. Can you elaborate? Which change would have to be implemented in CHDMISoundBaseDevice?

The only mention of CHDMISoundBaseDevice in MiniDexed is

		m_pSoundDevice = new CHDMISoundBaseDevice (pInterrupt, pConfig->GetSampleRate (),
							   pConfig->GetChunkSize ());

[soyersoyer]

After the mentioned commit, the CDMAChannel's SetCompletionRoutine() "Must be called before starting every new asynchronous transfer." CHDMISoundBaseDevice uses the CDMAChannel, and the SetCompletionRoutine() has only been called once. I think the CHDMISoundBaseDevice::DMACompletionRoutine() should call the SetCompletionRoutine() somewhere, but I've never tried.