Over the past three weeks I've tried a few different conferencing solutions, including jitsi. I'll give it another try with this update.
My use case is I take weekly music lessons, and now they are virtual. The problem is the DSP done on audio was designed for speech. If my teacher is explaining something then plays an example on his bass, it usually sounds terrible, maybe even inaudible.
I send him pre-recorded mp3s of cover songs; ideally he could listen to it and I could comment in real time about places where things could be improved. Instead, if he is playing any music on his system, I hear nothing -- no music, no talk. It seems like the software thinks "Hey, this participant is listening to non-conference audio, so I'll just mute him (at least on skype). I'd love there to be a half duplex audio button so none of the DSP shenanigans are needed, and a high quality audio stream would be sent.
Firstly, thanks for your work on what is really a great project. Can we set stereo=1 in the SDP and also the bandwidth constraint? That would make it ideal for this use case.
For music quality webRTC you need 3 things: disable audio processing, stereo=1 in the SDP and a way to limit bandwidth usage so it doesn't saturate the available bandwidth and create errors.
Disabling video is also really the best thing to do when recording for this reason (bandwidth saturation), and also Chromium will give you much superior experience. Safari and Firefox isn't quite there yet: Safari can't let you choose your output device and lacks some other useful features, and Firefox doesn't yet seem to allow stereo Opus, maybe that's changed since I tested. Microsoft Edge is now Chromium so you're good to go.
Firefox has supported stereo opus for a very long time (four years at least?). We know it works, it's used by medical professionals for their job and they wrote a message a few month thanking us for this feature, that doesn't seem to work on other browser (according to them, but I see tickets open on chromium).
Of course all the chain has to be stereo, that goes without saying: input signal is stereo, negotiation has been done in stereo, having enough bandwidth is important (otherwise opus goes mono), and then playback has to be on stereo hardware (but that's the easy part).
We hold regular flute meetings and play together. In this quarantine time we wanted to meet online, but if we play all at once, it seems I cannot hear everyone else at the same time. I guess it is as if everyone was shouting over everyone else, which is not the case when you have a meeting where usually only one person speaks at a time
Will this also fix this issue? So everyone will be able to hear everyone?
You won't be able to play together because of latency.
You will think you are in time with someone, but you will react when you hear/see them on your screen, which is maybe .15 seconds after they actually made the sound/movement. And then they will hear/see your reaction .15 seconds later again.
If all participants have good internet and are geographically close it should theoretically be possible to have delay not much greater than rtt/2 for everybody.
With rtt < 20ms that should make musical performances possible. After all, sound only travels less than four meters in 10ms. So this is just like singing in a choir (with more visual delay - but that can be solved by having a conductor).
Unfortunately I'm not aware of any software making that a practical reality, even with ftth.
You're assuming that network latency is the only latency that's involved here, but a huge latency source is the audio codec. Opus adds ~20ms latency, and that's the most low latency codec that's widely supported at the moment. You can see a comparison here: https://www.opus-codec.org/comparison/
There are all sorts of other latency that need to be taken into consideration too, and unfortunately in practice those do add up to live music being unplayable on pretty much any network.
There's a really interesting project called NINJAM https://www.cockos.com/ninjam/ which is designed for live music jam sessions. It flips this fundamental constraint on its head - instead of being real-time, it streams everyone else's output delayed by one bar (theoretically any interval >RTT I guess?). I haven't tried it, but it's a really cool idea.
Of course there's a ton of other potential sources of delay that make my fantasy hard to achieve, probably already starting at the typical USB microphones (in headsets/cameras).
20ms rtt through e.g. opus on a loopback network interface is already decidedly non-trivial to archive with "normal" hardware. When you do have low-latency devices, it becomes easy, but not everyone has those.
Musicians building digital audio workstations commonly have to replace the whole software stack to get audio latency down to an acceptable (<10ms) level: JACK instead of PulseAudio, a Linux kernel recompiled with custom options for low latency, other software reconfigured to use the JACK APIs, and so on. Sometimes they can't use whatever standard audio hardware. (And remember that USB polling frequency is normally only 100 Hz: 10 ms worst-case by itself.)
Minimizing latency is certainly technically feasible, it's just hard for stupid reasons.
I haven't tried it yet, but sofasession.com seems optimized for this. Using wired Ethernet instead of WiFi can go a long way, from what I've heard. Has anyone here tried it?
Depends on the type of music, something slow and choral can easily deal with high latencies, while something quick, rhythmic and precise can't be harder to deal with.
Has anyone tried Mumble for this? It's very low latency but I can't find exactly how low the latency is. It ofcourse depends also on your internet connection and other settings but the base latency that comes from buffering the sound before sending. Mumble also has lots of settings for sound quality and different sound formats so might work for music if you try all the settings.
Mumble has a setting for the audio buffer size and in fact they make you set it during initial configuration. It works great, has low latency and doesn't use much bandwidth (I hosted a server on a 1Mbps DSL connection for several people back in the days).
Latency is not that big problem I'd say. We play a music where it does not matter that much, sometimes just playing one long tone for the length of everyone's breath.
I just would like to hear everybody at the same time, but what I hear is always one person's sound getting preference over others. Or sounds just alternate randomly based on the volume, I'd guess.
Musicians already deal with that kind of issue when doing particular kinds of performance (e.g. famously at Wagner's festival opera house, where the orchestra is in a deep pit below the singers).
That's not how it works. In fact there are multiple algorithms depending on the browser, it's not defined in the spec. The most used one currently would be AEC3 from Google, which is quite a bit more advanced than what you describe.
If the website doesn't want to offer a control to switch this on/off, I'm confident this can be done by a browser extension in no time (which would have the benefit to work for all websites).
padenot, although I am a programmer of sorts, I don't do web development, so I'm at a loss. Say I go to the jitsi website (https://meet.jit.si/), type in my four word passcode, and get a conference connection with my teacher. When you say, "instead of doing..." doesn't apply to me, because I don't do anything. It sounds like what you are describing is what the developer of that web page needs to do, but me, as a user, doesn't see any of that.
Audio processing is a risky move -- so hard to get right. We've been using https://team.video at work, and one thing I absolutely love about it is how they handle audio / muting.
When you're speaking, you don't have to wonder if others can hear you because your microphone pulses in green visually as you speak. If your audio isn't working it shows in yellow with no pulsing, and you and everyone else can see your audio is not flowing.
Also, if someone else forgot to mute and their kid is making a ruckus, you can just mute them. You don't have to wait for a moment to interject and ask them verbally, you can just go ahead and do it.
Or, when you see someone else in their video feed trying to speak up, but they forgot to unmute, you just unmute them. No everyone saying, "you're muted" over each other.
It takes a second to get used to the idea that everyone has all the power, but in practice it just makes everything go way smoother.
It's only scary in the same way that it's scary how anyone walking down the street could kick you in the pants when you're walking down the street.
They could but they won't because we live in a society. Which is great because that means we don't have to walk around in steel suits to avoid getting kicked in the pants.
I choose to trust the people I work with every day. And then as a bonus, I don't have to hear people yelling "you're muted!" at one another. We just get on with it.
No. If you mute yourself you are distancing yourself from a conversation. Unmuting someone is like following them secretly on the street into their house and listening in on them standing behind their curtain. It is creepy and wrong and shouldn't be possible. Maybe they are having a fight with their spouse? You shouldn't be able to listen in on someone who muted themselves without them aknowledging it
The only legitimate use case I see for this is if you are working with e.g. elderly people who have a hard time understanding the whole thing and even then it shouldn't be possible without them clicking on "Yes" explicitly.
The difference there is that kicking people on the street lands you in jail (likely not the first time, but if you do it repeatedly...), and remote unmuting would likely require wiretap laws in unconvenctional ways to even get a judgment of whether it's illegal or not (not even considering what it brings with it).
Also, you're implying that one would only use this technology to communicate with people you work with every day. What about a meeting with outsiders/contractors/customers? You might not actually have those yourself, but someone usually has to do those.
I know we're getting far from the original point here, but I'm going to seize this opportunity anyway: the so-called "thin blue line" is not the reason society is able to function. We work as a collective /despite/ the presence of police and the prison industrial complex, not /because/ of them.
Exactly. In the case of a video call with your colleagues, everyone collectively manages mute states so that the group can be more productive.
Then, if one asshole starts unmuting maliciously, they get shunned real quick and then fired if they keep it up. We don't need to limit ourselves with draconian measures when social norms and expectations will already suffice.
This is why I was so opposed to Zoom when my company started adopting it a few years ago: the room dictator or whatever it's called can unmute you. (Maybe only if they had muted you in the first place.)
Here's something that a colleague passed along to a group of CS profs.
It's written by a music professor and geared toward using Zoom for music, but several of us Zoom newbies found it to be helpful more generally. He mentions the issue of disabling the speech-centric audio postprocessing.
Disclaimer: The author apparently makes his money selling eBooks, so you may want to skip through the several pages of promotional material at the beginning of his PDF to get to the good stuff.
Use TeamTalk[1]. If you need high audio quality, TT beats everything else you can find, maybe except very expensive software for radio stations. I've successfully used it to stream music and it works.
It's Teamspeak and Discord like, so you need to connect to a server, either public or self-hosted, join or create a channel, and then you will be able to talk to everyone on that channel. This is perfect for permanent communities where people just hang out, but works for one-offs too. It works on Windows, Linux, Mac, iOS and Android, no web access. The server is also available for Raspberry Pi. Half of it is open-source, but the core SDK needs a license if you're developing with it. The program itself is free, even for commercial use.
It uses Opus and lets you adjust the quality and processing, so you can get a lot out of it. We've been using it in our community for about 10 years now, including for radio broadcasting, and we haven't managed to find anything better since. I know of one local radio station and recording studio who successfully use it for remote work now.
To get the best experience, disable all audio processing in the preferences, on the sound system pane, so duplex mode, automatic gain control and noise reduction should be off. If you're on Windows, use Windows Audio Session as the backend for lowest latency.
Then, connect to a server, I use the German one for public stuff, as I'm close to it geographically and you don't need to register for it, but use whichever you want. After connecting, create a channel with application set to music, bitrate set to 150000 and channels set to stereo. Those are, at least, the parameters I use, and they work great. You can adjust the rest as you see fit.
There are some video and screensharing capabilities as far as I know, but I haven't used them. Audio is definitely the primary focus. If you need any assistance, my username here at gmail dot com is the way to go.
[1] bearware.dk for desktop, App Store and Google Play for iOS and Android.
ps. I'm not affiliated with the company in any way, it's just a tool I use daily and would recommend to anyone who knows his way around the computer. It definitely doesn't pass the grandma test, though.
"High"-bitrate lossy CBR compression is probably acceptable enough — at least compared with a voice codec! mp3 at max (320) is only 320 kB/s, doesn't have the security issues that variable-bitrate compression does, and preserves audio "ok" (it does delete the high frequencies above 20-22 kHz). No patent issues anymore, either.
Ogg-Vorbis may be an even better option for all kinds of reasons, but mp3 is more universally recognized.
Awesome! I've been wondering how to do this, since I normally take calls in a quiet room with headphones, so there's no need for noise canceling. It would be nice if you could enable this on a per-call basis, though.
I work for a company that builds virtual classrooms based on webrtc. Our customers are mostly business schools, but we have some music schools. For them we activate a different profile that disables all audio processing and selects the music profile of opus (opus are in fact 2 different codecs, one aimed at speech, one aimed at music). It would likely be very easy to do something like this in jitsi meet as well, since webrtc has everything onboard. The tricky part is that you also need to disable echo cancellation. So everyone must be wearing headsets and so on.
This sounds really cool! What’s the company? (I also work on WebRTC-based classrooms, at Minerva - we haven’t looked outside of voice in the audio sphere though.)
For this use case, you need selective fidelity and shared control over a sampler, with each sample having low resolution video, high quality audio and an arbitrary number of tags or notations (with a time range).
Yes, but it is entirely unsuitable for real-time conversations. The only thing it works for is modal jams or something like 12 bar blues that loop the same fixed chord structure over and over.
I want to like Jitsi, but I can't. I've been testing it out on a variety of servers, bare-metal and cloud with Debian and CentOS. Regardless of platform, it doesn't scale, it eats memory like peanuts, and can saturate even 10GbE network connections. The service, as opposed to the server, clearly works well. But, the service doesn't have anything like the load that Zoom, Teams, Hangouts, etc. must deal with.
I've been helping quite a few people set up Jitsi lately. The software works reasonably well, although documentation is lacking and a lot of configuration options are named terribly, but one thing I've noticed is people's expectations about bandwidth usage are way lower than actuality, especially outbound from the server. But a bit of napkin math suggests that Jitsi isn't doing anything fundamentally inefficient here; one high-res stream plus N low-res streams transmitted to N participants is just a lot of bandwidth.
This is so very true. We have been monitoring the bandwidth, CPU and mempools of our small Jitsi Meet instance living on an ESXi VM on a Mac Mini. We notice that 3-4 participants typically consume 5-7mbps downstream to the server and about 5mbps upstream from the server while CPU usage stay in the 15-20% range. The bandwidth scales fairly quickly with the number of participants, especially on phone type devices.
There are a few of things to be aware of when deploying your own instance in jitsi-meet/config.js:
Firefox simulcast is still experimental (edit: and disabled by default), so Firefox is only sending HD to the video-bridge and no LD stream. The HD is then relayed to everyone even as a thumbnail.
If you don't need to see everyone's video all the time, set channelLastN: 5 or a similar number, and only the last N speakers video will be broadcast
If you don't need 720p (1280x720), change the constraints: video section to be something like 360p (640x360)
Enable layer suspension so that HD is not sent to the server when not needed: enableLayerSuspension: true
I haven't tried this at scale, but was pleased with 6 participants on my $200 r710 hardware with 10megabits upload connection service. Memory usage is minimal, couple GB tops. Not running high-res, but was good enough. I mean they develop this and make it freely available for self-host, I'm pleased.
It could be worth reporting some feedback to them directly, if you haven't already?
They're quite responsive on GitHub ( https://github.com/jitsi/jitsi-meet ) and I'm sure additional details regarding any bottlenecks would be appreciated.
Identifying even modest improvements now could result in large memory and bandwidth resource savings over the next few weeks and months.
I've been running multiple deployments of it on Azure, on VMs with as low as 1 core/2 GB. I literally set it up every few days from scratch using https://github.com/rcarmo/azure-ubuntu-jitsi
For my use case (around 10-15 friends, for informal meet-ups) it has worked spectacularly well.
I hesitated to go through the hassle of setting this up because I was worried such a low-end VM wouldn’t be able to handle ~10 users.
Sounds like any of the $5/month VMs from the likes of DO, Linode, etc should handle this. Luckily there is a small hoster with a data center near me with similar specs/price. Their free offering on AWS works fine but it would be nice to get lower latency and have my own domain.
Why is that? Is each of the participants audio/video going over the server so that you need p^2 bandwidth? Are there cool P2P tricks they are/could be using?
I've been wondering about videoconferencing scale, since Zoom seems to have handled a huge explosion in usage very well. Are they just very good at autoscaling AWS instances, or do they use cool tricks to reduce bandwidth?
The server is receiving 1 stream per participant, and forwarding that stream to all other participants. So for say 10 participants, that's 10 inbound and 90 outbound.
If you switched to p2p instead, then each participant would need to send 10 streams instead of 1, and most people's upload bandwidth is much lower than their download (at least in the US).
It's possible for the server to make decisions on which video streams to forward (e.g. last x talkers) to reduce the number of outbound streams, but switching streams takes a bit of time (you'll need to get a new iframe from the just-switched-on participant) which affects the interactivity of the session.
Modern video codecs also allow for layering of into progressive levels of enhancement, so lower detail versions of the stream can be forwarded to participants will lower bandwidth without the server needing to transcode anything. (Not sure if Jitsi has implemented anything like that.)
Couldn't the server compose the streams itself? Perhaps as simple as tiling them all together and the client can manage that stream, or request single high quality streams if needed.
There'd be a CPU/bandwidth tradeoff being made here, I wonder how the prices on standard cloud providers would compare.
Sure, but that adds a lot of CPU load server side (and cloud CPU is still fairly expensive), adds latency for the extra buffering, decoding, and re-encoding, and limits the display options available client-side.
WebRTC should be capable of multicast, so nobody should be having to send X-1 streams for X users. I say should because it's incredibly hard to find out which parts the the WebRTC spec browsers actually implement. I just found an article from Mozilla from 2018 that just blithely mentions in passing some nebulous future date "when WebRTC is (hopefully) enhanced to support multi-user conversations." WTF have I been doing with more than 2 people in a WebRTC session for the last 5 years? What the hell has been going on in WebRTC for the last 9!?
What is you setup look like ? If you have largely 1:1 meetings you can enable p2p mode only , video will directly be shared between users. I have had no problems delivering 100-150 concurrent sessions at ~1 Gbps per bridge, beyond that we usually cluster the bridge ( Octo is out of the box solution jitsi uses for this)
Video stream, especially if it a group setting is always expensive. I can’t understand why people have such high expectations for video conferencing. This is the reason why Zoom and Microsoft Teams is killing it: video conferencing is inherently difficult and not a trivial task.
When I tried Jitsi with my family friends, some of them struggled to use it since they don't know English.
So I think changing the language can be easier for nonspeakers of English.
For example, language select box can be placed next to "Go" button (when creating meeting) and next to info button in the meeting.
Also using "Accept-Language" HTTP header for choosing the language can be a good default.
Another option is to add a language query parameter to the URL so that host can easily share meeting with a particular language.
Also if it would be great if some improvements can be made for low bandwitdh since there are people with slow connections and limited data plans.
(On the other hand, there is already an option to lower video quality).
Other than that, kudos to Jitsi team for their great efforts and this great project.
I've trialed several video conferencing apps in the last few weeks (Skype, Zoom, Hangouts and others), Jitsi Meet is the only one I've been able to have a video call on with my low-bandwidth, high-ping network. They've done a superb job for my use-case, I'm very happy with the result.
I see nothing in the specification that specifically mentions encryption. Are there any concerns about performance of in-JS streaming encryption? Does the encoder/decoder take promises and are they expected to use the subtle crypto APIs in the browser which return promises?
No, because the specification is more general than that. The specification is about being able to add a input/output transform step, so you can add encryption on top of WebRTC streams, via this new API.
JavaScript encryption/decryption seems to work fine for the most basic use cases, but if you have many streams you need to do encryption/decryption for you, you probably want to use native browser APIs for it or WebAssembly.
Right, I understand it's more general, but there is a use cases section in the explainer that putting this there might have value.
In other cases where encryption is used (e.g. fetch, webrtc itself, etc), often we ask the browser to do it due to, among other things, the performance benefit of not doing it in JS or WASM. I'd have to test using window.crypto.subtle.encrypt or tweetnacl something to check the overhead (I do see the webcodec examples show a write/readable stream which allows promise-based encryption). Arguably this could have been done at the conn level w/ raw RTC data instead of the media stream level so I wouldn't have to handle data channels separately, but I see the value in sharing with other use cases of client-side stream manip.
Apple has proven with previous actions and non-investments in the web platform that they are not interested in contributing to something like that and would rather focus on their own proprietary services/applications. Right now, they seem to be doing the bare minimum to not receive too much criticism from developers who are stuck on Apple devices.
I hadn't seen that before, thanks for sharing. First question: "Does Apple permit iPhone users to uninstall Safari? If yes, please describe the steps a user would need to take in order to do so. If no, please explain why not"
Apple answers that users cannot, and adds:
"The App Store provides Apple’s users with access to third party apps, including web browsers. Browsers such as Chrome, Firefox, Microsoft Edge and others are available for users to download"
While forgetting to mention that all "Apple's policies require all iOS apps that browse the web to use the iOS built-in iOS WebKit-based rendering framework and WebKit JavaScript" [https://developer.apple.com/app-store/review/guidelines/], effectively meaning it's just a skin on top of WebKit, which is controlled by Apple.
I wish something good comes out of that investigation, but realistically, I don't see it happening.
Seems like a straightforward retread of U.S. v. Microsoft.
1. Can you delete Safari on iOS?
No, but the "App Store provides Apple’s users with access to third party apps, including web browsers."
2. Can you set a third-party browser as the default browser?
No.
3. How about for opening links in bundled apps?
No, see questions 1 and 2.
4. Okay, so can these third-party browsers include their own rendering engine?
No, because "Apple can provide security updates to all our users quickly and accurately, no matter which browser they decide to download from the App Store."
5. What if a third-party browser introduced better security/privacy features?
See question 4 and it's "not our experience that competing web browsers have typically offered enhanced privacy or security that would protect users as adequately as our WebKit protections."
6. What features does Apple cut off to third-party browsers?
* WebRTC
* Service Workers
* Intelligent Tracking Protection
* Fullscreen API
I am so happy Jitsi exists. My friends and I have a room that we regularly pop into to say hi or play games together.
The mobile app I downloaded through F-Droid works incredibly well, and for those of you Firefox users who aren't having the best experience, I recommend using the Electron desktop app [https://github.com/jitsi/jitsi-meet-electron/releases].
I've been using the Jitsi Electron app in conjunction with OBS + the VirtualCam plugin to share games, videos and my desktop. Hopefully I can convert more Zoom users.
Random fact: the 'Big Buck Bunny'[1] short film that the presenter shares during the screen-and-audio-sharing demo was made by the Blender Foundation[2], an organization that develops open and free content creation tools.
I want to like jitsi, but have yet to use it without participants in the meeting having issues. It doesn't remember hardware selection, so if the default hardware is incorrect, you have to change it every time. Often people arent able to see video, or hear audio. If people aren't using headsets, then the audio from their speaker loops and causes feedback. Its always been painful for everyone. But everyone else seems to love it, so what am I doing wrong? (Running in gcp, fwiw)
I just did a quick test using latest Jitsi meet running in Chrome and it does remember my external webcam settings (saved to browser localStorage). Looping audio is something that happens on alternative platforms too, so I'm not sure that's a fair criticism of Jitsi.
I hope this crisis causes Jitsi to get some serious funding. I've been trying Jitsi on and off for about 6 years and it's never been this good. It also could be a lot better.
I agree. I've been just waiting for a use case for jitsi (the woes of social tools, is there is no use if there is no remote party willing) for years. I love when open source options are valid options.
After all the zoom privacy/security nightmare stuff, we've started looking at alternatives, but we have a set of features we need that either aren't in Jitsi or we couldn't figure them out. So in the mean time we've been stuck with zoom.
* breakout rooms
* annotations on screenshare (being able to draw on the presenter's screen)
* something other than dropbox for exporting recordings
There may be other shortcomings, but we'd be willing to "downgrade" except for these that leave management going "well, i guess we'll just deal with the security issues of zoom rather than lose features"
Just to offer a counter point: this crisis feels mostly manufactured. Zoom is under a microscope that almost all other comm software would fail just as horribly, if not worse. Maybe the majority of users here were too young to remember, but Skype was far, far worse, and did not have same positive response and seriousness Zoom seems to be having.
That said, competition and alternatives is good!
I disagree that this feels manufactured. It's due to a catalyst - one that has brought on a lot of positive and negative attention to Zoom. The evidence is all there and it is factual. Zoom has misrepresented their encryption on both the implementation and operational sides. However to say that only the bad press Zoom has received is "manufactured" is a misrepresentation.
I'm not sure I follow the Skype comparison. If you're talking about Skype historically (and it seems you are) - then that was before a lot of the strong privacy and encryption conversations were being had in the larger audience of consumers. Setting this comparison is a slippery slope. Yes, we know Skype was used and abused by nation state actors - but for the time encryption was not the norm. Things have changed and today misrepresenting encryption and privacy is a much more grave sin that consumers are more concerned about. Businesses lying or misrepresenting it should have been held accountable back then - but they only finally are now.
> Things have changed and today misrepresenting encryption and privacy is a much more grave sin that consumers are more concerned about.
Not disagreeing but I think we have to remember that 99% of consumers are not HN tech gurus and really don’t care. They only care about the quality of the product/experience, and clearly Zoom has topped the market on those (similar to slack for enterprise chat).
Consumers, in my opinion, have a much more vested interest in privacy and security today. If we look at Apple [0][1] - they've invested significantly in wrapping their brand around it. To say that "99% of consumers are not HN tech gurus and really don't care" seems, to me, an unfounded perspective. Again, in my opinion - but factually we have a lot of evidence to support the contrary.
> then that was before a lot of the strong privacy and encryption conversations were being had in the larger audience of consumers
That is an extremely. weak defense. There were plenty of other companies taking user security seriously. Many of our encryption standards and security certifications in use today were created in the 90s and 00s.
Defense? I think you misread what I stated. Sure, many encryption standards and certifications were created in the 90s and 00s. That doesn't mean all of them stood the test of time - lest we hash out if your perspective is that 3DES is still viable. What I stated was in response to the parent and pointing out, as you quoted:
> "If you're talking about Skype historically (and it seems you are) - then that was before a lot of the strong privacy and encryption conversations were being had in the larger audience of consumers."
Note that I was speaking of "consumers" for the point in time referenced. Many of those consumers were not aware of why they should care about privacy or encryption, you seem to be conflating industry and consumers - of which I was making a much more specific point. This point is obvious when you look at the trend of total encrypted traffic volume which was not the majority in the 90s or 2000s compared to today - of which it is. For reference (and to put this in perspective) Facebook didn't start rolling out required encryption until 2012 [0] - less than 10 years ago. Today most of us couldn't fathom logging into a service that wasn't encrypted. So, while I feel you took my statement out of context - I'm also pointing out that consumer encryption wasn't generally taken seriously in consumer oriented services until into the 2010s.
Signal went under a microscope during a critical time (Snowden leaks) and not only succeeded but changed how everyone else was doing it or at least set a new bar. Which then proceeded to help hundreds of millions of people as apps like WhatsApp adopted their crypto.
If major plays like WhtatsApp being capable of figuring it out and adopting it with hundreds of millions of users, then I fully believe any-sized company can where it won't kill their business model.
It doesn't need to be a part of Zoom's business model to watch everything so there's no excuse not to. And after that people will stop bringing this up every time their brand is named.
Not sure it was quite flawless, but it has gone from being my first-choice platform to last place. I fear that LinkedIn is going down a similar path, post-acquisition.
Yeah no. Skype was certainly good at the time, but compared to discord, slack, hangouts, or pretty much any contemporary chat app/suite, it didn't stand up.
Also as another user mentioned, skype was a DOS vector for individual users.
A number of Internet personalities such as Twitch streamers were doxxed with a little help from Skype IPs. Maybe impossible to avoid without centralized hubs or an overlay network like Tor.
It is curious how Skype was started by Kazaa engineers basically to find a legit use for their p2p streaming tech, and now it's not even p2p anymore.
> Just to offer a counter point: this crisis feels mostly manufactured. Zoom is under a microscope that almost all other comm software would fail just as horribly, if not worse
I fail to see why this matters; let's assume this is true and everything else is just as bad (and a lot of stuff is just as bad, so this may be a fair assumption): the answer is that they should be put under the microscope too and forced to clean up their act and stop lying to users or putting them at risk unnecessarily with bad development processes. The answer is not to just say "meh, everyone else is just as bad" and keep using Zoom.
If all other communication software will fail just as horribly under the same scrutiny, then it’s fine. With the quarantine, we definitely have the time to make something better.
I have seen it only on Microsoft Teams. Google Meets doesn't seem to have this feature. But maybe the availability depends on the browser/OS combination?
The two alerts that I’ve seen on Jitsi recently that really impressed me were: no signal from your mic for a while when you’re unmuted (I had mine hardware muted so this was expected) and background noise from your mic. I use Google Meet regularly for work and I wish it had both of those.
Awesome new feature! That's exactly what I'm going to use it for, though I am just a tad sad that it happened before my setup game night, as I felt like a wizard using pulseaudio to route the game audio through as a microphone...
Seems a decent bunch of improvements; sharing system audio is apparently a useful feature (I don't care, but I see it mentioned enough), and device and muting changes are nice usability improvements.
Agreed. Glad they're adding things at this kind of reasonable pace.
In the linux philosophy there are other things that can do the audio sharing (like Pulseaudio loopback modules) but I guess no one should have to learn those in order to use the simple feature in this tool.
The best thing about Jitsi IMHO is that it scales so well. After having problems with Nextcloud Talk, I just wrote a chat bot that returns Jitsi links (see my GitHub if you’re interested) et voilà 100+ people in one conference!
Wow. I keep reading that it doesn't scale to those numbers well but it sounds like you have a different experience? Do you enforce participants to use Chromium-based browsers?
They also ask for translations at the bottom of the release notes. It's a bit unusual though that most of the time the translation project on weblate is locked, but i haven't seen any vandalism
Nice to hear about the simplified device chooser, I used Jitsi a few days ago for the first time for a family call and I lost like 2 minutes to realize where to change the mic input.
I started using this (for https://virtualcoffeebreak.app) but in the end had to switch to daily.co - the jitsi support for mobile devices is a bit painful and doesn't work so well.
The mobile iframe is quite jarring and doesn't provide that nice user experience; for example it doesn't detect if the app is already installed or not.
Having to download an app increases the barrier compared to other solutions.
The banner complaining about not using google chrome (or derivative) is immensely annoying.
I am using it on firefox and it works anyway, but now my mom is being forced to use it for work and she's asking whether there are any problems (there aren't).
they should just take it away already, it's working well anyway.
There are known issues with Firefox clients causing deteriorated quality for all users. They're working on it, but current workarounds are use Chromium, a chromium based browser, or the desktop app.
This is not true, the whole conference performs significantly worse at much higher bandwidth usage if there is a Firefox client, due to implementation limitations.
Their documentations and many other places state that Firefox uses roughly 2x the amount of resources, so I think it's worth pointing that to the user if they are having resource issues.
Hi, I think there could be some synergies between what I'm working on and what you are doing. Couldn't find a way to contact you other than Twitter or LinkedIn, if you want to have a talk my email is in my profile :)
Sandstorm.io community members host weekly meetings on Jitsi and have for a few months. It's not perfect, but it works and it's open source, and that's great. I will say the audio on a computer is a bit hit and miss, I often opt to dial in with my phone instead, which works pretty solidly.
A really nice perk is that you can have your room name URL, and the dial in number is the same for that URL, so if you reuse the same "room", you can just know the meeting ID and all, which I haven't really seen from other solutions.
I'm surprised nobody has mentioned how complicated it is to add authentication to Jitsi meet. I ended up following a guide I found on their website it wasn't trivial.
Wish the next update can improve further the blur background function, right now it consumes quite a lot CPU cycles, and is not supported on the mobile apps.
Does anyone know how their releases correspond to version numbers? It looks like they are possibly releasing multiple times a day, or maybe using releases and tags in a non-standard way. https://github.com/jitsi/jitsi-meet/releases
Not sure I completely understand it, but Jenkins is apparently auto-tagging things (maybe every commit that passes tests?). I think their actual releases have "stable" in the tag and release name, so "current" is "stable/jitsi-meet_4384".
4384 matches the latest versions I'm seeing for Ubuntu and Debian at https://jitsi.org/downloads/ under "Jitsi Desktop stable build line". For some reason other OSes seem to be much further behind.
I’ve been using Jitsi for a couple of weeks and my experience has been pretty good so far.
Got a quick question if someone can answer. Is is some how possible to use OBS stream with Jitsi? For my use case, I work with an one MS-Excel window capture & my webcam input capture in the corner, to explain some concepts to my students.
I'm impressed with Jitsi, it all works pretty well. The only thing i noticed, compared to some of the proprietary solutions, is that my laptop got pretty hot because of CPU usage. I wonder if they're doing anything about that for the next release.
Jitsi simply forwards the video streams between users, whereas some proprietary services seem to re-encode everything into a single stream. So in a large conference each client might have to deal with decoding dozens of high-resolution streams. This is probably very difficult to solve without reducing video quality.
I wonder if there is anything published about meet.jit.si's use, traffic and costs (as well as scaling issues, solutions)? I imagine that it all of these have increased a lot over the last weeks, and it's pretty impressive that the entirely free and non-monetized (AFAICT) service has remained up and without problems (AFAIK).
#/media/File:Opus_quality_comparison_colorblind_compatible.svg){kind=link}
My use case is I take weekly music lessons, and now they are virtual. The problem is the DSP done on audio was designed for speech. If my teacher is explaining something then plays an example on his bass, it usually sounds terrible, maybe even inaudible.
I send him pre-recorded mp3s of cover songs; ideally he could listen to it and I could comment in real time about places where things could be improved. Instead, if he is playing any music on his system, I hear nothing -- no music, no talk. It seems like the software thinks "Hey, this participant is listening to non-conference audio, so I'll just mute him (at least on skype). I'd love there to be a half duplex audio button so none of the DSP shenanigans are needed, and a high quality audio stream would be sent.