When Discord is open in the background, NVIDIA card will not reach full speed
nvidia.custhelp.com
nvidia.custhelp.com
I work at discord and specifically have been tracking this issue. We recently released support for AV1 hardware encoding for go live streams. However, the process of probing the GPU for what codecs it supports has triggered a latent nvidia driver bug. We are releasing a workaround some time today, and nvidia is releasing a driver update to address this issue as well.
Apologies for any inconvenience this has caused.
That's one interpretation. But it could also read as "Discord bug instructs Nvidia card to throttle when in background". The title should have specified the bug was on Nvidia's end
> more likely
I'll agree to disagree here though. That seems significantly less likely to me. I haven't heard of excessive CPU/GPU usage causing throttling, unless it's temperature related. Normally when you have high CPU usage, your clock speeds up not slows down. But in that case, the problem is high heat or 100% usage, not the side effect that happens to be throttling.
That was indeed the case I was thinking of. It's easy to generate a lot of GPU load with minimal CPU load with some GPGPU process going haywire, for example.
That is how I read it
At least this has been the case last time I checked. And there is no way to disable the animation.
I think you can ask that question to Windows, instead of probing. Call MFTEnumEx API function with MFT_CATEGORY_VIDEO_ENCODER category, MFT_ENUM_FLAG_HARDWARE | MFT_ENUM_FLAG_TRANSCODE_ONLY flags, and MFVideoFormat_AV1 in the output video subtype.
https://learn.microsoft.com/en-us/windows/win32/api/mfapi/nf...
The function you linked to queries the registry, and that on its own can be invalid information. How does that info get there?
It ultimately reminds me of this article:
https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40...
Hardware codecs are complicated. See V4L2 Linux kernel API, it exposes hardware codecs without doing anything on top.
GPU vendors have higher chances of correctly using their hardware, compared to Discord developers.
> How does that info get there?
GPU driver package installs not just user/kernel mode halves of the driver, it also installs and registers these media foundation transforms. They are DLLs which wrap hardware codecs into higher-level API.
> reminds me of this article
The article is about Win95. It's now harder to ship broken Windows drivers. Windows checks for Microsoft's digital signature, and users expect drivers to be available on Windows update.
Is this related to a view port bug of Windows, and non-alignment?
It took me a few months of on-and-off searching, but I eventually found a comment on a message board where someone had experimented with things by closing different sets of applications and then trying to connect to a DayZ server. They finally figured out it was Discord that was causing the issue.
I don't know how people find it tolerable. It'd kill the battery of a Macbook that could handle 6-8 hours of actual work (this is pre-M1) or 10ish hours of playing Netflix or whatever, in 2 hours flat, fans whirring madly the whole time. WTF. And it wasn't just one of us, and it wasn't just Macs, anyone on a battery-powered device saw their battery life cut to a sliver of what it should be. To make matters worse, nearly every session saw at least one person's Discord simply crash and have to restart. What is this, the 1990s?
I was video-chatting in goddamn 2002 on a potato. Yeah the resolution was ass, but it's not like this is some totally new, hyper-advanced tech. It should have gotten far more power efficient! Look how great codecs are now! Video chat shouldn't burn my battery like I'm having it calculate digits of Pi in a hot loop on 20 threads plus a hundred graphics-chip threads.
Lastly, Discord has absolutely the worst software engineering behind it.
That being said I would love to have less memory allocation on my devices when effectively idle too.
One might consider these as cutting corners - hiring web developers to build an app that really should be native
If you want to do things properly, you hire separate teams who do native development for each platform, or you hire one Qt team for desktop and two teams for the two app platforms. Of course that's expensive, but again developer vs user side. That's what I mean by cutting corners.
And regarding electron there are different kinds of apps performance wise, like Atom vs VS Code. Discord is more on the Atom side of things, sadly.
Discord is also so big, that interested people develop lean third party clients for it. It's possible, but Discord rather bans them and forces users on the worse electron/web alternative.
Ripcord's very existence contradicts most of the claims you've made above.
The workflow that I've seen for frontend coding today is that a designer makes a mockup in something like Figma, and then a frontend programmer has to go remake it from scratch in typescript? It seems crazy that we have not made any progress (or even regressed) here in 15 years, but hopefully I'm just out of the loop on state of the art.
I like Qt for how much it enables us to do, but having worked with Qt Designer, it can get off the rails once things get too complex. Probably doesn't help when you enable/disable UI elements programmatically, but still lol
The usual explanation is that non-JavaScript devs (every programmer over the age of 40) was an amazing genius, and we need Electron/Flutter/Node/left-pad/etc now since there are so many new coders. I think you're on to something though. Somehow modern practices just result in wasting incredible amounts of time and effort tinkering with fiddly frameworks and boilerplate code
This cannot be any serious part of the reason, since literally playing 3D video games fullscreen at full resolution can use less power than Discord.
[EDIT] For that matter, any streaming video platform. They're ~all extremely battery-efficient even when pushing 4k.
Discord is showing emojis, images that are 10MB+ each, and all kinds of user generated crap at high res that it doesn't have control over. Personally I'd prefer to go back to just text.
And if Discord is rendering a 10MB+ image then that's definitely a problem with discord. 1920x1080 at 8bpp isn't even 10MB.
I don't think this excuse flies on anything made in the last 10 years, at least, except maybe trash-tier netbooks or something. Unless the software is so amateurish that it doesn't even try to negotiate a codec that suits the hardware it's running on, and just picks something evidently-poorly-supported no matter what.
I know that intel macbooks added hardware encoding from iphones into the T2 chip in part to solve this problem, but I also know that intel has quick sync, which should provide hardware encoding as well, and I didn't know what the pros/cons are. according to this article [1] the T2 chip seems to be much faster than intel quick sync, so that could be a factor, but it doesn't seem to cover power efficiency.
From a timeline perspective, Intel quick sync has been around on at least some Intel CPUs since 2011 and has been supported on osx since Mountain Lion (2012)[2], and the T2 chip first appeared in the Macbook pro in 2017 [3].
That would point to there being more at play than just absence of hardware video decoder. So I think you are right. At least _some_ hardware that can encode video efficiently has existed on macbooks for a while, and it seems like video conferencing applications should be taking advantage of it.
While it is always possible that the hardware could solve this problem, but the software doesn't make use of it, I have a feeling any software that did have correct use of encoding hardware would have gained a lot of marketshare, and people would be talking about it.
My next followup questions would be:
1) Were these computers in fact using hardware encoding, but the efficiency was not good enough for long battery life?
2) Is there some limitation to QuickSync and possibly other hardware solutions that makes them impractical for realtime use? Possibilities include:
- Maybe they are throughput optimized, and to work efficiently must take in large chunks of data at a time, which could increase latency beyond what would be acceptable for video calling
- Maybe they can't simultaneously do video decode and encode (it seems at least some generations of QuickSync couldn't do this)
- Maybe the hardware encoding isn't configurable enough to provide a low bandwidth typically used for video conferencing.
1: https://appleinsider.com/articles/19/04/09/apples-t2-chip-ma...
2: https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Develop...
The mobile app is sitting in my "notification jail" folder three pages deep too, where apps that abuse badge notifications are kept.
Note that you can also use Discord just as a browser tab, dunno what the difference is with having a client as I've only ever used the browser version (and I bet the client is electron aka outdated browser under the hood anyway).
Maybe it's the assumption that legitimate/good-will programs do not interact that causes this issue. It's ridiculous, and untrue. I don't really use Discord and I have a strong distaste for the kinds of social circles that it breeds, but it is a technically excellent product.
If someone wants to see an example of a triple-A game product that is built with this kind-of misunderstanding of the NT kernel and Windows operating system (and shell, and their own compiler toolchain... Oh my...), here lies a funny video: https://www.youtube.com/watch?v=b8xtw54-lCI
This feels like "dog bit me once, so now I will hate all the dogs".
Discord is a platform for comunities, and its your choice to choose amongst them. Many of such are of superb quality you cant find anywhere else. The key is in moderation.
In 2023, what app experience is still impossible to do in the browser?
The only things I can come up with are apps requiring access to outside hardware or files. There are now several entirely unique ways in which a AAA gaming experience could be delivered to a client browser. If we can ship resident evil frames to a Chromebook at 30+fps, is there anything we can't do?
One use case also used to be that you would use a browser tab for one discord account and the desktop app for another, but container tabs + browser profile switching made that less necessary. And then discord eventually added support for multiple accounts.
I think we are just 1 tiny browser API away from this one being solved too.
If we can agree on a way to capture the pointer device, I'm sure we could figure out a reasonable way to capture certain user-defined keys. The actual key that is subscribed to can be abstracted away by using some registration API. I think this would eliminate key logger concerns (you'd have to ask the user for every key on their keyboard) E.g.:
RequestGlobalHotkey('my-hotkey-id', 'Discord Push to Talk');
and then if the user presses it, we call something like OnGlobalHotkey(e) where the arg contains 'my-hotkey-id' and keypress state.
That's not even 100% true either [1]. For instance, you can flash Android devices from the browser. The example in [2] talks to an attached Arduino device.
Screen capture API has been a thing for a while now:
https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capt...
It has a UX almost identical to discord with regard to screen/application capture experience.
a) communication protocols that aren't encapsulated in http(s), websockets, or webrtc. There's good reasons for some of this, and it's not that limiting, since popular protocols tend to grow some of these encapsulations to circumvent lazy firewalls, but it sticks out to me. Additionally, a page/app can't run a server for other browsers to connect to, it's got to be intermediated with a separate server; it would be difficult to make an offline LAN multiplayer game work.
b) reliable non-interactive push messaging and/or background connectivity. Again, there's good reasons, and you wouldn't like every page/app to have this capability, but this capability enables good offline usability by fetching data when available and pushing user driven updates when available.
For example, Email should be offline capable, and it should have nearly all the messages that were available when last the device had connectivity, and it should let me compose new messages and replies and queue them until connectivity returns. Maybe it should even speak IMAP and SMTP, but JMAP is probably good enough and browser accessible. Same with other messaging systems, assuming they have queued messages and aren't online only.
IMHO, mobile operating systems have gotten better than legacy desktop operating systems in a bunch of key areas. But of all the platforms, the web is the worst one. The web has tracking everywhere and often uses a lot of CPU, memory, battery, and bandwidth.
(I'm not an Apple user and never will be because, with the highest privilege level being reserved for Apple themselves, I don't own the device / can use it for general computation. It goes against my principles so I'm not some apple apologist, it just doesn't make much sense to assume what you said. Google wouldn't surprise me at all....when using Google Chrome/-ium. That's a choice. On Android, your data is fully in your hands, even if you have to fight tooth and nail for getting it your way.)
The alternative to using something like Discord on the web is not a well-optimized desktop app that is somehow more respectful w.r.t. tracking than the web version. Same goes for Slack, Zoom, etc. It will still use lots of CPU and memory, and now in addition to tracking you with the techniques available to it in the browser sandbox, it will gleefully list the processes running on your machine, rifle through your files, try to get itself to start up automatically on login, try to get it so that when you "close" it it's still running in the system tray, and generally just make itself at home.
Desktop apps written by devs who first learned to write desktop apps are better than web apps. Desktop apps written by web developers are like demons that have broken through the summoning circle. The browser sandbox doesn't protect you from fingerprinting techniques and the ensuing tracking, but it protects you from a whole lot of other stuff. Take away the sandbox and the shameless data vampires get anything they want.
I think you're correct that desktop operating systems are in sore need of a permissions model for non-free apps. It should be possible to build one, and then shame vendors into using it.
The extra crap -- especially information gathering -- ends up making the native apps slower and buggier.
I bet iOS electron based apps are tracking significantly more than FF + uBlock. It's also why I strongly dislike Electron. It's basically Chrome without uBlock.
If you think websites track you, why wouldn't the app made by the company that adds the tracking on your browser ignore tracking you with their app?
Negative. It's actually the other way around. A browser is more controllable, especially with extensions.
An application in a browser cannot do certificate pinning preventing you from inspecting SSL traffic. Nor can you have uBlock origin running for your Discord app.
The demo has infinite days, but it's a good idea to actually donate if you like the project :)
I've been using ripcord for half a year now, and my account hasn't been disabled so far. If they actually choose to terminate my account because I'm using a more efficient client, I'm going to be really upset.
¹(usually…)
Not that I'd argue for making one Factorio frame a unit of measurement, to be fair; I just don't think the remark was useless.
Currently my biggest annoyance is for some reason every time I start a game, it also tries to access my Camera. Some people online are saying that it is because my webcam has a mic... but why is it trying to access my mic when I launch a game and discord is just sitting in the background?!?
But at the same time I have a lot of friends and groups I game with on it, sometimes in voice chat. The convenience of it is really nice.
Not really sure why the overlay would be trying to access my webcam or my microphone either though. But I also never use it and not sure why its enabled.
Please use Discord for chat, but don't use it as your main platform, please! Rant over.
I know where you are coming from here, but that's not really on Discord, but on individual server management. The people who organise their Discord servers like that would probably have created a similar mess in ye olde forum times, or on Slack or whatever. Plus bigger servers tend to be subject to SPAM and scamming and counter-measures seem ad-hoc at times because native tools for handling that are a relatively recent addition.
And for all its faults (not open source, slow, privacy concerns, OP, etc.) Discord also has some things going for it. Lots of people are already on it so network effect is a thing here, it's relatively easy to pick up the basics off and there are no immediate paywalls (which makes it attractive to semi-public projects without a cash flow), a lot of basic and advanced features are there to use, and most of them work across a lot of platforms.
My biggest gripe with it (besides the aforementioned) is that its better new features like forum channels and stage channels are locked behind usage metrics and/or paywalls.
I use it for gaming, with voice chat. Works fine. The only downside is that your voice chat audio will output to whatever channel your browser audio is set to.
Edit: also push to talk wont work, but it will pickup the microphone audio while inside a game. Set the threshold high or use the mute button on the microphone.
So if you have a headset and want voice chat to go through that, make sure to set that to the default audio channel in your OS before you join the voice chat.
Inputs (microphone) have no such restrictions.
Other than that gotcha, its about 1000% better than running a huge bloated electron App.
The first chat sites on the web e.g. Bianca’s, Poolside, and Talker were built using more primitive versions of the same interface tools used by electron and while they didn’t have the functionality of video and audio chats, they also didn’t break your GPU driver.
I miss the Unix philosophy at times.
A big part of discord's target community is gaming/gamers. One of the features it provides is the ability to livestream the game you are playing and view streams of games others are playing.
Definitely not my area, but I wouldn't be surprised if streaming some game with an overlay would require 3d acceleration to not suck.
It reminds me of the age of Windows bloatware.
Trying to pile all the ingredients on a single piece of bread does not a good sandwich make. On the contrary, it leaves me with an impression that they have to rely on the brand recognition and snowball effect of previous products.
I would probably hold their software in higher regard if it wasn’t just one monolithic multi-tool. They don’t even have to push multiple apps, but could use a modular architecture at the app level with plug-ins to support non-core functionality.
It is not a good user or server owner experience to have to manage multiple applications depending on feature. You can turn off 3d acceleration, if I understand correctly.
On the other side of the multiple app token, Microsoft doesn’t build out PowerPoint, Word, and Excel as a single monolithic Office app.
And I’m pretty sure that’s among the most commercially successful consumer software in the history of computing.
But it's hard to split it much more finely, and two in one isn't going very hard into bloatware. And I like the integration between the two.
I would change a lot of things about discord but not so much that part.
Discord was started to solve a big problem: how to communicate with friends around the world while playing games online.[1]
That said, maybe it’s not the app for you. I totally get why someone would want a single-purpose tool - that’s generally the way I go and I’m not crazy about discord personally having used it a lot, written bots for etc. It’s not reasonable to criticise them for making different decisions from the ones you would make when they are going for a goal that you don’t share.
Discord Snap has to block many unusual activities, but I still see these:
* attempt to `ptrace` processes all the time;
* using 99% CPU;
* to work Discord needs some non-standard interfaces to be connected;
* Discord tries to track which other programs you run by default and shares it.
* too frequently restarting desktop integration snap until the logs make machine non-functional (got 500GB.)
* blocking other programs using desktop integration for file dialogs: latency of several minutes, sometimes dialogs never appear.
Discord is as dodgy app as can be. Hope we will not find it is actually another distribution of spyware.
Since programs with so many bugs and crashes are frequently prone to security issues, I recommend to replace Discord with another app that allows push-to-talk.
Now you need a quad core 3GHz chip and 8GB RAM just to run a chat app reliably. Where did we go wrong?
... but, point is, a chat app ought to be able to run smoothly using perhaps 10% of a single efficiency-core on an M1, when actively being used, and about 0% when inactive. These programs acting like they're mining Bitcoin just to let you chat, which we used to do on hardware far weaker than many modern thermostats have (hell, maybe even some lightbulbs), are absolute jokes.
Not my experience. Windows (and IIRC MacOS too) always had a great disk I/O scheduler that prioritized audio related tasks so I never had mp3s pop or skip on me, no matter how hard I was thrashing my spinning rust disks back then.
Linux was the one where I noticed this issue intensely back then as the schedulers used by mainstream distros were all tuned for server/mainframe workloads.
I do feel that these apps these days, Discord included, eat a ton of resources, and that it feels like a regression.
I think the blame fully falls on the developers of such applications, not on the framework.
Strange enough they're now touting the move to Edge WebView as the solution (since they finally acknowledge how bad Teams is) but never explained how this will solve the problem as it's just the same tech (chromium) underneath.
Humans are lazy (efficient?) and will always gravitate to the easiest tool for the job. If “the job” is just to make a functional chat app, it becomes wildly efficient to simply wrap your web app in electron.
I’ve done it to an existing web app and it took less than a day to suddenly have “native” .dmg and .exe to distribute.
So when we yarn for the days of IRC, I think we should also yarn for the days when JavaScript was not the de facto language for everything which lowers the bar for development so incredibly low that you are ending up with truly garbage desktop apps that should be written in native windows SDK using C++.
But it still surprises me that Discord of all seems to care so little about the resource footprint on their users devices. Considering that Discord is still mostly used for gaming you would expect that users want the communication app's system footprint to be absolutely minimal and without any negative impact on the actual game. Thats why I always loved teamspeak so much
You would think with all the apps that use Electron this is something that would be fixed (I don't know if the root cause is Electron itself or some bad practice that people who use it do often enough that I've mentally associated it with the framework) but I've seen this issue with every Electron app I've used for any period of time (except VSCode) for years.
It used p-2-p over port 80 so it would always reach its destination no matter the firewall rules on your network, and it allowed file transfers up to 2GB(!) in size, in 2005(!).
Can present day Discord do that?
Skype was great at first. Then Microsoft bought Skype and turned it into a shithole. Then Microsoft said that this product is trash and migrated everyone to use MSN. Thanks, Microsoft!
It used p-2-p over port 80 so it would always reach its destination no matter the firewall rules on your network, and it allowed file transfers up to 2GB(!) in size, in 2005(!).
There were no better alternatives at the time.
(The Discord TOS does not even mention third-party clients.)
> All 3rd party apps or client modifiers are against our ToS, and the use of them can result in your account being disabled. I don't recommend using them.
like reddit, bans are entirely meaningless
Reddit is new user hostile.
indeed it is, because if you're new and don't know about the effective shadowbanning of new users then it just looks like the site is dead
meanwhile anyone actually banned will just go and pay $1 for a 3 month account with 100 karma
If we could pare our use of Slack down to just text, it would be a great alternative - but until them I'm stuck using the official client.
Two years ago the multinational company I was working at had a global ransomware attack and we had a teams call for like 7 days straight with check-ins every two hours for everyone but there were on call people in there always if you had specific questions.
It worked really well and made it easy for people to get stuff done and have clear chain of command when everything else was down.
The tiny window is sorta useless except for mute/hangup, but you can undock it from the sidebar and make it much larger for video chat or screensharing.
I'd love to see some real focus on open standards and enforcement for those standards at a legislative level (the first to go should be any limits on 3rd parties acting on behalf a user... it's essentially the same as the court case that allowed consumers to install 3rd party equipment at telephone jacks)
But until then (and I'm not holding my breath because the US congress is utterly, woefully, frankly perhaps intentionally, useless for both antitrust and tech regulation at the moment) I'll continue to use the first party software.
This is to help avoid having to use a bot to log all message edits+deletes, usually done to mitigate bad actors saying something bad, getting someone else to report the message or take a screenshot of it, then delete it afterwards.
https://www.nvidia.com/en-us/geforce/broadcasting/broadcast-...
xdotool search --name 'Discord.*— Mozilla Firefox' keydown F9
xdotool search --name 'Discord.*— Mozilla Firefox' keyup F9
According to some people on StackExchange (I didn't test myself) this doesn't work if you're using Discord on Chromium-based browsers, which seem to reject xdotool events unless the window is focused (which xdotool can do for you, but doesn't work for the PTT usecase). Of course, this doesn't work on Firefox when running native Wayland windows because xdotool is X-only, and ydotool doesn't work either because it emulates a virtual device which would mean you still need to focus the window.
It seems like a WebExtension using dispatchEvent could solve both these issues.
https://unix.stackexchange.com/a/87839
> It seems like a WebExtension using dispatchEvent could solve both these issues.
Great idea! Couldn't find anything any pre-existing project like that from a quick web search and tbh I have enough side projects as it is, but that would indeed solve the issue for both.
Isn't that for showing what game you're running as your status? If you turn that feature off it should stop doing that.
I think HN may have solved one of my most annoying technology mysteries... Definitely taking discord out of automatic startup. Moving back to teamspeak or some other system is quickly becoming a thing for me. I used to run a TS3 server for years.
* Persistent chat
* Multimedia chat (Emojis, resized images, etc)
* Camera streaming/game streaming (MUST HAVE these days)
Additionally, if there were "mumble multi-server management" that allowed a host to spin up other servers quickly, third-parties could skim off Discord. There is no loyalty to Discord IMO, it's just so damned easy to use.
Man, that would be pretty sweet though. Someone could cobble together an unholy Mumble + Mastodon beast of privacy-respectful gaming communications
TS3 already had a lot of features like file uploads, rich text chat, avatars, and much more, and as far as I know TS5 is mostly a reskin using the existing technology of TS3.
The stand-alone server is small, and efficient. There are countless clients that will work with it. I've run it on Linux & FreeBSD systems.
If Mumble could do streaming/video and rich text support, I think people could be peeled off Discord a tad.
But I don't know what you're talking about regarding buggy. Discord runs pretty much perfectly for me, excepting one issue (it was either Discord or Corsair Wave) that was giving fuzzy audio with a particular virtual audio input.
For how complex the server/channel/DM/text chat/"voice channel" text chat schema is, I think it's a pretty impressive product.
"Discord is worse with the app".
You might not want it, but it's not like this is unexpected behaviour. Tracking the currently running game and sharing that information with your friends is an intentional, advertised feature.
There are Discord employees on the thread so I gotta ask.. what's the justification on this one?
Shit like this makes open sourcing the client a must for me
The client is written in javascript. It's not hard to go look at the source.
Open source is about giving back users control over their own computer
This is the one that got it removed from my machine. It runs just fine in the browser so I do that. The feature I lose are ones I don't want anyways.
That's a Chrome/Chromium thing. Often, if I try to open the Nvidia control panel, it will not appear until I close Chrome. I've had something similar happen with rpcs3 (a ps3 emulator) - only with that, it wouldn't start compiling shaders until Chrome was closed. They continued just fine after reopening it.