Pinos Is For Linux Video What PulseAudio Is For Audio

[phoronix]

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...

http://www.phoronix.com/scan.php?pag...inos-Announced

[Ancurio]

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.

[birdie]

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 [email protected] MJPEG capture mode, no other app can set a web cam to [email protected] YUV mode.

[psychoticmeow]

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 [email protected] MJPEG capture mode, no other app can set a web cam to [email protected] YUV mode.

Presumably it could downscale it as needed?

[duby229]

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.

[psychoticmeow]

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?

[h**2]

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.

[DanL]

^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.

[duby229]

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.

[psychoticmeow]

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?