Reduce calls to Init() in sound drivers

[ann0see]

Description

Findings from the last ASIO4ALL bug fix showed that the Init() function might be called 4 times in the ASIO backend. This feels inefficient. I remember that iOS even refused to start due to having too many audio initialization calls.
We might need to rethink the sound design - not now but for after the review freeze.

[mcfnord]

🤖 AI: The four is in CClient::Init(), not the ASIO backend: three frame-size capability probes (client.cpp:1129-1131) and one real call (:1146). iOS already skips the three.

Settings load multiplies it: of the thirteen Init() call sites in client.cpp, nine are settings setters. On a Focusrite USB ASIO device an instrumented client made 9 CClient::Init() calls before the window appeared -- so 36 CSound::Init(), spending 11 952 ms inside ASIOCreateBuffers, all of it before anything is on screen. The charge lands on a buffer-size change, and the three probes ask for three different sizes.

The TODO directly above the fourth call already says 9 inits at launch <- slow. Same nine.

Separate from launch: connecting to a stock server doubles connect-time re-init too, 4 to 8 CSound::Init calls, regardless of the client's own audio-quality setting. CClient::OnRawAudioSupported() stops/inits/starts the device with no eAudioQuality check, and the server sends that message to every client on connect (opened by #3653). Measured on Linux/JACK, stock binary, gdb breakpoints, --noraw as control: 44 CSound::Init (36 launch + 8 connect) vs. 40 (36 + 4) -- corroborating the 36/9 launch count above on a second platform. At 328-391 ms per call on the Focusrite trace, the extra 4 is ~1.3-1.6 s of avoidable re-init per connect.

[ann0see]

Thanks for the clarification. It's worth investigating it even more then...

[dingodoppelt]

Thanks for the clarification. It's worth investigating it even more then...

The connection process is all over the place and should be redesigned to negotiate a proper handshake. The freely available 4 bytes (#3896) could be helpful.

[dingodoppelt]

We could save another call to Init() (and the reliance on the version and os message) by deprecating packets without a sequence number. Just a thought.

[pljones]

We could save another call to Init() (and the reliance on the version and os message) by deprecating packets without a sequence number. Just a thought.

Now, if we had stats from the Directories as to how many IPs generated those, we'd be in a better position to judge.

I don't remember which version brought them in.

[mcfnord]

🤖 AI: Before/after numbers for both levers, on main @ 5146a072, Focusrite USB ASIO, 5 launches per arm, interleaved. CSound::Init calls are attributed to a phase by their own timestamps; every arm's per-phase counts were identical on all five reps.

arm	launch	connect	teardown	total	window (median)
stock	36	8	4	48	13308 ms
coalesced settings load	4	8	4	16	2704 ms
cached probes	12	2	1	15	3060 ms
both	4	2	1	7	2709 ms

The two levers act on different phases, so they are complementary rather than overlapping. Coalescing the sound section of the settings load collapses launch to one CClient::Init() and removes none of the connect calls; caching the frame-size probes barely moves launch but cuts connect and teardown. Measured at startup alone the second lever looks redundant; across a full connect-and-quit it is not.

The charge is per buffer-size change, not per call: 32 of stock's 36 launch calls cost 328-391 ms, 4 cost nothing. On ASIO4ALL those same calls cost 16 ms in total, and across two runs every arm lands within 306 ms of the others.

Controls: settings round-trip byte-identical after a settled close, probe results unchanged by caching, shutdown time unchanged across arms at 308-415 ms, and audio verified on the Focusrite through the server's own recording. One caveat on that shutdown figure: closing the client by posting WM_CLOSE intermittently fails to close it at all, in 6 of 35 stock launches, and those runs contribute no shutdown time. The rate does not separate the arms (0 of 10 on the coalesced build is what a 17% rate produces 15% of the time), and it is not Init work — every Init call completes about 1.8 s before the window appears, in all 45 launches measured. The cause is not yet identified.

[pljones]

I tempted to split this into two phases - "coalesced settings load" first (get the simple part done), then the "cached probes" part.

I don't think I'd want a single PR for both.

[mcfnord]

My AI says two PRs would be no problem.