Firebrandx wrote:I get a white screen on the image window, though everything else (including sound) seems to work fine.
Do the VDP palette and VRAM windows work, or are they all white too?
Shadow wrote:Very odd, i just uncheck HT cores in task manager for Exodus and got big speedup on DirectColor-DMA test. (29-32fps)
You are a bit at the mercy of the Windows thread scheduler here. I've experimented with manually assigning thread affinity within Exodus, but I've never been able to gain a speedup by doing it manually.
Huge wrote:HardWareMan wrote:Huge wrote:I imagine that would be limited by your drive speed, not cpu power. Have you tried it on a SSD?
OK, let's see. 5 threads for one channel. 6 channels and one master out. So we have 5*6+1=31 threads. Output format is 44100/16/2 that require 172,2KBytes/s. In result: 31*172,2=5340,2KBytes/s or 5,2MBytes/s. Do you still believe that is not enough the regular HDD? This speed is smaller than can done my UDMA33 HDD 10 years ago.
Try copying 31 files onto the same HDD simultaneously and then tell me you reach 5mbyte/sec. Or even 500k. SSD should have no problem with that though, that's the main reason they are better, not just the sequential reads.
The problem could be related to how the files are saved though, it might be "emulating" each channel separately for dumping purposes, so emulating the YM2612 30 times or something like that (I'm assuming that due to the nature of FM, you can't just do all channels ones and mix them together before outputting - so for channel dumping, you actually have to do all channels as their own device?).
Nah, I really have no idea.
The sound logging output happens directly from the main render thread, just before the data is sent to the audio output buffer. The logging happens at the actual native internal sample rate, not the output sample rate, there's actually around 55000 samples per second being output.
That said, the slowdown is due to the way the logging is being done. Operator samples aren't buffered, they're just combined together into the output buffer, which is then resampled at the time it is being sent for audio playback. Since the operator samples aren't being buffered, they're written to the file stream one at a time. That wouldn't normally be a problem, except that in order to write wav files "properly" using the win32 API, I'm using a special file stream that uses mmioWrite to write samples to the output file, and I haven't implemented buffering over that, so it's literally hitting the file system for each and every sample. I'll implement some buffering over the top to fix that problem.