Streaming PCM Audio from SD Card?

[Dacobi]

Are you fìlling the PCM buffer before setting the audio rate? If you set the audio rate with no data in the buffer you'll hear a pop

The code I'm using with and without the "pop" is completely identical. Only difference being whether the buffer is a pointer to normal memory or BANK_RAM

Edit: Of course when using BANK_RAM I set RAM_BANK whenever I access the buffer, but again the exact same code gives a "pop" the first time a PCM stream is loaded, but not the following times.

[Dacobi]

I just tried disabling PCM audio in the start menu, so that the winner menu would be the first PCM playback and the winner menu plays without the "pop".

If the "pop" was present in the winner menu when that's the first PCM playback I would think the problem was some variable that wasn't initialised, but the "pop" only happens the first time the start menu is loaded and only when the buffer is BANK_RAM.

I also tried as a hack to call my reload_audio function within my load_audio function to simulate PCM being closed down, but still the "pop" is there.

Edit: I also tried writing a PCM init function to initialise all vars and registers I could think of and call it before I load the menu the first time, but it didn't help either.

Sanity failing...

Edit2: My code is now set up so the only difference is this:

Code: Select all

unsigned char sample_point[4096];
//#define sample_point BANK_RAM

changing from one line to the other is the only change for whether there's a "pop" or not.
And I've added "RAM_BANK = 1;" every place I can think of, but also I'm already using RAM_BANK 1 in my other menu code and it runs without any problems.

[Dacobi]

While working on another part of the game I had a problem with RAM_BANK not being set correctly even though I had just set it at a previous point in the code, so my only current theory is that something is happening when the program first starts where RAM_BANK is being set to 0.

The only thing is that I already set "RAM_BANK = 1;" all over the place, but I can't think of anything else that could cause the "pop".

[Daedalus]

What's left is interrupts. Riddle me this, Batman... does the KERNAL use RAM bank 0 in it's interrupts? I wasn't sure... I know it uses RAM bank 0 in it's startup, and in the handling of the SDcard, but I had to look in the kernal code for this.

Yes, the KERNAL uses RAM bank 0 in, at the very least, the ps/2 keyboard processing. Which it does during interrupts. (I looked there first because I know first hand that it would need RAM to work.) A segment used in the keyboard buffer, "KVARSB0" is in RAM bank 0 at $AF00.

What could be happening is that during startup, an interrupt is occurring during your buffer setup and switching the RAM bank. The test to see that is to disable interrupts around the buffer setup with sei (disable interrupts.) and cli (enable interrupts.)

[Daedalus]

As an aside, there's something I've been wondering about: How do you debug C programs on the x16? If you use the emulator's debugger, you need to know assembly AND what the C compiler turns your C code into.

I debug my asm programs all the time, and I've developed "methods" to make that easier for me, for example, I use the compiler's symbol table output to easily find the memory a function uses.

[Dacobi]

What could be happening is that during startup, an interrupt is occurring during your buffer setup and switching the RAM bank. The test to see that is to disable interrupts around the buffer setup with sei (disable interrupts.) and cli (enable interrupts.)

sei/cli didn't help. I've attached a screenshot of my code.

As an aside, there's something I've been wondering about: How do you debug C programs on the x16? If you use the emulator's debugger, you need to know assembly AND what the C compiler turns your C code into.

I don't I just assumed it wasn't possible, didn't know it was possible in asm?


Here's my code

seicli.png (60.54 KiB) Viewed 46017 times

[DragWx]

Try commenting out your writes to $9F3D and replace them with just STZ $9F3D, and see if you still get pops.

This should hypothetically make your program still go through all of the normal motions of playing PCM data, except it just writes silence instead. If that pop still occurs, then the problem isn't where you've been looking.

[Daedalus]

I can't see anything wrong with that as far as functionality is concerned.

The assembly debugger is in the emulator, as such... you can't use "actual hardware" to use it. So you do your development on the emulator then move it to the hardware for final testing. On hardware, you still have the monitor, at least.
The debugger is mercilessly low level, and has it's own fairly steep learning curve.

It looks like this:

debugging.png (31.7 KiB) Viewed 46003 times

The breakpoint I set is at the routine that inserts characters into the on screen command buffer. Looking a the memory data (Address $0C50 is the start of the edit modules's data area.) I can see that the cursor x/y is 04/01 and that the character that should be added if I step through the code is $54, which is ascii for the capital T I typed that called this routine, triggering the debugger. The buffer that character will go into as they're typed is currently completely blank.

I use this all the time, and simply couldn't develop on the x16 without it.

[Dacobi]

Yes, the KERNAL uses RAM bank 0 in, at the very least, the ps/2 keyboard processing. Which it does during interrupts. (I looked there first because I know first hand that it would need RAM to work.) A segment used in the keyboard buffer, "KVARSB0" is in RAM bank 0 at $AF00.

I think maybe the problem is that MACPTR itself used RAM_BANK 0?
I had a problem where I didn't set RAM_BANK 1 in the VBLANK interrupt when rendering the Winner screen and where my winner player text sprites were in RAM_BANK 1, which resulted in the player text flashing on and off as if BANK_RAM was switching between two different RAM_BANKs.
My theory was that streaming the PCM audio from SD card was causing this switching, but it still doesn't explain why it's only a problem when the program first starts.

[Dacobi]

Try commenting out your writes to $9F3D and replace them with just STZ $9F3D, and see if you still get pops.

I can't really do this since I use MACPTR to write directly to $9F3D from my file on the SD card.
So it wouldn't be a complete simulation of my code to replace it with STZ.