Exophase said:
I'm actually testing from SD card.
Nice work then. I wonder how you got around those I/O problems, dedicated thread? Are there any games streaming data (like FMVs) a lot? I wonder how would those run, if there are any (I'm not familiar with TGCD games).
No dedicated thread for CD streaming, here's what I'm doing, any one of these things might be doing the trick:
- with a small buffer to audio (2048 bytes, which is under 1 60Hz frame's worth) there's no benefit in trying to have delay based synchronization, it just makes things worse (and I think this is what I was fighting against half the time). The audio thread will block when it needs more data, and the sound generation will block when the audio thread is too far behind (and each will signal each other otherwise) Once I set the LCD refresh rate for non-MK1s I'll try vsync based synchronization as well.
- fcntrl is used instead of stdio to circumvent the overhead + buffering this does. I've found on PSP that stdio can be much slower so I decided to throw this in since I didn't want any implicit buffering anyway.
- There's a block cache of a few blocks (and a table to map them, it's probably not worth it to have a table for so few now.. at first I was doing like 8MB but there's no point whatsoever in that). It loads 4KB at a time - this is mainly to try to get around the boundary issues of 2352 byte sectors and fit to something that's a good fit for the filesystem.
- After rendering a frame the next CDDA audio sector will be preloaded into the block cache. This could be modified so that it does the next data sector during loads too.
I don't have a lot that streams video (nothing that works -_-) but I have things that stream ADPCM which should work out the same. I don't really see any reason why data streaming should work any worse than audio streaming though.