Can't access / manage media devices via NUI (possibly intentional?)

FiveM Discussion Bug Reports
1

Previously, we could access media devices via the NUI screen. This would allow us to choose a Microphone source.

Currently, accessing these devices is prohibited and users cannot change their microphone source in game. NUI will currently use the Default Windows device as its source.

Ideally, if its intended to block access to these devices, the NUI/CEF instance would use the same one as selected in the FiveM “Voice Chat” (Input Device) panel.

Example JS call:

const activeDevices: Device[] = await navigator.mediaDevices.enumerateDevices();

Device.kind = 'audioinput' | '...'
1 Like
2

Likely a thing that’s not supported in the CEF media access handler unmerged and unreviewed trash PR that we had to already change to not crash instantly.

Unlikely to be fixed or changed at all, CEF/Chromium is a pain to work with and maintain custom patches for already, and this is a very much minority use case that isn’t worth fighting Google’s code for a day for.

It’s really suggested that you don’t rely on using a UI layer for communication purposes and instead try to report missing features, issues and make PRs for a built-in layer to do such.

3

Mumble / Native Audio is completely unusable, especially when it comes to using the filters; not to mention the constant static pops coming from mumble.

I can reproduce these issues 100% of the time within 10 minutes of a server launch; I feel like these issues would’ve been reported already? If not, let me know and I can put together more comprehensive data for you.

4

Then help fix it? Report it? PR it? What ‘static pops’? How would ‘static pops’ come from a protocol?

Also, ‘using the filters’? How are ‘the’ filters ‘unusable’?

Why are you assuming, like many others, that such is an unchangeable wall, and responding to that by rolling a weird custom solution founded in its entirety in a hack, which you then don’t share either, leaving everyone else with whatever issues you perceived and failed to report?

It’s easier to fix whatever issues had there, than to constantly monitor the 50th refactor Google does in Chromium especially once custom patches start being more elaborate, and much more rewarding as anyone can use a built-in solution and not just a few people who want to ‘write a custom WebRTC hack’.

Cool! I can’t. I don’t even have any other player to test voice bits with and have to resort to an ambient stream recorded using local audio loopback on a second client.

Other than that, I’ve not even noticed any reports about any such breakage, generally people are reporting things are ‘amazing’ and ‘working fine’ and whatnot, but as usual this seems to differ wildly across individuals: the same goes for replication/‘sync’ bugs where some people have none and others get blatant issues with 10% of the player count that others are fine with.

(yet another thing I can’t test, anyway, since I don’t run a server, don’t have access to a server, nor have access to players to play on a server)

No, I don’t know of any conclusive reports about ‘static pops’, and ‘completely unusable when it comes to using the filters’ is not a report at all but just a baseless complaint, since filters have been shown to be usable fine?

5

This is obviously a sensitive subject, but these also aren’t baseless complaints. Mumble has been unusable for almost a year, we rolled a custom solution because lack of progress made on making Mumble usable (no blame given here, just how we perceived things.)

That being said, I would love to obviously use native audio / voice by default, so I’m happy to help get all the information needed to diagnose the issues. I’m not a FiveM expert, nor an audio expert, so debugging these issues isn’t something that comes easy.

What evidence / examples of these issues can I compile? How would you like said examples presented? If you would like to see data, how can I utilize FiveM to give me the output data? I’m assuming since its an audio stream we don’t have a way of getting that data by default.

6

Lack of progress on what? Nobody even said anything was “unusable” ever. Everyone in fact has been saying it was fine, and/or only conflicting unreproducible vague concerns. Even your post history shows nothing of such sorts.

Again: I don’t run a server. I am not involved in any server on this platform, and the most I do in regards to playing on here is joining a local server (or a random public server) for 5 minutes to ensure it doesn’t crash or fail to load for other reasons. If something is broken or “unusable”, and nobody reports it, I won’t know. Even if it’s something that happens “within 10 minutes of use”, and people think “it’s so obvious anyone who even tried to use [feature] notices it, why is it not fixed yet? guess time to make a workaround/downgrade/disable whatever option”, it’s usually rather the case I don’t know said issue exists at all, or do know but haven’t gotten reproduction steps or conclusive correlations/data about said issue.

As to “data”, ideally clear reproduction steps. I’ve no clue about any other means to provide information, since I don’t know shit about this either, I’m just trying to provide something that works to the best of my ability which clearly isn’t enough, so instead people make up random other ways to do things and then blame me for not being able to get built-in functionality working fast enough when as said I have no ability to test such most the time nor know everyone’s use cases, and then only mention their issues whenever some unrelated fix affects their “random other ways” or when they feel like comparing with closed-source competition that “does do feature X” but doesn’t share anything on how they achieved that or how I can achieve that here at all, while expecting me to be a subject matter expert on literally every possible subject, have code working 110% first try, and any mistake is heavily punished with infinite rants.

At least with reproduction steps I’m able to try to figure out how to get relevant data, which is even more difficult otherwise as only a listing of symptoms is oftentimes not able to be correlated to any code at all, especially since most the time things break in game/library code with incorrect assumptions rather than actual project code here, but with reproduction steps as said I can at least hammer at something for an hour or two until I get to an issue origin rather than having to deal with a many-week feedback cycle.

7

And again: UNUSABLE IN WHAT WAY?

The only thing you mentioned is something about “static pops” apparently coming from the protocol, and “filters” being “especially bad”, neither of which are specific, actionable concerns at all.

And even then, how come various other server owners have been claiming to use the integrated Mumble client fine, a number of them with native audio filters and all, and yet it’s apparently “unusable” entirely?

Are these other server owners lying, or mistaken somehow? Are they just ignoring some small non-blocking issue that you do notice and consider inherently “unusable”?

Again, as above: I don’t know, I 100% rely on user reports because I have no environment in which to test anything in a similar way to what typical RP server owners do.

8

Bump. Could this be fixed? I’m sure a number of people would benefit from it, it’s a bit annoying to have the players change their default input device on windows to talk in-game.

9

Did you read the topic? information is needed to even start looking into this “problem”.

If you wanna help you could supply the information asked above.

10

I did read the topic and they said they won’t look into the issue because it’s a “minority use” not because information is missing about the issue. You probably are confused about the two different things being discussed here (WebRTC device listing and Mumble Issues)

11

No. As above, this is a very low-priority issue, since CEF does not support this in their media permission PR, and we’re not CEF or Google devs, it’s their responsibility to allow for device selection there, we’re not going to maintain even more complex CEF patches than we already do for maybe 2-3 users, also as it would be two days of work for no notable benefit at all to 99%+ of users and complicate any future CEF updates.

No ‘bumping’ will change this decision, you can implement it and get it merged either in CEF (or our fork, once you get it working in cefclient) yourself if you feel it’s so important though.

1 Like