Streaming PCM Audio from SD Card?

[Dacobi]

I just tried doing something different. I now load the first 4KB of the PCM file into the buffer using MACPTR and then load that data into the FIFO and fill the buffer again.

This resulted in that there's now 2 "pops" when the game is first launched. Not sure what to make of it.
Now there's the tiniest hint of a "pop" when the buffer is normal memory, but only once and nothing like the "pops" from BANK_RAM.

[Dacobi]

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

Now that I fill the FIFO from my buffer I tried to change the code to use "STZ", both in the load_audio function and in my AFLOW interrupt handler and it does remove the "pops", so the problem is in the data.

[Dacobi]

I now have some code that loads the PCM audio with the buffer being BANK_RAM without "pops".
Only problem is that it takes longer to load. My update_audio function still uses MACPTR.

Edit: Odd thing is, it also works without setting RAM_BANK for every byte in the while loop.

This is the new code:

Screenshot from 2023-08-26 12-06-34.png (53.22 KiB) Viewed 34300 times

[DragWx]

I've been giving it some thought, you should be ok using MACPTR to fill the FIFO as long as you reset the FIFO before you do it, because I don't think MACPTR can check if the FIFO's full, which would result in dropped bytes, which may sound like a click in the audio.

MACPTR is also the only thing I can think of which can change the RAM bank on you. Everything else (Kernal routines, ISRs, etc) should be restoring the RAM bank after changing it, so I think you're safe not resetting the RAM bank before each byte in your loop.

So, I'm retracing your steps from earlier in the thread. On page 2 (the only full snapshot of your code here), your issue was that AFLOW was over-consuming your audio buffer. It wasn't considering how many valid bytes were in the buffer, and it was just filling the FIFO completely, and the buffer's read position was breezing past the write position (i.e., underflowing). That's what was causing the stuttering/skipping sound.

Next, when you switched to using MACPTR to fill the FIFO (which I think is a good idea), the problem with MACPTR is that it's unable to check whether the FIFO is full or not, so it'll always write however many bytes you tell it, and if the FIFO gets full, the remainder of the bytes will get dropped. This would've caused scratchy noises and a sound like the audio was constantly skipping ahead.

This doesn't mean you can't use MACPTR, you just have to set things up such that you can guarantee that MACPTR can write a predefined number of bytes without overflowing the FIFO.

When you initially load your audio, make sure to reset the FIFO first, then you can tell MACPTR to write the full amount of bytes, and you know it won't overflow. Then, if you want to use MACPTR to stream more data to the FIFO, try doing it within the AFLOW interrupt. AFLOW is convenient because it tells you the FIFO has dropped below X amount of bytes (and X is a constant), so you have a guarantee that you can write (MAX - X) amount of bytes without the FIFO overflowing. This won't fill the FIFO all the way to the maximum, but it'll fill it enough to be fine.

I think it's also ideal to use AFLOW to refill your audio buffer right after you've consumed the bytes from it, instead of trusting VBLANK to get you caught up.

Finally, I was making the assumption that the "pop" you were talking about was right at the start of the PCM data, but I wonder if it's actually a pop that happens slightly after the start of the PCM data? I'm thinking the pop isn't a problem with the data, but a symptom of the code having trouble synchronizing everything.

[Ed Minchau]

For my video demos, I would use MACPTR to load audio into VRAM (but not the PCM_AUDIO buffer). I used a separate subroutine to copy from VRAM to PCM_AUDIO. I had nothing but problems using MACPTR directly to PCM_AUDIO.

[Dacobi]

I don't see how the "pop" could be caused by over/under flow/consumption.
The code on page 2 is not what I've been using recently and it's been a while since I've had any problems with PCM audio skipping.
Recently the absolutly only change in my code between perfect audio and perfect audio with a single "pop", only when the program first starts was whether "sample_point" was a buffer in normal RAM or in BANK_RAM.

My current "load_audio" function, screenshot below, works with MACPTR and BANK_RAM without "pops", but only if I load the last 16 bytes of the buffer in a while loop with 16x ACPTR. If I load the last 16 bytes with MACPTR the "pop" is back.

Here's my load_audio function:

pcmpop.png (120.44 KiB) Viewed 34229 times

[DragWx]

Here's something that might be an issue: MACPTR uses the carry flag as a parameter when you call it, and two of those calls to MACPTR are with the carry flag in an unknown state. Try adding a "CLC" for those two calls that don't already do an "SEC", and see if that fixes the pop when you try the MACPTR method.

[Dacobi]

Here's something that might be an issue: MACPTR uses the carry flag as a parameter when you call it, and two of those calls to MACPTR are with the carry flag in an unknown state. Try adding a "CLC" for those two calls that don't already do an "SEC", and see if that fixes the pop when you try the MACPTR method.

And we have a winner!

I've added "clc" before my calls to MACPTR, for filling the buffer, and now everything works, loading only with MACPTR.

[Daedalus]

That's right! The carry flag is used to allow writes into VRAM. (VERA uses a "single address" to write to, as opposed to regular RAM where you change the address for each write.)

Good call, DragWx.

[Dacobi]

With my lack of knowledge of 6502 assembly I didn't even consider it or maybe I thought that the flag would be '0' unless it was specifically set to '1'.

I still don't understand what causes the flag to be set only sometimes?