111–120 of 130 posts
Earlier quoted context omitted.
Something wrong with simply using RNNoise?
mmm, https://github.com/jitsi/rnnoise-wasm looks like it might help. wonder if jitsi actually uses it.
With Audio Worklets or insertable streams, however, it should be possible to apply it to the stream im real time, though we haven’t tried it yet.
Earlier quoted context omitted.
The competitive gap with Discord in terms of media quality is probably something like: * Need a low-latency SFU. This should be very doable; not only are there a lot of good FOSS SFUs to build on top of these days, the history of the Matrix team is actually that we built VoIP stacks fulltime before we shifted focus to Matrix, and we've built MCUs and media servers of all flavours in the past. MSC3401 should also give…
Can you at least let us know what "stacks" anyone involved has produced? last I checked nobody involved has ever been involved in real voice platforms (as evidenced by 8 years of "voice first" but actually producing very little actual voice integration)
Unfortunately the IP was all proprietary and owned by the company, and when WebRTC stole our lunch we shifted focus to messaging and building Matrix, and have slowly returned focus to VoIP - hence Element Call.
This is really cool. I really feel like this ecosystem is hitting its stride. The list of upcoming features is long and sometimes I don't understand how they can have so many things going on at once. Features tend to take a few years to mature, but that is not a bad thing. I will be setting up my own server shortly, something that I have been thinking about for a while and maybe try to develop something. Congrats to…
Slightly off topic: I really like the idea of Matrix/Element, but I’ve found I can’t rely on it. In three instances, I’ve had a long-running chats stop working completely and simply not load. All history/media inaccessible. Just a loading spinner. This is Element on iOS. I wish it were more dependable, because things like this would excite me much more.
Seperately, we wre also experimenting with a full rewrite of the iOS app on top of matrix-rust-sdk called Element X, which whould provide a much better and faster codebase to try to avoid this sort of thing in future.
Earlier quoted context omitted.
> I wonder if this setup can be leveraged to create a Twitch-like streaming solution based on Matrix. Yes, we've built it with this in mind. There are three possible approaches: * You can broadcast a headless client via HLS or RTMP, similar to how Jibri works for Jitsi, and how we broadcast FOSDEM ( https://matrix.org/blog/2021/02/15/how-we-hosted-fosdem-2021... ). Basically you run a headless Chrome against a virtua…
> If there are two, then folks will pick the one with the lowest latency. No it needs to be deterministic. "Just picking the lowest latency node" would result in sync failures i.e. not everybody hearing the same thing.
Earlier quoted context omitted.
So in the initial beta we haven't turned on E2EE, purely because it will make it way harder to debug any problems which surface. However, at this rate, things are looking pretty stable and i'd expect us to enable it in the next few weeks. It uses normal Matrix E2EE, which means a Double Ratchet between the pairs of devices participating in a given conversation, which is then used to secure the signalling which is use…
Will E2EE be on by default?
Slightly off topic: I really like the idea of Matrix/Element, but I’ve found I can’t rely on it. In three instances, I’ve had a long-running chats stop working completely and simply not load. All history/media inaccessible. Just a loading spinner. This is Element on iOS. I wish it were more dependable, because things like this would excite me much more.
We have had some fairly nightmarish bugs on iOS thanks to how iOS changed push notifications a while back, meaning that you end up with a tiny client in the push extension trying to independently sync and decrypt e2ee traffic which was at risk of clashing with the main app and causing problems. I think I know the bug you are describing, and it was fixed several months ago - as of the current build the spinner should…
I wish I could update my parent comment. Although this interaction speaks for itself I think. Thanks for a great product!
I feel if XMPP just had some better tools this push for Matrix would be unnecessary.
If IRC had some better tools then the push for XMPP would be unnecessary. In fact, why didn't we just build IM on top of email? Turns out its much much easier to start from scratch with the right ideas than to transform an existing protocol in to something usable and convince everyone else and update all software to match. "The market" has decided that Matrix works well and XMPP doesn't. If it made sense to fix XMPP…
Earlier quoted context omitted.
> If there are two, then folks will pick the one with the lowest latency. No it needs to be deterministic. "Just picking the lowest latency node" would result in sync failures i.e. not everybody hearing the same thing.
Mixed sync +/- 100ms of latency or whatever is probably fine, for most purposes? If you really want everyone to be centralised on a single SFU then you’d set the permissions on the room appropriately.