Initial minor issues - not sure if normal? #81
Comments
|
An update to the part about the high quantum: It turns out I am able to get it to behave properly with the low quantum, but in doing so I have highlighted an issue. The scenario is that, in order to test this, I was sharing from firefox, and had a copy of chromium running discord to watch my stream from firefox. Obviously, I would be able to hear the stream coming direct from firefox, as well as hearing it in chrome, so I disconnected the firefox playback stream from the sink which feeds to my sound card, leaving it only connected to the pipewire-streamaudio virtual device. I think it's relevant to mention, that the streams are always 5.1 due to my config, and this addon is only linking the FL and FR channels to the screenaudio sink - so there's a problem there. It really needs a 6 channel capture, downmixed it to 2 channel output for discord to play over WebRTC. Anyway, I discovered by accident that if I left the stream connected to my output sink (another virtual loopback device, part of a chain of virtual devices before the sound card device itself) then the audio stream coming from chrome was fine. So it wasn't the small quantum that was the issue causing the broken-up audio - although a larger quantum did let me 'get away with' disconnecting the stream from the 5.1 sink, the larger quantum wasn't actually necessary - provided that I gave the source stream somewhere else to sink to, in addition to the pipewire-streamaudio device. I did try linking all 6 streams of the firefox source, to the stereo screenaudio sink, but it still stuttered. |
|
Hello @pallaswept, thank you for your time troubleshooting these issues.
It would be best to track 2, 3 and 6 in separate issues. For the rest, 1 is already tracked on #80 (as said), 4 will be fixed in React and 5 will be added to the README. KR |
Thank you for your help and the awesome addon! It's nice to not be forced to use chromium for sharing any more 🙂
It's ready now :) I updated the other issue with details. I just didn't want to drop the package until I was sure these issues weren't a package problem, so it was a bit late... but it's good to go now!
That surprises me given that you've created this addon! For someone who claims not to be an expert you've sure done an outstanding job.
I agree. It's just a loopback module like any other, really. I think this is a case of the client dropping out because it can't find a complete sink (same sort of thing happens just watching a youtube video or whatever and disconnecting it, the video will freeze). I suspect this will be solved with # 6, but in a real-world situation where I'm monitoring the sound on my speakers and the 'listening end' is someone else's computer, it won't be a real problem anyway.
I actually don't have any accounts elsewhere, but I do need to get around to creating one (for other reasons, live chat to help out a pipewire user) so I'll check this out. I thought to try it with the multi-process console and caught an error when clicking the button - until I click it four times fast and it just works for no apparent reason. I'll put that in a new issue.
👍
👍
👍
You got it, thanks for your advice, and once again, thanks for the awesome addon! |
|
Oops, forgot to close it! |
Apologies for the further delay in getting the OpenSUSE package out. I had it 'working' for some time, but wanted to test it further as I did have some issues, and I wanted to make sure it was my system and the package was really OK.... but I've had it working flawlessly (NICE!) so I'm satisfied that this package should be fine to release.
As for the problems I had:
Pipewire quantum:
I found it was not compatible with the small (128/48000) pipewire quantum I usually configure for Firefox, and I needed to relax the timings significantly. Maybe you'll have better luck than I, but I couldn't get it to run properly with less than a 480/48000 (10ms) quantum which it selected by default, but I normally override it. and because I stick to powers-of-2 quanta, that means going up to 512/48000. Your mileage may vary, but if you find it working but the receiving end is cutting in and out, and you don't see any xruns (ERR column in
pw-top) and you manually modify Firefox's quantum, this will be why. Stock pipewire installations should not suffer from this, their default quanta are well within the safe range.Starting the share:
I found that the screen sharing was a little difficult to trigger. When you first click the 'Share your Screen' button in Discord, you will be prompted for permission to use a "microphone" - this is the pipewire-screenaudio virtual device, so be sure to pick that out of the list if it is not pre-selected - you don't want to actually select your microphone here. That should be allowed when you first join a voice channel. If you tick the "Remember this decision" checkbox, then it won't prompt you in future - but nor will it prompt you for permission to use your normal mic, so keep that in mind.
After this prompt to allow the 'microphone', or if you did tick the "Remember this decision" checkbox then immediately upon pressing the "Share your Screen" button, you should be prompted to select which screen to share. With this Firefox extension addon installed, that seems not to happen. I expect this is either a Firefox or KDE or discord bug of some sort, triggered by this add-on, but not an actual bug with this addon. The solution is not exactly scientific, but it is what it is: clicking several times quickly (a double-double click seems to do the trick every time or by clicking and holding, then releasing and quickly clicking again....but clicking fast seems to be the most effective way. Trouble is, you don't want to click too fast, or you'll miss the permission prompt. I recommend the double-double-click approach.
Brief false error message:
In a brand-new Firefox profile, I did not suffer this, but in my normal profile, when I open the application popup to select an audio stream to share, I see for a fraction of a second, an error message stating that "The native connector is misconfigured or missing!". This disappears so quickly I had to try like 10 times to be so fast as to press the key to screenshot it, and then everything works just fine. It looks like so, just for a that brief moment. There's nothing wrong with the connector or its configuration (as you will see when you get it working) so again, I suspect this is a Firefox bug:
WebRTC security plugin conflict:
I use an addon which disables WebRTC, for privacy/anti-fingerprinting reasons (I don't like ads targeting me). Obviously, I usually disable it before opening a discord session where I plan to use voice/video. It is required to enable WebRTC BEFORE selecting an audio stream from this plugin (specifically, it has to happen before the addon creates the virtual device). So, the order of events goes:
Enable WebRTC > Select audio source > open discord webpage
My thoughts on all this:
I'm unsure of whether these are issues specific to me, known issues, something actually broken, or considered normal working intended behaviour, so let me know which, if any, of these I should file a separate issue for. My thoughts on this:
The need for a relatively large quantum seems plausibly normal but a little odd, I certainly have no issues with my usual 128 quantum streaming from virtual devices over WebRTC (eg my real mic is at 128 quantum via a filter chain virtual device, I can link videos in YouTube to a virtual loopback device and stream that over WebRTC tests or discord's chat, etc), so I think perhaps there might be something up with the virtual device or perhaps Firefox's capture (strong chance this is it, because the capture was requesting 480/48000 even with the pulse env vars set and rules specifying 128/48000 and the rest of Firefox running at 128/48000 quantum - so this might be a Firefox bug) and that may need an issue filed for it. Please note this related but in firefox you'll need to know about that workaround I found, in order to get Firefox to abide by rules you set in pipewire-pulse.conf[.d], to get the lower quantum (TL;DR you need to use the PULSE_LATENCY or PULSE_LATENCY_MS environment variables, it will not follow those properties you command via those variables, but their usage will make Firefox follow rules you set in wireplumber, which it will otherwise ignore)
The weird partially unresponsive 'Share your Screen' button may be a KDE thing or a discord thing or a Firefox thing, it does only happen with this addon enabled, though, so perhaps that should have an issue filed against it, perhaps not? Do you guys get this same behaviour?
The brief error message is definitely related to my Firefox profile, a clean profile didn't do it - but it is strange because it is a false negative (as in, it says something's wrong, but there's not) so I think this might need an issue to fix it on this end.
The conflict with the Disable WebRTC addon seems normal and correct, although I can imagine that it could be possible to code this addon such that the WebRTC initialisation occurs when the outputs of this device are linked (to Firefox's inputs for the stream) rather than when the inputs are linked (to the source of audio to be shared) so perhaps this could be fixed here?
As for the severity of these issues: The need for an unusually large quantum that is normally not needed, is a fairly big problem because it taints the entire pipewire graph and negatively impacts the performance of the entire machine. The busted up button is a problem because it makes it really hard to change streams, you basically have to remove the permission to share the screen and then share it again, which kills your stream, which would be an annoyance to anyone watching it since they'd have to re-connect. The false error message is inconsequential but probably undesirable from the developer's perspective. The conflict with the Disable WebRTC addon seems normal and not difficult to avoid, but could probably be improved at this end.
The text was updated successfully, but these errors were encountered: