I wonder why no open source program (that I'm aware of) has ever tried to tackle the reason of 's primacy as a chat app: multi-user, real-time screen-sharing **with audio only from the shared window**.

The "Go Live" feature is I think the most compelling reason to use as voice chat, since it opens up many, many activities that aren't easily available elsewhere, such as:
- watching a friend play a videogame (it's just not the same thing without audio or with a delay)
- watching movies together
- giving technical support and having immediate feedback
- and so on

I'd love to see that supported on Call, for example!

@steffo, I understand that screen-sharing with audio only from the shared window is nice to have at application level (it’s traditionally done via JACK or Pulse sink, which is not exactly user friendly), but I don’t see how it is necessary in most setup, given the streamer is unlikely to listen to multiple sources at once.

Watching a friend play a videogame (with both game audio and voice): This is doable on BigBlueButton AFAICT. It’s unlikely to be real-time unless you have really good connection, e.g. Owncast could drop a lot of frames if you choose to keep up. The video and audio are sync’ed in time though.
Watching movies together: The same, but please don’t do this. It’s a waste of home bandwidth and an atrocity to the video quality due to recompression. Plan your download together or upload it to a server.
Giving technical support and having immediate feedback: This is just normal screen sharing? Again, there’s no magical solution to the delay, you either skip frames, reduce quality or get a better connection. BTW I did pair programming through Jitsi and a few hundred millisecond delay didn’t bother me at all. The reality rarely matters, the average Discord user who proclaims himself a proponent of free software is just looking for excuses to keep using Discord.

@tyil That's not how you get people to actually use free software, though. If you truly wanted to use free software for your needs, you could've done so a long time ago. I can't really take anyone seriously that proclaims to want free software, then uses #Discord for chat, with so many free alternatives just waiting to be used. Rather than bowing to a proprietary service, you could try to improve existing free software platforms if you honestly think they don't cut it as a chat application.

@tyil I'm not sure of what you're trying to tell me...?

@cnx I agree with most of you say, but a non-technical person who just wants to do these things without having learn a thousand new programs will definitely not.

@cnx I'll tell you the results of some experimentation I've done to see if it was possible to get some friends to switch:

@cnx has at best ~7 seconds of latency and at worst up to ~50, which are definitely too much to talk about what's happening in real time.

Is any better?
I've only seen it used for some of my university lessons, so I don't know its capabilities.

@cnx About movies: I *definitely* agree, I've been recommending <> to everyone I know, but for non-technical people sometimes finding the video file to watch may prove to be complicated.

@cnx My third example was a pretty bad one, so please disregard it... (I probably shouldn't post at 5 AM...)

@steffo, BigBlueButton’s latency is around a few hundred ms. I was wrong about the audio though, you do need to create a loop back device, e.g. with pw-loopback on Pipewire.

@steffo ... Discord only got that semirecently. That is NOT why Discord is popular.

@pixelherodev It's not why it's popular, but it's definitely one of the main reasons for its user lock-in.

@pixelherodev I don't think it's a coincidence that 's competitor rushed to implement audio in screen-sharing.

@steffo Is it? Is it really?

That lock in existed for *years* beforehand. That screen sharing may have *enhanced* their lock-in, but it cannot be a core reason for it.

@pixelherodev Why it cannot? It's an essential feature that no other applications provide.

@steffo Causation.

If A exists from time T onwards, and B exists from T+10 onwards, then B *cannot* have caused A, because A preceded B.

That is to say, the lockin existed *before* screenshare of any kind. Ergo, screenshare is *not* a root cause of the lockin.

It may have made the lockin *stronger*. It may *become* the sole factor which maintains it. But if we assume it's the sole factor, we'll probably miss the real original causes, and make faulty assumptions about how to compete with them.

@pixelherodev It's a good point, but keep in mind that many people started using Discord after screenshare was implemented, so for them it may be the cause: your A event (an user joining Discord) would be therefore placed after your B event (screenshare being implemented).

@steffo What percentage of users joined after screenshare was added?

@pixelherodev "Go Live" was released on August 2019, so, using Google Trends as a source, I'd say around 70%.

It's definitely too few data to imply that's the single cause, but that's on me, as I should've worded my original toot better, saying that "it's one of the main causes".

Like I said earlier <>, it was a 5 AM "random thought" post, so it wasn't that much specific 😅

@steffo okay, except Google Trends is not a reliable source :P

@AAMfP Seems to be more of a chat application, than a voice application.

I don't think it even has screen-sharing natively, but I might be mistaken.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.