Just wondering, can I have fullband stereo sound to play music?
Native Matrix VoIP with Element Call
51–60 of 130 posts
Re: Native Matrix VoIP with Element Call
#52Earlier quoted context omitted.
Tauri + Electron (or Hydrogen) provides a lightweight cross-platform Matrix client that doesn't rely on Electron... Meanwhile, Nheko, NeoChat, Fractal and others provide very usable lightweight native cross-platform Matrix clients too. Element is also working on its own experiments (TBA) based on matrix-rust-sdk.
Calling Fractal usable is maybe a bit of a stretch, but there are a lot of really good Matrix clients now!
Fractal-next is looking very usable (thanks to leveraging matrix-rust-sdk as its engine), tbh.
Re: Native Matrix VoIP with Element Call
#53Just wondering, can I have fullband stereo sound to play music?
The media quality that you hear is entirely up to the sender's WebRTC implementation. If you're calling another Element Call user, we currently use the default audio constraints when capturing audio: https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732b... - but if you wanted stereo, you could put { channelCount: 2, sampleRate: 48000 } or whatever into that line to achieve it.
I'll file a bug to make this configurable.
Re: Native Matrix VoIP with Element Call
#54Earlier quoted context omitted.
Could you give some insights on how you estimate the amount of effort of making Element Call competitive, performance-wise, with say Discord. I heard that Discord threw a lot of time and money at optimizing voice in their product. Can you just jump in and realistically compete? There are a lot of performance/latency/sound quality comparisons online of Mumble vs TeamSpeak vs Discord and recently Jitsi vs MS Teams vs Z…
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…
Very insightful! I'll have a look at the links. Thanks for answering.
Re: Native Matrix VoIP with Element Call
#55great post, animation helps a bunch too.
wondering if ip addys are exposed to the other users like with webrtc and if so, could we force conencts to be only through coturn to hide the ips?
Also wonder if there will be a warning for such, especially of encryption is turned on - some may think they are truly anonymous, and where ips are exposed of course that's not true.
Also wonder about moderation, hopefully this does not become a target for the sickening trolls soon - but moderation needs will be coming, so who gets the ip logs to consider blocking? homeserver runners?
I expect the future will need whitelists/blocklists subscription options for clients at some point.
Re: Native Matrix VoIP with Element Call
#56My only concern is does this expose your IP to participants? This is one benefit of Discord Voice channels vs Discord Calls (which are end to end but expose your IP to everyone on the call, and theirs to you, so much so, you just open a console log and you can see them all...).
Re: Native Matrix VoIP with Element Call
#57> We’re also working with the Tauri core team to provide cross-platform lightweight desktop apps as soon as possible! How about a lightweight cross-platform Matrix client that doesn't rely on Electron?
Tauri + Electron (or Hydrogen) provides a lightweight cross-platform Matrix client that doesn't rely on Electron... Meanwhile, Nheko, NeoChat, Fractal and others provide very usable lightweight native cross-platform Matrix clients too. Element is also working on its own experiments (TBA) based on matrix-rust-sdk.
i think you meant Tauri + Element
Re: Native Matrix VoIP with Element Call
#58> And, the big one drum roll, please ... we will be integrating this into Element so you can have voice and video rooms, and hold group video calls inside the Element app natively over Matrix. I'd love to replace my teamspeak server with this. Discord is tempting, but I'd rather host it myself.
Mumble works great for me in the meantime
Re: Native Matrix VoIP with Element Call
#59great post, animation helps a bunch too. wondering if ip addys are exposed to the other users like with webrtc and if so, could we force conencts to be only through coturn to hide the ips? Also wonder if there will be a warning for such, especially of encryption is turned on - some may think they are truly anonymous, and where ips are exposed of course that's not true. Also wonder about moderation, hopefully this doe…
Currently we don't force TURN, so in practice this means that voice packets go direct between the clients if possible, and so the IP addresses of the clients are necessarily exposed to each other.
However, this is utterly trivial to fix: matrix-js-sdk already exposes https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732b... and we simply haven't exposed it as a setting in Element Call yet. I've filed a bug for it at https://github.com/vector-im/element-call/issues/251 - thanks for bringing it up!
In terms of moderation: this is no different to moderation in Matrix as a whole, where we're already busy working on shared greylists (MSC2313 and friends) - https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix... has more details at the end.
Re: Native Matrix VoIP with Element Call
#60Earlier quoted context omitted.
Yup, the grandparent post is a misunderstanding. Basically, we want Element Call to work with a single click to a URL without requiring any account - much as Jitsi and similar do. Therefore it needs to pick a default homeserver. Currently it doesn't play well with existing Matrix accounts (as it will sync in loads of chatrooms which are irrelevant when you just want to do a call), so for expedience we just create acc…
I guess I still don't understand it. (And my apologies for coming across like I was trying to pick a fight) What does it mean that I can currently use it with my existing homeserver? The architectures for some of these federated systems can be difficult to understand, I feel like I didn't really understand what _Matrix_ was until I tried running my own homeserver.
Federated systems tend to have different client and server implementations that can work in all combinations (as long as both are spec compliant).
The confusing part comes into play when the client implementation is a web app that you can use to log in to any server hosted anywhere. Because of how centralized services work, we are used to a paradigm where the website you visit hosts its own backend - you cannot choose. With these federated systems, on the other hand, you can go to website element.foo.com and log in at matrix.bar.com.
The blog post was saying they limited the option to log into your homeserver at matrix.bar.com (because of the reasons outlined above). This does not, however, stop you from hosting their (FOSS) app at call.bar.com and pointing it to your homeserver at matrix.bar.com