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.
Can you have a look on how the web ui does the typing indicator animation?
I really need an engineer to know what is happening there, why is it animating an svg in the dom by looping in Javascript, instead of just using a gif?
This is destroying the battery by pegging a cpu core on firefox.
At least this has been the case last time I checked. And there is no way to disable the animation.
I mean, that's what it sounds like when reading the headline. Card not reaching full speed under <condition> is an issue with the card. Impaired performance could be from <condition> occupying it, but that's not what it says (it sounds like clock scaling or something). That you've been investigating this for Nvidia is very nice of you!
My immediate thought was "Oh it's hardware acceleration must be using up/reserving resources" which is decently common especially among chromium/electron based programs.
Discord has a large contingent of gamers among its users who expect to be able to use discord to communicate while gaming, so even if this isn't Discord's fault it's in their interest to look into it and facilitate a solution
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
Either way, it looks like it's Discord's problem when it isn't
> 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.
> the process of probing the GPU for what codecs it supports
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.
I agree with your statement, but I understand why you'd want to probe. It's cross-platform, and it's more reliable... (unless you run into a driver bug).
The function you linked to queries the registry, and that on its own can be invalid information. How does that info get there?
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 also why Hades has been lagging, dropping frames, and running at a much lower framerate for months while Discord app DMs (and only DMs) are open?
Nvidia promises to give you your frames back, but they will be triple buffered and may be replaced during runtime with newer frames. Render now while supplies last!
Discord can definitely do some strange things to your machine. I can't play DayZ when it's open, the game will not connect to any servers and errors out with this "player auth login state" message. I thought it was my internet connection but running a server locally also resulted in the same error.
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.
My friend group started using Discord during the pandemic to continue our previously-in-person RPG sessions.
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.
Seriously. More users than Slack, and I assume 99% of them are on a free plan too. Their engineering blog talks about some of the problems they deal with at that scale, impressive stuff:
I made that comment about the worst software engineering in the context of this discussion, which is about the frontend. If discord had good fronted software engineering, it wouldn't be as bloated. With good software engineering you can make even web/electron apps fairly lightweight (compare Atom with VS Code).
Video playback is low power primarily because GPUs (even embedded ones) have dedicated hardware for video decoding. Video chat requires also encoding video, which not all gpus provide hardware for. CPU encoding video is a very energy intensive task especially as the resolution increases.
A macbook with a built-in webcam doesn't provide robust and low-power hardware encoding for video that camera captures? I should see battery life plummet if I use Quicktime to record video through it, then... right? There shouldn't exist battery efficient screencast apps for these computers... right?
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.
Good points. You have successfully made me revisit my assumptions!
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.
I was unable to find answers to these in ~1h of googling. Would love it if someone here knows.
Doesn't every consumer AMD/nVidia GPU and every consumer Intel CPU (as long as it has integrated graphics) made in the last 10 years have hardware accelerated H.264 encoding?
I think intel quicksync also has that(random green screen) sometimes. The only one not suffered from it is amd hardware encoding. But the encode quality is worse than the other two. Sometimes to the point that I want to just disable it.
Video games have optimized rendering pipelines and assets.
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.
Of course they have control over it, it’s literally their own platform. There’s no reason that Discord can’t benefit from the same optimizations that video games use. If a AAA title can figure out how to render 100000+ polygons UV wrapped with several 4K resolution textures in the span of 16 ms, then a $15B valued company can certainly figure out to display emojis and large images without turning your notebook into a DIY stovetop.
I assume Discord is built with electron. That should answer all your questions. Personally i dont use web apps on desktop..use discord in browser never had any issues
The worst software engineering? Have you met Teams? The flagship chat application from the world’s biggest software company, which is often unable to send chat messages
So, second worst is better, then? Btw the Teams product is not a "chat solution", but a workspace collaboration tool; chat is just a small part of it. And now I feel dirty from defending the steaming pile of garbage that is Teams :)
It's basically IRC with an enormous amount of bloat tacked on. Every time it upgrades - which is obnoxiously often - it'll have some new feature they want to force on me and I have to click on a popup to dismiss it so that I can do what I intended when I started it. And they've started injecting their politics into it too, which you'll see on startup now and then.
The mobile app is sitting in my "notification jail" folder three pages deep too, where apps that abuse badge notifications are kept.
I like it how it goes straight to "touch grass" when someone has a slightly different belief to someone else. Of course it must be unreasonable if they disagree with me!
Nope. Sorry. Your personal politics and opinions can be objectively, morally, ethically, legally, and practically wrong. On the topic of "woke" content, e.g. rainbows, gay representation, black history, etc., being against people being allowed to express themselves in ways that affirm themselves in ways that are best for the mental health and well-being, being allowed to love whomever they love without fear of legal or moral backlash, teach the true history of a people including the icky parts that certain demographics would prefer to keep hidden from the sunlight, and exposing the injustices of this country from a historical and contemporary context, IS morally, ethically, objectively, practically, and hopefully someday sooner rather than later legally wrong.
Your opinion, thank fucking god, does not matter. It's not "groupthink", insofar as all we are are just people who agree that treating human beings with basic dignity regardless of their social or racial standing isn't groupthink, just common fucking sense and what a decent person should do at the barest of minimums. And if you oppose that, guess what? You're on the wrong side of history, society, and progress. IF you don't like it, you're free to leave. But we're not going anywhere, so try not to cut yourself while seething at our existence.
Also make sure you subscribe to Discord Nitro, so you can upload longer clips of you talking to your camera in the cab of your 2017 Ford F150 Superduty wearing wraparound shades.
Flamewar comments like you posted to this thread (and elsewhere, unfortunately) will get you banned here, regardless of how wrong someone else is or you feel they are.
Also, nope sorry ;), I didnt say anything about whatever nonsense you're talking about. I simply stated that its about providing space for discussion and evidence, all that rant crazy is on you.
Interesting that asking for open discussion with supporting evidence pushes so many buttons for you.
Thanks for the input though. I feel like that we each have a responsibility to call out unreasonable comments when we see it. I hope you all do this when it counts and not just when it's easy.
The phrase "call out" is a bit of a red flag on HN because it's associated with flamewar, aggression, and online drama culture. You can make a substantive, thoughtful point showing how someone else is wrong without resorting to "calling out" or shaming.
It's not about cutting corners. It's about time to effect change. It's about cross device and platform support. It's about it being easier to find developers familiar with the browser stack then native app developer.
That being said I would love to have less memory allocation on my devices when effectively idle too.
The aspects you mention mostly make things easier for the developer side, not for the user side, which get only the indirect advantage of a more feature rich app.
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.
Most of this is false. Ripcord achieves near-feature-parity with the official Discord and Slack apps using cross-platform desktop technologies with a fraction of the resource usage with a single developer.
Ripcord's very existence contradicts most of the claims you've made above.
You can also just look at how many developers it took to build similar programs, native and cross-platform, in, say, the 90s and early 00s. I wouldn't be surprised if a bunch of them had smaller teams for all platforms combined than Discord has for its single desktop client. Yet one would hope we've gotten more efficient at software development since then, and the entire excuse for using things like Electron is supposed to be that it saves a whole bunch of developer hours—but then you look at how tiny teams were on some of even the fairly-big programs back then, and all our "more-correct" processes and technologies start to look pretty damn suspect.
I only ever used it for small GUIs for some scientific computing I did back in college, so maybe it's hard to use for larger projects, but the impression that I remember of Qt was that it had a pretty large component library, extensive documentation, and a drag-and-drop WYSIWYG UI editor!
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
Yeah, I think you guys are right. It's like the history of vitamin C and scurvy on ships. We seem to have collectively lost some very obvious and straightforward knowledge
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
>It's about time to effect change. It's about cross device and platform support. It's about it being easier to find developers familiar with the browser stack then native app developer.
One might consider these as cutting corners - hiring web developers to build an app that really should be native
Anything that injects DLLs and hooks into lib functions will have this effect on unstable software that was not written with a comprehensive understanding of how the majority of Windows programs operate. It's not Discord's fault that they are using the APIs provided to them by Microsoft fairly, legally, cleanly and non-intrusively and not everyone supports them.
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
>and I have a strong distaste for the kinds of social circles that it breeds
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.
Can you recommend any interesting groups? I use Discord all the time, but in my experience it's all just noob programmers, cryptocurrency people, gamers, and troglodytes. (What it says about me that I'm in these groups, I'll leave as an exercise to the reader)
If I had to guess I’d say discord attaches to the dayz executable to show the discord overlay in-game and the dayz anti cheat doesn’t like it when processes get attached to the game because that’s how cheats work and doesn’t let you auth into the online game.
Sounds like a port issue. I imagine the first thing most people did was list the ports in use when either app was running. Did the investigation end at finding the culprit or did they figure out the actual cause?
They never figured out the actual mechanism involved, just that running Discord caused the connection issue, and that when Discord wasn't running, they could connect to a server and play the game.
Does dayz use DRM? My first thought is that they've got a false positive in their lie detector rather than that the Discord client somehow reaches into dayz and causes it to give "authentication state" errors.
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).
I’m the opposite. If there is a well written app on iOS or iPadOS, I’ll use it for the increased privacy protections, lower battery and CPU usage and (sometimes) lower bandwidth consumption.
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.
> The web has tracking everywhere and often uses a lot of CPU, memory, battery, and bandwidth.
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.
Webapps have better privacy protections than native. Battery/cpu is a tossup depending on the app. With the example above of chat apps I've found that the webapps use less cpu/memory.
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.
A well written native app should use less battery and CPU than a well written web app. Lots of native apps are not well written though and, like Gruber said, many are just a wrapper around a web view showing their website.
Native code should be able to do more work with less power, yes. But in practice, these kinds of runtime efficiencies aren't the overarching factor. Native apps add features and these features in aggregate end up using far more memory, cpu, and being otherwise invasive into the system -- for example, the discord native app attempting to ptrace everything else on the system.
The extra crap -- especially information gathering -- ends up making the native apps slower and buggier.
I can use uBlock on the web, I can't do that on iOS. I'm fairly confident that it gives me more privacy than what I can get on iOS. It's much easier for me to get a vague idea what a webapp is tracking and what it's doing. You can see all the network requests, you can disable javascript, disable access to certain APIs etc.
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.
Of the two major mobile OSes, one is literally owned by an ad company and the other is increasingly succumbing to the dark side of advertising. Why would I trust Apple not to do nefarious things with all the tracking they do ("privacy" my ass) when I could just use a browser with an adblocker and do even better?
(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.)
> I’ll use it for the increased privacy protections
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.
> I simply won't use a dedicated app for anything that can be done in a web browser.
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?
> The only things I can come up with are apps requiring access to outside hardware or files
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.
I believe the discord app has some weird limitations around global shortcuts and push-to-talk when you use the browser tab instead of the desktop app.
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.
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.
Discord optimizes streaming your gameplay by injecting DLLs into your game when you go to stream it (I discovered this, and the setting to disable it, after trying to figure out how the hell Puzzle Pirates could crash due to being streamed). I would be very. Very, very surprised to learn a website could do that. Hell, any streaming of whatever separate application you're running seems like it shouldn't be possible from a website.
If you'd rather use a native application, I can recommend Ripcord[1]. Ripcord is an alternative client. Unfortunately, the developer doesn't seem to make many sales, so some features are not implemented.
The demo has infinite days, but it's a good idea to actually donate if you like the project :)
Is that tweet ripcord related? The original tweet to which discord is responding is deleted.
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.
Interesting. I discovered just the other night that merely minimizing Discord nets me about a 20 FPS improvement in Factorio. (Even if Discord is otherwise off-screen, which it normally is, as Factorio is fullscreen, and there's no second monitor for me.)
I'd like to assume that too, frankly. But I actually think it's slightly more complex. I've got CPU time to spare, as it is, and Factorio gets a solid 60 UPS. (I.e., the game simulation proceeds without lag¹.) It's the FPS that isn't there, and I think it's mostly constrained on GPU time…? But I'm really not entirely sure where the bottleneck is. (I also don't think the NVIDIA reports Discord as being on the GPU, too, so … IDK. 20 FPS is a stark, hard to miss difference.)
Same on my ArchLinux setup with RTX 2080 SUPER and nvidia drivers, Factorio at some point starts limiting to 30 fps (from 60), alt tab doesn't help, minimize/maximize too, but the moment I kill discord from the tray everything gets back to normal, the same in some other games I can't recall now
Not really. It just has to draw what's on the screen, which for an average base is estimable. Whether that's 40 to 60 or 140 to 160 fps doesn't really matter: it's a significant difference and I think probably absolute if you know how many flops or whatever you need per frame at a certain graphics settings level.
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.
I really have a love hate relationship with discord and I feel like it is a prime example of an application that should be "simple" but just seems far more complicated than it should be.
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.
Discord is a fucking bitch.. Find Something interesting, you have to join some Discord to find all the information. So you join the Discord and then you have 100s of channels with chat.. Try to find the information, need a role, I give up. It's almost angering me how terrible this program is, seeing so many people use it. It currently is being abused.
Please use Discord for chat, but don't use it as your main platform, please! Rant over.
> So you join the Discord and then you have 100s of channels with chat.. Try to find the information, need a role, I give up.
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.
It's absolutely great for moderators and server owners though. Also color coding user names is surprisingly good to enrich communication on public channels. I guess that goes for personalisation in general but think is simple and very effective. Channel separation and hiding and other permissions are doing great service to reduce clutter, it's a trade off I guess.
I can't believe in this day and age there are still solutions like this. This is reminiscent of having to manually set IRQ settings to get games to play properly and is one of the reasons I stopped using Windows decades ago. This is giving me PTSD flashbacks.
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.
I must be having a hard time waking up today, or something, because I can’t wrap my brain around why a chat app would need 3D acceleration.
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 can’t wrap my brain around why a chat app would need 3D acceleration.
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.
Streaming functionality isn’t chat, though. AMD gives you the option to not install streaming functionality when you install their drivers and I’m pretty sure they target gamers too.
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.
Discord is not a "chat app". That's a pretty narrow view on how it is both used and vended. It's a communications app, at a minimum, and people use it for audio, video, chat, events, and a bunch of other stuff that may require hardware acceleration.
You’re the person who has decided that discord is a “chat app”. Discord themselves say:
Discord was started to solve a big problem: how to communicate with friends around the world while playing games online.[1]
It’s not too much of a stretch to see that they would see streaming as a logical part of their core functionality as a result.
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.
Video and game streaming is one of its core features.
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.
The microkernel would like a word with you, good sir. As would the Unix toolchain, the Google suite, iWork, and Microsoft Office. If it was modular, you wouldn’t need separate apps per se.
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.
There are many problems with discord, and GPU is not the worst one.
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.
>> blocking other programs using desktop integration for file dialogs: latency of several minutes, sometimes dialogs never appear.
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.
Mumble is probably the best VOIP solution on the market. The main issue blocking its wider adoption, IMO, is the lack of support for persistent, multi-media friendly, text chat. I've suspected for a while that Discord could be totally replaced by someone duct-taping Mumble and some forum software together.
Same. I've thought about what Mumble needs to be competitive at all in the market.
* 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.
Discord's biggest sell is being able to spin up your own "server" for zero effort and for free. Some kind of federated Mumble that people could rent servers from (or join their own self-hosted servers to) would be able to eat into some of Discord's market share but the free hosting is a huge draw ro Discord.
TeamSpeak 5 is currently in beta and attempts to bring a Discord-like experience to any TeamSpeak server.
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.
> Discord tries to track which other programs you run by default and shares it.
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.
I wouldn't mind this feature so much if it were optional. However, while it's possible to disable the sharing of the information, as far as I'm aware the only way to stop Discord from being able to probe the running processes (so it can display them in the corner to the user) is to run it in a web browser. As such, the desktop apps do not get to run on my machines.
One sticking point for people might be the way push-to-talk works for the in-browser version; the shortcut to trigger it will only work when you have the browser window focused (I think due to limitations in how browsers can capture inputs when not focused, which is a pretty reasonable policy in general). Not only does this mean you'd need to alt-tab over whenever you want to push to talk (which isn't super easy for a lot of potential use cases, like gaming), but if I remember correctly from trying this out once, you can have even more jarring bugs like "alt-tab over to the browser to hit push-to-talk shortcut, hit the shortcut, alt-tab back before releasing so you can keep talking, and then having the push to talk never deactivate because the browser didn't detect the key-up event due to a different window having focus when it happened".
On Linux, I just tested that if you have a Mozilla Firefox window running on X (I tested on XWayland but it should work just as well on X11) with the Discord tab in view, you can use your desktop's/compositor global keyboard shortcut functionality to call xdotool to send a keyup/keydown event without focusing the window, like this:
xdotool search --name 'Discord.*— Mozilla Firefox' keydown F9
xdotool search --name 'Discord.*— Mozilla Firefox' keyup F9
I configured web Discord to use F9 as the push to talk button since it seemingly doesn't conflict with anything in Firefox, but you can then bind it to any key or mouse button on your global keyboard shortcut settings.
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.
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.
Oh wow, that's super interesting! In retrospect it's super clear that muting and unmuting the microphone system-wide will pretty much always work, since it's incredibly unlikely someone would need to have input on between push-to-talk activations, but for whatever reason, it never occurred to me. I use a cheap USB foot pedal to avoid needing to manage holding down the button while trying to do stuff in-game, and I'm realizing now how obvious it is that making it just toggle mute/unmute on each press rather than needing to hold down my foot would be _way_ more convenient!
I keep trying to use ripcord, but the reality is a workplace expects you to be able to jump on board everynewfeature that Slack adds within moments of it's release. Whether that be huddles, threads, recordings, etc.
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.
1st party support is (sadly) usually the best experience you're going to get.
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 a real question: what are Slack huddles supposed to do? I run the native client. While anyone can start a huddle with me, I never see any UI for a huddle. All I get is the audio coming across. To end the huddle I have to force stop Slack and relaunch it.
What should be happening is a small window opens at the bottom of the left sidebar (under your channels/direct messages/apps)
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 really like them. No need to invite people to a meeting; just jump in. E.g. if you have an issue to diagnose as a group you can just stay on the line, and dip in and out where necessary.
In Teams you can just call the first person up and then add more people into the call. "Jane Doe is calling you from a group chat" or whatever it says. I'm surprised this is a new-ish feature in Slack?
It's hard to explain. You're in a channel already, e.g. your team's channel, and you hit a toggle and it creates a voice chat and others are notified to join. I think it's really slick.
Teams has that too, you can call groups, or teams, people can pop in and out at will.
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.
I know what you mean - we had Teams at my past place. Difference is Teams UI is intrusive, which might suit command and control style orgs. Huddles are much less intrusive. You can do regular calls with Slack as well, Teams-style, but huddles are much slicker IMO.
> 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.
That's not the TOS. That's a 3 year old tweet with multiple people in the replies asking to cite where in the TOS it says that, and no further reply from the official account.
Ah, I didn't really read the ToS, but contemplated a third party client a while ago, and was told I best avoid them due to ToS violations. I guess it must've spread through that tweet.
Reddit is one of the most difficult sites online to use as a new user. Virtually no subreddits allow new account to post. There are often waiting periods of a month for new accounts and large karma requirements that are difficult to get, because once again subs won’t let you post.
I would love to use Ripcord but I can't find any information on noise suppression/voice focus and that's a requirement for me as I play without push to talk and on mouse and keyboard so all those key presses get sent through to those in my channel. With the 1st party app, despite other issues, none of my key presses come through for people in my channel.
If you have an Nvida card you could use Nvidia broadcast. It runs as a virtual microphone that other apps can target as the voice input. So Nvidia broadcast will receive the raw input from your real microphone, process it, and feed it to any applications that are targeting the Nvidia broadcast mic as their voice input. It also doesn't appear to add any noticeable latency.
Ripcord will temporarily remember deleted messages for channels in which you're a moderator. You can view the contents by right-clicking on the message. It won't do this if you aren't a moderator in that channel.
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.
Me and my friends started using discord early in its life. It was a joy to get away from Skype, google meet, etc. It was such an elegant solution. Sadly it has become a gigantic, bloated, buggy mess trying to do absolutely everything. I hate it. Can anyone recommend a better solution?
I used to use Mumble. I still think decentralized, encrypted chat is great. But there is nothing like Discord for free.
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.
To pile on (somewhat). I've been enjoying using discord for the chat features. We just have one channel that I use with long-time friends to chat. Recently, we started playing games together (cross play), and Voice Chat _usually_ doesn't work well on the Xbox. I'm not sure if it's an Xbox or Discord issue though, as I'm the only PC gamer and don't have access to an Xbox to debug it :-)
We went wrong with Electron in particular: https://www.electronjs.org/. I am convinced this framework alone is responsible for more performance loss on the desktop than any other single thing.
Agreed and I’d go a step further and say that this was inevitable with the advent of JavaScript.
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++.
Alright so I gotta ask, now that two people are saying they yarn for the days of IRC. I thought maybe it was a different idiom I was missing, but searching for "idiom yarn for" doesn't get me anywhere. Just a typo/misspelling of "yearn"?
That seems like the exception that proves the rule to me. If every electron application is a bloated CPU/memory hog that ignores the OS conventions, save the one with major corporate resources backing it, that tells me that making electron apps not suck is out of the reach of most developers, and such a thing is probably inherent to the framework.
Also it's important to note that MS makes bit only the best performing electron app (VSCode) but also the worst (Teams). So even with MS' billions it's not guaranteed to become a quality product.
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.
It's able to share one instance of the browser engine across multiple apps (the way that Chrome is able to share one instance across multiple web pages). It'll help some, but won't make up for whatever the hell react is doing all the time.
You are probably right. But at the same time, there are a bunch of good desktop apps that would not exist without electron (or at least not in the way we know them today).
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
My suspicions that some Windows app or another is using Electron under the hood are usually confirmed when I eventually click the app launcher icon and no window appears and I look in the task manager and see like 20 processes of that app running in the background but something is blocking new UI instances from displaying any UI until I go and kill all the headless zombie instances of the app running in the background with no UI attached.
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.
I don't knit, but none of those do what Discord does, really: effective group chat + in game voice. Skype is sort of is in that direction, but Discord's UX nails it for in-game chat whereas Skype's did not. (Though it has been a while since I ran Skype for more than "oh, that's the only medium that party supports? I guess if we have to…")
I do feel that these apps these days, Discord included, eat a ton of resources, and that it feels like a regression.
They ran fine on machines a hell of a lot weaker than that. If you had an actually-good desktop OS (uh, BeOS is the only example I know of—Linux, at the time, couldn't do this, even with minimalist window managers) you could even browse the web, have chat open, and be playing mp3s, and not hear so much as a pop or skip on the music, on a 166MHz Pentium (that's a single core, kiddos) with 128MB (luxury!) of memory.
I used to be able to do that on my 25MHz Amiga with 10MB of RAM. Static absolute task priority scheduling is actually a very good way to ensure your MP3 will play without stuttering.
Some of those more-obscure operating systems simply felt like magic. Refresh a webpage on Windows or Linux, mp3 you're playing pops and skips about half the time. Mouse just seemingly-randomly becomes unresponsive. BeOS on the same machine? Hard to load the system enough that playback isn't smooth, and input was only rarely anything other than instant-feeling. Closest I've seen to that recently is iOS, but it cheats by suspending or evicting backgrounded programs.
... 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.
> Refresh a webpage on Windows or Linux, mp3 you're playing pops and skips about half the time.
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.
To be fair to Windows, it didn't take much more powerful hardware before that problem went away—the mp3 stuttering, anyway, UI lag/unresponsiveness is still struggling to match BeOS on ~every major OS, today. Was all Win98 for me in that era, maybe XP and such improved it (I don't think I ever tried to run it on anything that weak)
Linux could do that fine. Not sure why it couldn't for you but with similar hardware in the mid to late '90s I was able to listen to mp3s, browse the web, and chat on IRC at the same time with no issues.
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!
I meant the pre-Microsoft Skype. That one was magic.
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(!).
Skype was always a bloated mess. My gaming/friend group started off with it, but between the hard cutoff at 8? 16? people in a call, Skype taking up approximately half of our typically 4 GB of RAM, and people discovering you could crash people's clients by sending them several GB of ;) emoticons which, when rendered into smiley images, would overwhelm most anybody's computer, we ended up switching to Mumble, where we discovered something else Skype had sucked at: audio quality. Mumble took less bandwidth and less system resources, while sounding like someone actually sitting in the room with you (at least to our phone-and-skype adjusted ears).
I beg to differ and strongly disagree. Pre-Microsoft Skype was a genius invention and performed admirably for the time (~2005) considering how limited PC specs and bandwidth were back then.
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(!).
hmm. My experience with it was ~2010-ish? Mumble came out in 2005, too. Can't say for certain when we switch to Mumble, but it looks like they've had some codex changes over time.
Couldn't you do that by just scanning `px aux` or even just `/proc` rather than running a tool that is meant for observing and control the execution of other processes? A simple name matching should be enough, rather than digging into the execution of the process itself.
Well, they have equivalent functionality I assume where you can get a list of process names that are currently running, without having to resort to using ptrace?
* blocking other programs using desktop integration for file dialogs: latency of several minutes, sometimes dialogs never appear.
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.
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.