Um, different animal, one is threading, the other I just put the guts of mixer_mix into mixer_callback, calling mixer_callback from mixer_mix, which seemingly produced a slight improvement, but doesn't mesh with the threading.

Attached is threaded mixer_mix diff using sdl_delay and put back sdl_lock/unlockaudio.

jmarch, I've added locking to capturing in hardware.cpp, untested, need a puke condition to verify locks work preventing said puking.

Solve the dac bug and play nice adding thread shutdown wherever dosbox shuts itself down would complete the patch I think, like to see what load threaded mixer_mix gives going over it with profiling like latalante did for the nonthreaded goofyness, thanks for that, BTW. At least with it threaded there's lots of room to add audio post processing or heavier emulation without impacting performance.

You also need locks around all the pic stuff and basically any audio device state that gets touched when the device's MIXER_Handler function gets called. Good luck.

(Any problems will probably be hidden on x86 architecture due to atomic/direct memory operations, other archs that have to read-modify-write memory values will be much more susceptible to issues caused by more than one thread modifying the same data.)

>You also need locks around all the pic stuff

Not from what I see, what CAPTURE_AddWave touches that's referenced outside of it comes down to capture.video.audioused and capture.video.audiobuf, which is what got locked.

Oh yes, now the difference is visible not only in perf, but very clearly in the benchmark.

dosbox-r4356 + mixer3.diff

1Children|Self |Command|Shared Object|Symbol
21,04%     0,01%  dosbox  dosbox  [.] MIXER_Mix_Thread
30,15%     0,02%  dosbox  dosbox  [.] MIXER_MixData
40,04%     0,04%  dosbox  dosbox  [.] MIXER_CallBack
50,02%     0,01%  dosbox  dosbox  [.] MIXER_Mix
60,01%     0,00%  dosbox  dosbox  [.] MIXER_Init

What did you test with? Something with fm and dac playback I hope? I also accidentally left a log_msg running, did you comment that out?

Another thing to do is cut the "max" headroom by about half.

awgamer wrote on 2020-08-23, 08:23:

Not from what I see, what CAPTURE_AddWave touches that's referenced outside of it comes down to capture.video.audioused and capture.video.audiobuf, which is what got locked.

I'm not talking about CAPTURE_AddWave, I'm talking about all the stuff that MIXER_MixData can possibly call... practically all the audio hardware calls PIC functions for IRQs and DMA stuff, and none of that is designed for multithreaded access (and most of it is linked lists which are not atomic-friendly).
There's also all the audio device hardware internal state that gets accessed while generating samples that may also be used by CPU code that's running at the same time.

Ah, you threw me, pic stuff, as in irq, not pic stuff, as in audio video capture. I'll run through that , might even be the fix for the dac bug.

There's setting "max" cycles and do once more it sets to 105% and then doesn't allow the user to go higher, which I'm looking to undo, would expect it to be a simple change to keep going with 110, 115, etc., I thought that handling wouldn't be so hard to spot, I was wrong. Maybe I've been away from it too long but the auto cycle code seems harder to follow than the recompiler. Anyway, that's what I'm poking and prodding currently. edit: well, it's not what I was looking for but it will do, CPU_CyclePercUsed*95 instead of 90.

Tidings and salutations, I bring news! Not fixed yet but I've narrowed it down, playing around locking various things to see the impact, lots of no difference but locking ret = (*cpudecoder)(); in Normal_Loop(void) in dosbox.cpp gets dac playback to run error free, albeit slowly. Continue going down that rabbit hole to find the ultimate conflict inside the decoder, come up with a solution to make that happy without being slow and bobs your uncle.

:thumbs up: @awgamer.
And.. I'm looking forward to having a 2nd uncle Bob!

A new toy to play with, threaded cycle handling. doom, 3dbench, diag report better results but quake isn't impressed, worse fps. Also changed the max from 90 to 100% Anyone know the problem games that led to limiting cpu usage to 90%? I haven't run across anything that has issues at 100, most games cpu usage well below 100, I'm only using an igpu, perhaps that explains that behavior, bottlenecking things, or dosbox rendering code that's the hold up.