When I was working on the sound for my version of Gens4All, I looked at the code for KOS's MP3 and Vorbis streamers to see how to push my own samples from the CPU. I was able to figure out that, but the way the decompressor was structured looked like it would have problems doing the decoding. It seemed like the MP3/Vorbis streamer would wait until a large chunk of the AICA buffer had been emptied, then decode a big block of the audio and send it to the AICA. This would cause a large spike in CPU usage whenever it decided to preform the decode. If you wanted a game to run without dropping frames or slowing down while streaming compressed audio, you would have to allocate enough CPU time every frame to absorb the worst case spike. CPU time on frame without spikes would just be wasted.
To check if my understanding of the code was right, I measured how much CPU time was available to the main thread by continuously incrementing a global variable in an idle loop. On vblank, the variable would be reset. By looking at how high the variable reached, it's possible to measure idle time for that frame.
Reducing the sample rate of the audio does reduce the average CPU usage, but not the worst case CPU usage. The spikes are a bit less frequent, but still about as long.
I compared lowmem Tremor, used by KOS, and the stb_vorbis library. Tremor uses fixed point math only, while stb_vorbis uses floating point. When decoding a single test file, already loaded into RAM, entirely in one shot, stb_vorbis was around 10% faster than Tremor. I think this is because the SH4's integer multiply instructions aren't as fast as floating point ops, and using floating point gave the compiler access to more registers to use.
I also checked how well the library minimp3 worked for MP3 decoding. This was around 20% faster than stb_vorbis for one shot decoding. Using MP3s might be a better option than Vorbis because of this (and the MP3 patents have expired), but for now I'm mainly focusing on Vorbis. Any improvements to Vorbis decode made would still apply to MP3 decoding.
I modified some of the KOS streaming code to manually fill up audio to the AICA buffer each frame, and not let it get too empty. This significantly improved the worst case per frame CPU load, from 60% to 25%. The average CPU load was 12%, so the worst spikes are still pretty noticeable, though they don't happen as much. It mostly alternates between a frame with practically no CPU load, and one with a minimum amount of CPU load, with the occasional double load frames. Dropping to 32Khz reduces the worst case spike to 22% with an average load of 10%.
I think the no-load frames are ones were there the entire amount the AICA needs is already decoded in a previous frame and buffered, and the high load frames are ones where the CPU needs to decode one or more chunks.
Vorbis decoding has occasional extra large spikes. I'm not sure where the inconsistency in the Vorbis spikes are caused by. From what I've read, a Vorbis stream can have multiple chunk sizes, so maybe sometime more than one chunk is needed, even though the number of samples need is mostly consistent?
The graph is still jagged. Some frames we don't need to decode anything, since we have enough from the last chunk. What matters most performance-wise is what the worst case is like. Instead of having to decode an entire vorbis/MP3 chunk in one video frame, it would be better if we could spread the decode time across frames. This could be gone by putting the decoder in a thread and limiting how much time it can run per frame.
The thread scheduler in KOS doesn't seem suited for this. There's doesn't seem to be a way to configure how much time a thread gets when it gets scheduled, and there's no way to synchronize scheduling with vblank.
It's hacky, but it looks like it might be possible to override KOS's scheduling and achieve this without modifying the kernel itself. The decode thread would be marked a low priority, so that it won't normally interfere with the main thread scheduling. A vblank handler would force schedule the thread and set the thread reschedule timer to however long the thread should run for that frame.
This would only work for one thread at a time. If two threads tried this, one thread would override the scheduling of the other. Ideally, some more robust way of doing this would be worked into KOS, but this might work for now.
If/when KOS scheduling improves, I think instead of specifying how much time a thread gets per frame, it should be specified per second. This way, 60hz NTSC, 50hz PAL, and custom VGA resolutions (like 640x400x70hz) will allocate the correct amount of time without extra handling.
Another issue with speeding up decoding as the lack of sound DMA. How much time does manual pushing samples to the AICA take? Disabling writing the samples to sound RAM reduced average CPU load of the decompression by about 10%. But, obviously, you can't hear it then. Replacing CPU sample pushing with a DMA driven one would get very close to that speed up.
I first tried using blocking sound DMA as a first step to getting background DMA working. The system would completely freeze every time I tried to start the DMA with blocking. I guess I'll have to look into what happening with G2 DMA. I have a fairly long (and heated) thread saved from the dcdev Yahoo Group about G2 DMA, and M. R. Brown was very critical of how G2 DMA was handled in KOS at the time, and posted some documentation of how he thought G2 DMA worked.
The "mode" parameter passed to g2_dma_transfer by spu_dma_transfer is 6 in the current version of KOS. There's a comment saying that 6 might work better, even though that's what it is? Sounds like it was originally something else, and going through older revisions, it was originally 5. It looks like KOS's DMA originated from an example by bITmASTER, where the value was also 5. Using mode 5, the DMA started working again. Is something wrong with my code or Dreamcast, or has no one used KOS's sound DMA in 15+ years?
I looked a MAME's source code to see how it handled this register. If bit 1 is set (i.e. "(mode & 0x2)") then ctrl2 won't start the DMA, and instead certain interrupts will start DMA instead? I guess the idea is that the ARM could trigger and IRQ to trigger a DMA, but a single DMA from the ARM doesn't seem enough to be useful. It doesn't really make much sense to me, but using mode 5 got sound DMA working again
Another thing is the way KOS's G2 DMA code configures the SH4's DMA controller. There shouldn't be any need to, as the Dreamcast uses the "On-Demand Data Transfer" (DDT) feature of the SH4 DMA controller, which allows an external device to set DMAC registers, for all DMA except one type of PVR DMA, which uses a special mode that does require the CPU setting up channel 2. I think the reason SH4 DMA channels 1 and 3 are the only ones that work are because they are unused, and setting the other channels can interfere with running DMA. No emulator I looked at read the SH4's DMA controller when preforming G2 DMA. I tried removing the part of g2_dma_transfer that modifies the SH4 DMA registers, and AICA DMA still works fine without it.
The first way I thought of handing this was to stop the DMA by clearing the start bit, then setting it again to resume from where it left off. But that ends up restarting the DMA from the beginning. You also can't get an idea of how much DMA remains by looking at the source, destination, and count registers set by g2_dma_transfer. They don't change as the DMA progresses. I looked at the register M. R. Brown called a status register. KOS calls it "u1".
Reading the status register before DMA returned 0x20. Starting DMA, then reading it immediately returned a 0. Starting DMA, preforming a small delay, then reading the register would return either a 0x20 or a 0, depending on how long the delay was. It seemed like a inverse copy of the DMA completion result you could get from ctrl2.
I looked into how different emulators handled the register. The MAME source names it "SB_ADSUSP", but it doesn't seem to be used anywhere. lxdream names the register "G2DMA0STOP". Well, that sounds like it might be the right register to pause DMA.
I modified my Vorbis sample pusher to write 0xffffffff (one of these bits have to do something, right?) to G2DMA0STOP immediately after starting DMA. There was complete silence, so it did seem to stop the DMA. After uncommenting the pause request and rerunning the program, there was still no DMA. It seems KOS's G2 initialization wasn't enough to undo the pause command, and it stayed stopped across different runs. Writing 0 to G2DMA0STOP reenabled DMA.
When reading G2DMA0STOP immediately after writing all ones to it, I would get 0x17. If I delayed the read a bit, I would get 0x37. My guess is (G2DMA0STOP & 0x20) means the DMA channel is idle, while (ctrl2 & 0x1) means the DMA hasn't fully completed. Some of the 0x17 bits probably mean more than just "the channel is paused", but I don't know what. They always seem to be set or cleared together.
Setting only bit 0 in G2DMA0STOP seems to be enough to pause DMA. I haven't figured out what side effects bits 1 and 2 have when set.
But I have seen both a 0 in ctrl2 and G2DMA0STOP&0x20, which would imply that the channel is not idle but complete?
The G2 read/write functions KOS have don't seem to cause corruption, but when there's a DMA, they waiting until DMA completes before operating. This explains the temporary lockup that happened when I tried a DMA with size 0. The DMA took a long time to complete, so I think the AICA channel read waited for a while for it to finish.
After a bit of extra testing, it seems setting bit 0 is enough for bit 4 and then 5 to get set. I'm not sure what bits 1 and 2 are for.
My final guess is that the correct way to read/write to G2 during G2 DMA is this:
1. Write 0xffffffff (or 0x1) to G2DMA0STOP.
2. Wait for (G2DMA0STOP&0x20) to be set
3. Wait for FIFO to clear
4. Preform read/write
5. Write 0 to G2DMA0STOP
Maybe we don't need both steps 2 and 3, but I guess it doesn't hurt to be safe.
I'm working on creating tests for this to verify this. It starts a long DMA to one part of sound RAM, and while it's going on, it will write values to another part of RAM with the SH4. When DMA completes, it checks that all values written by DMA and CPU have been written correctly. It will also test reads during DMA. I'll test a couple different methods for pausing the DMA, to see what works best.
I've also noticed KOS and SDL check different bits when seeing if the AICA FIFO is clear. Any ideas which s right? Just check all of them just to be sure?
From what testing I've done, at first it appears mid-DMA writes didn't corrupt or interrupt the current DMA, but the CPU write was dropped and sound RAM was unchanged. But after cold rebooting the system, the writes started working? I did still get some odd corruption afterwards, but I think it was because I left the ARM running while I overwrote sound RAM with test data.
When KOS initializes the AICA, it leaves the ARM running, but has it execute an endless loop (since stopping the ARM apparently prevents CD audio playback). My DMA tests would break the loop and cause the ARM to execute random code, overwriting some of the tests. At first, I just stopped the ARM, but then I changed my test to left the ARM running, leaving the idle loop KOS sets up alone, in case having the ARM stopped/running affects anything.
After doing that, all corruption stopped. ALL of it. I can't get any corruption even if I try to deliberately cause errors by ignoring the FIFO registers and just spamming the AICA with writes from the SH4 while DMA is occurring. This is pretty irritating. I want errors I can compare the error-free code against!
In the Yahoo Group thread, someone mentions that different hardware revisions might be affected differently by this. I know that different revisions of the Genesis have bits were there are slight differences, but Sega had redesign parts of the Genesis to reduce chip count and and save costs. The Dreamcast already had G2 combined into Holly at launch, and Sega would still need compatibility with older versions of the hardware, so I don't really see any benefits to Sega for redesigning and improving G2 afterwards. I think it's unlikely, although possible, that different revisions behave differently. But if anyone has older hardware versions, like the original Japanese systems, and can run homebrew, I'd appreciate if you could help run the G2 DMA tester, whenever it's finished. The manufacture date stored in flash on my main console is March 3, 2000 (revision VA1).
I haven't tried seeing how reads behave yet.
The G2 DMA code in KOS mentioned G2 status registers. I didn't look too much at them, since they weren't covered much in emulators or the Yahoo Groups thread, but I went back and did a quick check. The length in the status registers does countdown as DMA progresses. But the length status register doesn't stay at 0 when the DMA completes, and instead resets to its starting value.
It might be possible to "pause" the DMA by reading the in-progress counter, stopping the DMA completely, then starting after setting the length to the read value, but there's the possibility of a race conditions depending on when the counter is read. It could probably be done by doing multiple reads to work around it, but using the pause register seems safer and simpler.
I haven't looked at how the status registers' source and destination values behave, but they probably update the same way as the length register.
Also, wow, bandwidth to sound RAM is really low. About 5 MB a second? I know a lot of sound RAM's bandwidth is reserved for the playback channels, DSP, and ARM, but that's still impressively low.
Final major issue with speeding up decoding: Accessing the discwork drive in KOS uses PIO (CPU reads) instead of DMA. My CPU usage tests were decoding a file already loaded entirely in RAM (except for the current KOS playback library, which played from romdisk), and DMA-less disc access would increase CPU load.
By modifying KOS to use DMA for CD file system access, it should be possible to eliminate the CPU usage for this. But KOS doesn't really provide a way to prefetch CD data, so the decoder might still block occasionally. If the decoder blocks, it would need more CPU time to make up for the time lost. One way around this would be to have a separate decode and I/O threads. The I/O thread would prefetch the compressed audio data into a buffer which the decoder would consume from.
I had hoped converting KOS to use DMA would just be a matter of changing the PIO read call to a DMA read call, but while typing this it occurred to me that DMA alignment would probably be a problem. The DMA probably requires 32-byte alignment for the destination, and would only work in 32-byte blocks. KOS's existing file system I/O doesn't require any alignment or round sizes. Just converting all disc access to direct DMA probably wouldn't work as easily as I hoped.
Has anyone actually tried using CD DMA in KOS? Does it work? I would guess that there's some syscall that needs to be run when a disc drive DMA completion IRQ happens, but I don't see something like that in KOS. Are the syscalls able to still able to work correctly anyways? Marcus's site has very little infomation on disc drive syscalls. I have some disc drive syscall stuff saved from Yahoo Groups, but I didn't see anything about that. It's possible that the "main loop" syscall (or the check command syscall) could poll the DMA register for completion, but then why have the IRQ?
I personally would prefer having an asynchronous I/O system, rather than having another thread. You'd just have to ask "Move bytes from here to here, and let me poll or set up a callback to find out when it's done." Maybe have a priority system, so a game can load level data (normal priority) while streaming music (high priority). A lot of complexities that a desktop or server OS would have to deal with (like synchronization between reads and writes) wouldn't matter on the Dreamcast, which is pretty much read only.
