p-rivero / DiscordAudioStream

Windows utility for streaming (with audio!) in Discord. Easily share the the audio of entire screen, or even use OBS for streaming!
GNU General Public License v3.0
180 stars 7 forks source link

Win11 only? #10

Closed botnag closed 10 months ago

botnag commented 1 year ago

Hi,

Trying to follow the instructions to set up OBS audio capture, and found step 4 confusing where it says:

"For each of the programs whose audio you want to share, change its output device from "Default" to another device (that you are not currently using)."

This seems only for win11? I do not know how to do this in win10 since my volume mixer doesn't look like that.

Can you advise how to proceed in win10?

p-rivero commented 1 year ago

Those instructions should also work for Windows 10, you should look for a menu that looks like this image, and change the "Output" dropdown. Windows-10-modern-volume-mixer I don't have access to a Win10 machine right now, but tomorrow I'll try to send you some screenshots with detailed instructions.

p-rivero commented 1 year ago

I had a look at this today. You can open the App volume and device preferences window (the screenshot from yesterday) by pressing the Volume mixer button (or Ctrl+V) from the DiscordAudioStream window. volume

p-rivero commented 1 year ago

Since I haven't heard back, I'm going to close this issue. Feel free to reopen it if you have more questions.

sanscriptum commented 11 months ago

A related question - Is Win10 the minimal requirement? (I'm on Win7). The latest version crashes outright upon launch with the log below, and v.1.0.0 crashes when starting the stream.

System.EntryPointNotFoundException: Unable to find an entry point named 'SetProcessDpiAwarenessContext' in DLL 'user32.dll'.
   at DLLs.User32.SetProcessDpiAwarenessContext(Int32 value)
   at DiscordAudioStream.Program.EnableNativeStyles(Boolean darkMode)
   at DiscordAudioStream.Program.Main(String[] args)
p-rivero commented 11 months ago

No, Win10 isn't the minimal requirement. This crash is a bug that I need to fix. Could you check if the error message in v.1.0.0 is the same as this one?

sanscriptum commented 11 months ago

image It's just an application hard crash, and it closes immediately, so no logs, sorry.
Also the capture "area" field flickers constantly and self-resets? It doesn't let me choose anything. But it might be the problem of the older version.

p-rivero commented 11 months ago

Right, back in v1.0 the log wasn't generated automatically. You should still be able to see and copy it by clicking the "Details" button.

sanscriptum commented 11 months ago

Like I said it closes by itself immediately, I only managed to get a lucky capture by screencapping it at the right frame. There's no way I can input fast enough to click or press on that.

Oh, just figured something out: disabling "capture cursor" not only does stop the flickering, but also stops it from crashing upon starting the stream. How odd.

p-rivero commented 11 months ago

I see, sorry for the misunderstanding. In that case, I'll just focus on the original crash as soon as I have some free time.

p-rivero commented 11 months ago

The latest prerelease attempts to fix this crash. I wasn't able to find an ISO for Win7, so I don't know if it actually works. Please let me know if the crash has been fixed (and also try enabling "capture cursor" to see if it crashes when starting the stream).

sanscriptum commented 11 months ago

Thanks for an update!

Okay, this is interesting. There are many things that just happened:

1) First of all, it does launch. However upon starting the stream, it immediately closed without a word. So I enabled the log output and tried again. The third (3) log is for that, plus the error prompt. (DXGI capture method) DiscordAudioStream_log - Copy (3).txt image 1) Win 10 capture method just doesn't work outright and switches to something else. Fair enough. 1) So my only option was the BitBit capture method, which worked, but... 1) "Force screen redraw" made the window get extremely slow and fail to actually redraw anything. It made the solitaire effect with the preview window leaving traces of itself everywhere even after closing. The second (2) log shows that when I enabled it back at the end. DiscordAudioStream_log - Copy (2).txt 1) So with the aforementioned option disabled, and with BitBit capture, the preview did appear a little less smoother, but I guess it's just the 30FPS thing. The first (1) log shows nothing out of ordinary (except when I tried to switch to Win10 Cap Method) DiscordAudioStream_log - Copy.txt 1) Somehow capturing the specific window doesn't work at all with the preview area being completely black, both here and in 1.0.0 version. Nothing out of ordinary in the log file though. 1) Edit: Capture Cursor does work flawlessly, yay

