Firefox 116 Should Have Experimental PipeWire Camera Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Hibbelharry
    Senior Member
    • Jun 2009
    • 627

    #21
    Originally posted by Danny3 View Post
    Cool!
    But now I wonder when will Firefox automatically detect and enable its Wayland support when running in a Wayland session on Gnome or KDE Plasma?
    How hard it could be to detect a Wayland session and enable support for it?
    You misunderstand the challenge. They're detecting the type of session just fine, they don't enable wayland for other reasons at least on stable releases. On nightly releases it's enabled for probably a year...

    See here: https://bugzilla.mozilla.org/show_bug.cgi?id=1752398

    Comment

    • creative
      Senior Member
      • Mar 2017
      • 870

      #22
      Originally posted by pharmasolin View Post

      Define what's main Linux OSes. Steam deck I believe use pipewire, Ubuntu as well, Fedora as mentioned above, Arch(?) Pipewire is here
      The only thing is is that if you don't want pipewire? I am absolutely fine without it. If I want really low latency qjackctl runs through d-bus and the pulse-jack interface was automatically bridging. It's becoming more of a question of can you get a distro running without the dependencies of it. Lutris required it due to depending on xdg-desktop-portal which one of its own dependencies is pipewire. Pipewire seems to be pretty much fine as far as I can see but if you want to go without it? All of my experience with Starship Matiese, GA104, and my Focusrite Scarlette 2i2 sound interfaces absolutely didn't need pipewire at all, not even jack for optimal operation, everything worked perfectly.

      The proposed advantage of pipewire are things like screencasting with certain things and supposedly better security across sandboxed applications. I am not sure that it is actually lower latency than alsa>puiseaudio or jack2-dbus>alsa>pulsaudio. I would think adding pipewire
      might actually increase latency.

      I am not against pipewire, better Audio/Video continuity has probably been needed for quite sometime for automatically bridging applications better. I am not sure if it's a better added layer of redundancy due to applications being coded in such an isolated way that they needed something like pipewire to plug into them. I would need to see a really good control group of plenty of testing across a broad spectrum of actual AV application scenarios in a lab type environment to be fully convinced that it's needed though.
      Last edited by creative; 17 June 2023, 01:50 PM.

      Comment

      • Wtay
        Junior Member
        • Jun 2017
        • 14

        #23
        Originally posted by creative View Post

        The only thing is is that if you don't want pipewire? I am absolutely fine without it. If I want really low latency qjackctl runs through d-bus and the pulse-jack interface was automatically bridging.
        ...
        I am not sure that it is actually lower latency than alsa>puiseaudio or jack2-dbus>alsa>pulsaudio. I would think adding pipewire
        might actually increase latency.
        ...
        You can do this jackdbus bridging with PipeWire as well since the latest release. It will give you lower latency than anything pulseaudio
        can achieve.

        Comment

        • Wtay
          Junior Member
          • Jun 2017
          • 14

          #24
          Originally posted by creative

          I do. Again I would have to see the actual round trip latency, otherwise I am still not fully convinced. Nothing is going to compete with a fully bypassing jack session, nothing. Jack is as low latency as it gets, its the closest to bare metal linux has had.
          You can try this yourself right now. For me, using using jack_iodelay on pure jack2 with a loopback cable and 2 periods of 32 samples at 48KHz gives me a roundtrip latency of 5.1ms. With pipewire jackdbus bridge, routing the signal through pipewire and using jack_iodelay with the pipewire jack emulation I get a roundtrip latency of... 5.1ms. There is no added latency, there does not have to be and there isn't. You can not do this with the pulseaudio jack bridge.

          Getting less latency than jack is not generally possible with PipeWire, although on some hardware (my laptop, not using USB, for example) you can get lower latency because with timers you are not limited to the smallest period size. This is not the goal of PipeWire however.

          Originally posted by creative

          I still have issues with pipewire in some games where before I didn't need to start a jack session. If I have to starta jack session pipewire is the problem, not pulseaudio, which has had all the latency kinks ironed out already. So I am going have to call bullshit on that.
          What are those 'some games'? I don't see a bug about that so while I'm waiting I have to call bullshit on your bullshit call. If you have more information, please do tell us so we can fix it.

          Originally posted by creative

          Pipewire still has a lot of maturing to go through, this stuff always makes me laugh, just wait by the time pipewire has absolute full continuity some group of dinguses are going to add something else on top of it.

          You are getting the perception that it's better than it actually is. In actuality pipewire is only 80% there. Pulseaudio was already 97% and that missing %3 is margin of error most likely due to some weird discrepancy in some straggling process priority somewhere.
          It could be true, it also could be false.

          Originally posted by creative

          I saw a video on youtube of some British guy at some kind of conference giving a presentation about Linux as a DAW this was not that long ago. He asserted that jack and pulse did not get along, which was an absolute lie. I have experienced this stuff ever since pulseaudio's inception and yes starting out there was a lot of problems but over the years there has been plenty of maturing.
          Yes, things got a lot better and it can be even better!

          Originally posted by creative

          Do you see what I am getting at? Pipewire is causing more latency in certain application scenarios. Unless you are doing a lot of bypassing and cutting straight through adding something else on top is going to cause more latency in a number of places.

          What needs to actually happen is pulse just needs to be stripped out and pipewire needs to fully replace it. Then maybe pipewire will be 90% there.
          But pulseaudio is stripped out when you use pipewire, there is no more pulseaudio server, it's replaced by a compatible implementation that runs on top of PipeWire that has lower latency. Not sure what you mean.. Do you mean the pulseaudio protocol needs to go? Not really, the things the pulseaudio protocol and API provides are things that people actually want from an audio API, like buffering, device queries, network transparency.

          If people don't want those features, they will move away from the pulseaudio API (and some already did).

          I think you just need to be more patient. replacing the audio stack is a lot of work.

          Comment

          • creative
            Senior Member
            • Mar 2017
            • 870

            #25
            Originally posted by Wtay View Post

            You can try this yourself right now. For me, using using jack_iodelay on pure jack2 with a loopback cable and 2 periods of 32 samples at 48KHz gives me a roundtrip latency of 5.1ms. With pipewire jackdbus bridge, routing the signal through pipewire and using jack_iodelay with the pipewire jack emulation I get a roundtrip latency of... 5.1ms. There is no added latency, there does not have to be and there isn't. You can not do this with the pulseaudio jack bridge.

            Getting less latency than jack is not generally possible with PipeWire, although on some hardware (my laptop, not using USB, for example) you can get lower latency because with timers you are not limited to the smallest period size. This is not the goal of PipeWire however.



            What are those 'some games'? I don't see a bug about that so while I'm waiting I have to call bullshit on your bullshit call. If you have more information, please do tell us so we can fix it.



            It could be true, it also could be false.


            Yes, things got a lot better and it can be even better!



            But pulseaudio is stripped out when you use pipewire, there is no more pulseaudio server, it's replaced by a compatible implementation that runs on top of PipeWire that has lower latency. Not sure what you mean.. Do you mean the pulseaudio protocol needs to go? Not really, the things the pulseaudio protocol and API provides are things that people actually want from an audio API, like buffering, device queries, network transparency.

            If people don't want those features, they will move away from the pulseaudio API (and some already did).

            I think you just need to be more patient. replacing the audio stack is a lot of work.
            I had to remove my post, I was unaware of a complete pipewire replacement of pulseaudio. I am testing it now. I actually had to look for a main package that actually removes all of pulse. This whole subject really got me thinking seriously again, I currently have pulseaudio completely stripped out. No pulseaudio server. I was unaware the dependencies had been resolved for removing pulse audio with a main package being implemented.

            Whats even more hilarious is the fact that right before you posted a reply I deleted my post and went off researching and am now testing different configurations. This has happened more than once lol.

            One of the games is Dishonored 2 Death Of The Outsider in Steam having clipping with pipewire/pulse. Before pipewire, pulse had no issues with it and that was without jack bridging. There are a few others another one was S.T.A.L.K.E.R. Call Of Pripyat in Lutris.

            Audio has always been a touchy subject with me on Linux cause I have always had to go in and edit a number of files and set priorities for groups, when something comes in and toys with the work I have done myself I start to get a little pissed. Even with a Distribution completely aimed for DAW work in the past I had to go in and edit stuff.

            Before DAW distributions even existed I was having to configure and build RT kernels for audio work. Now that stuff doesn't even matter much anymore.

            I definitely have been patient, patient not to even touch the stuff but in came dependencies. Now I am testing again due to those dependencies and new packages.

            Nothing against developers and far from it, more than anything I am appreciative, it's just that at a certain point one starts feeling jaded in a sense.

            I am not the only musician out there that has expressed irritation about the subject.

            I am actually appreciative more than anything, I just wasn't expecting it to get merged in as quickly as it did, again I am on a rolling stable release distribution so I already knew sooner or later I was going to have to be getting use to changes.
            Last edited by creative; 18 June 2023, 06:37 AM.

            Comment

            Working...
            X