Announcement

Collapse
No announcement yet.

Pinos Is For Linux Video What PulseAudio Is For Audio

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Pinos Is For Linux Video What PulseAudio Is For Audio

    Phoronix: Pinos Is For Linux Video What PulseAudio Is For Audio

    Just a few hours after writing about some new Linux video project dubbed "PulseVideo", Pinos was announced as a new initiative by Fedora Workstation for improving Linux video support...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Ohh, this is PulseAudio for Video Input. For reference, the XServer or a Wayland compositor is PulseAudio for Video/Graphics Output as it multiplexes access to the same DRM device for multiple clients, so one client doesn't have to hog the hardware as is done with raw ALSA.

    Comment


    • #3
      It cannot work, sorry.

      For different video inputs you have to set up your web cam [hardware] in a certain way, which precludes other apps from using the web cam differently.

      I.e. if app1 sets 1280x720@30 MJPEG capture mode, no other app can set a web cam to 640x480@60 YUV mode.

      Comment


      • #4
        Originally posted by birdie View Post
        It cannot work, sorry.

        For different video inputs you have to set up your web cam [hardware] in a certain way, which precludes other apps from using the web cam differently.

        I.e. if app1 sets 1280x720@30 MJPEG capture mode, no other app can set a web cam to 640x480@60 YUV mode.
        Presumably it could downscale it as needed?

        Comment


        • #5
          Originally posted by psychoticmeow View Post

          Presumably it could downscale it as needed?
          Oh boy... Let's throw resources at the problem... Why not? It can waste as much as it wants right? You have a multicore processor with multiple GB of RAM right?

          That's exactly what PAs problem. They try to brute force what shouldn't be done and ended up with an audio server with 50ms to 2s of latency and no possible way to predict where at in the middle it might be. The only reason people don't see it is because of gigantic buffers allocated by the -playback- software to try and hide it.

          Comment


          • #6
            Originally posted by duby229 View Post

            Oh boy... Let's throw resources at the problem... Why not? It can waste as much as it wants right? You have a multicore processor with multiple GB of RAM right?

            That's exactly what PAs problem. They try to brute force what shouldn't be done and ended up with an audio server with 50ms to 2s of latency and no possible way to predict where at in the middle it might be. The only reason people don't see it is because of gigantic buffers allocated by the -playback- software to try and hide it.
            Oh no! Using CPU cycles to enable functionality! When will this insanity ever end?

            Comment


            • #7
              For those of you who has been around for a while you might remember how you once upon a time could only have one application using the sound card at the same time until PulseAudio properly fixed that.
              Yeah right, not like every other Unix had that already figured out with 1% of the complexity.

              Comment


              • #8
                ^Yeah, if you want to argue that Pulseaudio was better than OSS4, dmix, arts, esd, etc., that's one thing, but if you want to pretend those things didn't exist, you're deluded.

                Comment


                • #9
                  Originally posted by psychoticmeow View Post

                  Oh no! Using CPU cycles to enable functionality! When will this insanity ever end?
                  Or as a better idea, implement functionality the way hardware was designed. It's beyond stupid to ignore hardware design and try to brute force with software instead.
                  Last edited by duby229; 30 June 2015, 04:04 PM.

                  Comment


                  • #10
                    Originally posted by duby229 View Post

                    Or as a better idea, implement functionality the way hardware was designed. It's beyond stupid to ignore hardware design and try to brute force with software instead.
                    And where the hardware is inadequate?

                    Comment

                    Working...
                    X