Streaming PCM Audio from SD Card?

[Dacobi]

I'm currently working on adding PCM Audio to the menus of my game, and I have something that's mostly working.

However it only works when I run the PRG from the PC filesystem. If I create and use an SD card img the program can't read the sample files from SD card fast enough.

Is this a problem with the emulator or does it reflect the actual speed of the SD card on the X16?

I'm using r43 btw.

Edit: Also I'm running under Linux. I was considering if it could be a bug in the emulator when dealing with virtual SD card image files?
Wouldn't the virtual machine consider the PCs filesystem as an SD card aswell, when running without "-sdcard" ?

[Daedalus]

The Emulator bypasses the X16's BIOS code and accesses the file directly when in HOST mode, it runs the X16 BIOS code when in SDcard mode.

I'm 99% sure the issue is not the actual SD card itself, rather I expect it's the way the BIOS is written. Bear in mind, it was written in 1980 to support floppy disks over a slow serial line.

The first thing to look at is what data rate are you trying to use? If you're trying to use a full 16 bit 46K stereo channel then I would expect you can't do that over a stream, you have to buffer the entire sample in RAM first.

[Dacobi]

The first thing to look at is what data rate are you trying to use? If you're trying to use a full 16 bit 46K stereo channel then I would expect you can't do that over a stream, you have to buffer the entire sample in RAM first.
Top

Currently I'm running 8bit mono at 12khz and while the actual PCM audio runs flawlessly my menu is lagging badly (with "-sdcard").

I'm using 5 ram_banks for sample data and with each VBLANK interrupt I read a 2KB file to an unused ram bank. So it should take 4 frames to fill one ram bank.

The weird thing is that it seems kinda random, how long it takes to load a sample file. My menu "render speed" varies quite alot when using SD image file, where it's completely smooth on host filesystem.

Edit: I just realised that I miscalculated. With 8bit mono at 12khz it's only 200 bytes for the FIFO pr frame, and thus for most frames my audio file stream function doesn't load any files. I guess that would explain why the lagging seems random?

Edit2: I just tried changing the file size down to 512 bytes, but this actually seems to have made it worse, when using "-sdcard". Without it, it runs perfectly smooth.

[Daedalus]

There you go. Sometimes you just need to look at something differently.

With that low a data rate, (12,000 bytes per second.) you only need to buffer 200 bytes per frame. The BIOS has to work hard to load that file, but the VERA's interface to the SDcard's SPI interface is a rocket.

So you're CPU bound because of the constant loads, it's fast on HOST because the emulator lifts that weight.

One approach you could try is to keep the file open and pull in only the 200 bytes per frame you actually need from it then the AFLOW interrupt hits (Use the interrupt as a trigger and do the load after the int routine ends.)

[Dacobi]

One approach you could try is to keep the file open and pull in only the 200 bytes per frame you actually need from it then the AFLOW interrupt hits (Use the interrupt as a trigger and do the load after the int routine ends.)

I don't understand how this would change anything? Whats the difference between loading a file to an address and opening it to the address? If the open or load call takes longer than one frame it would still lag?

Edit: What I should have written was that I have no clue how file open/read/write works on the x16 : ) I've only ever used cbm_k_load.

[Daedalus]

Assuming I understand how the fat32 implementation works... (And I may not, I'm only started trying to use it directly recently.)

Because the BIOS doesn't have to do everything at once, BIOS calls the fat32 implementation on a different ROM bank, if you open the file and leave it open, it remembers the "current position", the data then comes from a buffer in RAM bank 0 above $B000... when you leave it open and just pull in the bytes you need, BIOS only has to pull from that buffer (Still by proxy through the fat32 layer, though.) Fat32 (As implemented) can hold 4 files open at once.

This eliminates all the overhead of fat32 having to allocate a context, find the file, open the file, load the next sector into the buffer on a frame by frame basis. You can't tell fat32 to do this directly, it's done by proxy from the KERNAL's BIOS.

The key is in your last sentence... "If the open or load call takes longer than one frame it would still lag?" By leaving the file open, you don't have to load OR open it on a frame by frame basis, just grab the data you need.

[Dacobi]

I think I understand the concept. Just so I understand, I'm using C so I'd open the file and then use cbm_k_chkin and then cbm_k_getin or cbm_k_basin to read the bytes?

How large a file can I open on the fat32 partition?

[Daedalus]

You want CHKOUT and ACPTR after opening the file. The paradigm is from the point of view of the connected hardware device, so "out" mean into the computer.

As far as I can tell, cc65 just mirrors all the KERNAL calls, so they should be cbm_k_chkout and cbm_k_acptr

Edited to add: As to size, basically any size, I expect. If it will go onto a fat32 partition, you should be able to open and read it.

[Dacobi]

Edited to add: As to size, basically any size, I expect. If it will go onto a fat32 partition, you should be able to open and read it.

What will happen when the last byte of the file has been read? Will the "index" wrap around by itself?

[Daedalus]

Reading the last byte in the file should put it in the accumulator (return it as an unsigned char in C) then set the EOF flag. The EOF flag is bit 6 in the return from READST. You could also keep track of the number of bytes read and stop when it's 0.

If you read past it, I expect it throws an error, probably setting the carry bit and stopping you from reading any more data... attempting to read should leave whatever was in the accumulator in the accumulator, but I don't know what the cc65 wrappers will do there.

Also... I'm pretty sure seeking to a point in the file isn't live yet (But may be in a new build if you build rom.bin yourself.) So when you get to the end of the file, you should just close it.