GP32 The Gp32 Dma Sound Bug

[fdave]

Just to let you know I finally had a bit of progress last night with the GigaDrive sound glitches. It seemed to be down to two things:

1) The sound loop was 4*735 samples long, I increased it to 6*735 which gives 100ms latency. But this seemed to help
2) The sound rendering loop (ironically) was locking the DMA out, so I added in an asm("nop") to the tight inner loop and now it's fine.

(NB - I'm only talking about the sound loop bugs, I haven't added anything to the FM emulator, so it still sounds like a SMS


Does this sound about right?
It's a relief that the Cyclone core itself doesn't seem to be locking the DMA out.
Does anyone know how frequently the Sound DMA has to get access to the bus, i.e. how frequently I need a asm("nop") in?

 

[Robster]

Hi fdave,

I don't think that increasing the length on your sound buffer would make any difference unless the problem was that your DMA buffer was starving, it shouldn't really affect the memory bandwidth use?

But from your numbers, it sounds like your sample rate is 44100Hz - is that right? If so, it's quite excessive! fGen32 runs at about 16500Hz and everyone seems happy with the sound quality so higher rates are just going to chew up CPU and memory bus cycles.

Point 2) sounds fairly reasonable, but I've never had to do anything like that. Once again, your issue is probably made worse by the high sample rate.

Is your DMA buffer in non-write-buffered memory? That seems to make a big difference.

I can't say much more without seeing the code, are you going to post it on your site?

 

[fdave]

Hi fdave,

I don't think that increasing the length on your sound buffer would make any difference unless the problem was that your DMA buffer was starving, it shouldn't really affect the memory bandwidth use?

But from your numbers, it sounds like your sample rate is 44100Hz - is that right? If so, it's quite excessive! fGen32 runs at about 16500Hz and everyone seems happy with the sound quality so higher rates are just going to chew up CPU and memory bus cycles.

Point 2) sounds fairly reasonable, but I've never had to do anything like that. Once again, your issue is probably made worse by the high sample rate.

Is your DMA buffer in non-write-buffered memory? That seems to make a big difference.

I can't say much more without seeing the code, are you going to post it on your site?

Hiya,

I agree, the sound buffer is quite large at 100ms, there must be something going wrong still.
I'm interested about the 'non-write-buffered memory' thing since this would explain it. If I'm writing data to memory, but it isn't reaching the DMA unit in time, the sound would break up.

Can you tell me more? How do I make memory non-write-buffered (or flush the buffer)?

About 44100hz sound - hey, I like my high quality sound ;-)
Plus 16500Hz is going to show some real aliasing on a Megadrive

 

[mr.spiv]

Can you tell me more? How do I make memory non-write-buffered (or flush the buffer)?

Check www.deadcoderssociety.tk -> gp32 -> documents.. there's some old code & stuff about changing caching. Both Gamepark SDK way and direct BIOS call way.

 

[Robster]

Hi fdave,

16500 sounds ok. Just remember: Nyquist was a nazi, and he should be ignored whenever possible

Anyway, I've got some MMU setup code to make the sound buffer non-write-buffered, or you could look at spiv's site. Or, an easy thing that I quite often do, is put the sound DMA buffer in the LCD frame buffer area, because it's already set up right.

The LCD buffer area starts at 0x0C7B4000, so there are 4 8-bit buffers at 0x0C7B4000, 0x0C7C6C00, 0x0C79D800, and 0x0C7EC400. Then there's 4k of space left over at 0x0C7FF000. If you're not using 4 LCD buffers, you can use any of that space, or you can use the 4k of leftover space.

With 100ms of sound buffering at 44100s/s you need... errr... (counts on fingers)... 17k or so of buffer space, and if you're double-buffering the sound it'll be like 35k - does that sound right? Anyway, it'll fit nicely into one of the unused LCD buffer slots.

 

[fdave]

Hi fdave,

16500 sounds ok. Just remember: Nyquist was a nazi, and he should be ignored whenever possible

Heh

I've had various goes at this now, but no joy sadly - I still have to have a sound loop of 100ms. Have you ever got a smaller sound loop?

Tried putting in screen ram, no joy.

//test:
static int SetMmu(void *start,int len,int flags)
{
  int end=0;

  len+=0xfff; len&=~0xfff; // Round up to 4K
  end=(int)start+len-1;

  asm volatile
  (
    "  mov r0,%0\n"
    "  mov r1,%1\n"
    "  mov r2,%2\n"
    "  swi #2\n"
    :
    : "r" (start), "r" (end), "r" (flags)
    : "r0","r1","r2","lr"
  );

  return 0;
}

SetMmu(AudioWave,len,0xff2);
....
  AudioWave=(unsigned short *)0x0C79D800; //test

Anything obviously wrong there? Haven't tried the official SDK Mmu change, will try that next time...

It's not a huge problem, just a tiny bit of lag on my sound presumably, but a bit niggling if the GP32 can definitely have a smaller sound loop?