As for making sure that the audio stream actually works, it remains to be seen. I'll restart the system and try to tinker with it in a bit. Part of me hopes that I can just Plug&Play the OBS webcam capture with sound no problem, but I have the VBCable installed and monitored device configured just in case.

p-rivero commented 11 months ago

Thank you for the logs, this made finding the problems much easier.

Regarding [1]: the DXGI duplication API was introduced in Windows 8, so it can't be used in Win7 (as explained in the docs). However, it should fail gracefully like the Windows 10 method in [2], but instead it's flooding the thread with errors, and once it runs out of memory the app crashes. I'll have to look into that.

EDIT: This is now fixed in the latest prerelease. Attempting to use DXGI duplication should now fail gracefully.


Regarding [4]: forcing a full redraw is a hack to allow the DiscordAudioStream window to be streamed even when it's partially off-screen. However, it's known to be very CPU-intensive. If your use case doesn't need that, you can safely disable it. Also, in your case, it was extremely slow for 2 reasons:


Regarding [6]: the PrintWindow method was introduced in Windows 8.1, so again your only option is BitBlt. Make sure the "Window" capture method is BitBlt and let me know if it doesn't work. However, this method has some serious limitations. From the docs:

  • Cannot capture windows that are partially outside the screen or occluded. When using this method, the captured window will be brought to the front (other windows cannot be placed on top).

Regarding the audio: OBS does not output any audio, you'll have to grab it from each app individually. Open the "Stream to Discord using OBS" dropdown from the readme. VBCable is not required, but you can use it if you want (just use [IN] CABLE Output as the audio capture). However, keep in mind this might add an extra layer of audio delay.

sanscriptum commented 11 months ago

Okay, I tried to stream with sound and it went well, however the framerate dipped during action apparently, so I guess there's no cutting the middleman in this case. I'll try it with OBS and report back later. Update: The window capture seems like a no-go even with BitBit, the preview is black and it stays that way.

p-rivero commented 10 months ago

Sorry for taking so long, the window capture should now be working on the latest pre-release and the upcoming v1.3.2 release.

This time I managed to find a working Windows 7 ISO and was able to verify that the bug has been fixed, so I'll close the issue for now. Feel free to reopen it if I didn't catch something.

sanscriptum commented 10 months ago

Hmm, not sure about that, the screen capture got very unresponsive and laggy (looks fine on preview though), and flickers constantly, way more than usual. The window capture makes it very difficult to alt-tab back to Discord Audio Stream, and upon streaming it only shows a tiny black window.

p-rivero commented 10 months ago

If the screen capture looks fine on the preview but not when streaming, go to Settings -> Debug and make sure that "Force screen redraw" is turned off. When it's off, the preview and the streaming window behave identically, so if the preview looks fine, the stream should too.

Keep in mind that the BitBlt method is very CPU intensive, so if the resolution of your screen is high, you may need to lower the FPS to get a smooth stream.

Edit: In addition to disabling "Force screen redraw", please also try the new pre-release. I added some changes that could improve the performance slightly (or also make it much worse).

sanscriptum commented 10 months ago

Aha, I see, so the window capture only really works if the window is in front, which makes it difficult to alt+tab. As for CPU load, I stream only on 720p without nitro so I assume it shouldn't be an issue.

p-rivero commented 10 months ago

Aha, I see, so the window capture only really works if the window is in front, which makes it difficult to alt+tab.

Exactly, since BitBlt can only capture what is visible on the screen, I thought it would be better to force the captured window to the front, so that the user doesn't accidentally capture something they didn't intend to.
I could add an option to disable this behavior, but I don't think it's a good idea to accidentally capture something else than the intended window.

As for CPU load, I stream only on 720p without nitro so I assume it shouldn't be an issue.

The biggest bottleneck is capturing the screen, not streaming it. The CPU load depends on the resolution of your screen (or the window you're capturing).
However, it's strange that you're getting such a high CPU load, even with BitBlt. Were you able to try the new pre-release?

p-rivero commented 9 months ago

Turns out that the PrintWindow method does work in Windows 7 with some small changes. Try downloading the new pre-release and changing the window capture method to PrintWindow. It should be able to capture off-screen and occluded windows. However, keep in mind that it can cause flickering on some apps. I'll copy the warning from the docs:

Warning: Some programs may flash or flicker while using this capture method. Usually it's not very noticeable, but I strongly discourage using PrintWindow if you are sensitive to flashes or suffer from epilepsy.