libogc v1.7.0 sound issues

[okachobi]

I rushed to upgrade my toolchain and libogc versions when I noticed the new version, but I may have done so too quickly. It appears that sound code that was working with the prior version (from SDL-Port) is no longer working with this latest version.

When I rebuilt SDL-Port, video worked fine, Audio appears to initialize fine, sounds loaded just fine, but nothing is coming out of the speakers. This is the first time I've rebuilt SDL-Port so I'm not sure if its something in the SDL build that is causing the issue.

Has there been changes to the AUDIO_* routines that need to be reflected in client code?

Does anyone know if sndlib still works with v1.7.0? I did a comparison of the code in sndlib and SDL-Port audio driver and didn't see anything that stood out as a problem. It appears that there has been work to integrate an accelerated DSP version of sndlib into ogc itself. Has this impacted the AUDIO_* interface in some way?

Or maybe this is some issue with the latest devKitPPC toolchain? Thanks...

[WinterMute]

The current SDL port mess that is being distributed is not supported.

[okachobi]

I recognize that its not supported (I saw the other thread on SDL-Port), but all the same I need to fix my code or revert back to the older libogc and it uses that port of SDL. I'm not really looking for SDL-specific support- the SDL audio code looks very similar to the libsnd code, it uses 'supported' AUDIO_* interfaces in the same was that libsnd does- so I'm really just trying to understand what needs to be changed to again make that unsupported code compatible. Is libsnd no longer support either?

I don't want libogc changed to support the older SDL port... I just want to fix the SDL Port I'm using so I can release against the latest devKitPPC and libogc. But at this point, I can't see anything that SDL-Port is doing that shouldn't be compatible.

I know that GPF is having the same issue with sound in the only SDL port that is available and is working on a C64 emulator that no longer works with the latest libogc. And with the holidays and being off from my normal job, I have time to put into fixes on Paradroid. If I can't get around the problem I'm having with libogc, then this time will be a bust for me...unless I downgrade to the older libogc.

If you have a new SDL port beta that you'd like to introduce for testing, then that would be nice too

[okachobi]

It would help a whole lot if you could comment on whether the AUDIO_* routines can still be used in the same way that various sound libraries HAD been using them prior to this release. It appears that the DMA callback is occurring in SDL-Port, but the data in the DMA buffers is being ignored. Its as if something else is overriding the DSP registers.

If AUDIO_* usage has change, just say so. Don't be so cryptic... its not a secret is it?

[WinterMute]

I was hoping Shagkur might have replied to this by now actually, I'm not 100% familiar with the changes that were made to the audio support in the latest libogc. It's not a secret, just not something I've spent much time with yet.

I'll get you an answer as soon as I can.

EDIT: In the meantime it would be useful if you could separate the audio functions from SDL and show us the code you're using in a small test case. We may be able to spot something that way.

[okachobi]

thanks. I'm currently tracing (line by line) through the SDL-Port code and it would appear that the code path that is getting executed is memcpy'ing silence into the dma buffer.

Either this isn't the source code for the binary being distributed, or some compile options are missing. Given that a segment of the SDL gamecube audio driver code in question looks like this...

Code: Select all

// Called whenever more audio data is required, and Registerred as DMA Callback
static void StartDMA(void)
{
	// Is the device ready?
	if (current_audio && (!current_audio->paused))
	{
		DMABuffer* const dma_buffer = &dma_buffers[current_dma_buffer];

		// Is conversion required?
		if (current_audio->convert.needed)
		{
			// Get the client to produce audio.
			current_audio->spec.callback(
				current_audio->spec.userdata,
				current_audio->convert.buf,
				current_audio->convert.len);

			// Convert the audio.
			SDL_ConvertAudio(&current_audio->convert);

			// Copy from SDL buffer to DMA buffer.
			memcpy(&(*dma_buffer)[0], current_audio->convert.buf, current_audio->convert.len_cvt);
		} else {
                        // ** This block is getting executed every time.... ***
			// Not implemented yet.
			memset(&(*dma_buffer)[0], 0, sizeof(DMABuffer));
		}

		AUDIO_StopDMA();
		AUDIO_InitDMA((Uint32) &(*dma_buffer)[0], sizeof(DMABuffer));
		DCFlushRange(&(*dma_buffer)[0], sizeof(DMABuffer));
		current_dma_buffer = 1 - current_dma_buffer;
	} else {
		// Set up the DMA.
		AUDIO_InitDMA((Uint32) silence, sizeof(silence));
		// Flush the data cache.
		DCFlushRange(silence, sizeof(silence));
	}

	// Start the DMA.
	AUDIO_StartDMA();
}

So the case where no conversion is necessary is unimplemented?! I think someone packaged up the wrong source code. I went through the code in SDL_mixer, and it explicitly does the necessary valls to SDL_Convert() when the samples are loaded- which is the right thing to do since it only results in the overhead of conversion 1 time.

The SDL gamecube driver is running in "irq" mode, so that the DMA callback drives the polling of the mixer callback for data. That "unimplemented" block probably just needs to go something like...

Code: Select all

			current_audio->spec.callback(
				current_audio->spec.userdata,
				&(*dma_buffer)[0], sizeof(DMABuffer) );

So I definitely think this is a case of some missing source code. Thanks for prodding me a little more to dig. I hadn't needed to rebuild the SDL-Port source until the libfat changes broke the way it was using it. Now I wonder what else is missing from the SDL-Port source that is being distributed.

EDIT: The code snippet above worked, but clicked. I had to add a double-buffer and reduce the samples per buffer to 2048 for less latency. So this problem obviously had nothing to do with libogc. The SDL_Port source code distributed from wiibrew.org on 12/24/08 does not contain all the mods used to make the binary. It also isn't compatible with libfat without a few edits.