However, I don't think this should piggyback off the Audio Output Capture source type, at least UI/UX wise. I'm mostly in agreement with what Matt suggested. I've thought on this more and changed my mind a bit.
I do not think we should have two separate flows through the program for capturing a game or window depending on what the user wants to capture from it Sure you can hide the source but that's still taking unnecessary ressources.Ī dropdown then to choose between capturing video, audio, or both perhaps? What if you want to include some audio but don't want to show that window? Have not tested my PR myself yet, but from a UX standpoint is there any reason this can't/shouldn't just be a checkbox in game capture / window capture that says "Capture audio directly" or something? This is for when the user doesn't want to window capture the process but does want its audio (eg. I'd say this method should essentially use the same window lookup/storage functions as Window Capture (same kind of dropdown). For the Process / Application method, I agree that process ID would be bad.
This should behave identically to Process mode, but doesn't require the user to manually specify a process, it just mirrors the Window / Game capture source's selected window.
It is accessible from the Audio Mixer using the gear + Properties, but in this particular situation that should remain device-only. This is because the core of that is modified in the Audio section of Settings, which a user shouldn't need to modify live. This should not be a thing you can set to a global audio source (the default Desktop Audio source, for example).So here are my thoughts on how I think this should be exposed to the user:
0 kommentar(er)
