3 ms·
With audio, accessing kernel interfaces directly in olden days lead to problems with multiple apps using the device & inability to provide inputs/sinks from use
by fulafel 3y ago
With audio, accessing kernel interfaces directly in olden days lead to problems with multiple apps using the device & inability to provide inputs/sinks from userspace (eg post/preprocessing or hw driver implemented in userspace). It's still that way with video.
People have been using a out of tree loopback video kernel driver for these things which is hard to use and hacky and slow.
- tadfisher 3y agoThat still is the case, it's just that nobody runs hardware DSPs so nobody needs to deal with anything but a single userspace sound server. Video just has order-of-magnitude higher processing requirements, so dumping raw buffers into userspace and letting a "video server" do the work isn't usable for use cases that care about latency, throughput or resource usage (e.g. game streaming). So you end up with a bunch of kernel interfaces for hardware-accelerated video transforms (many driver-specific), a few competing userspace APIs (gstreamer, vulkan extensions, vaapi, vdpau, etc), zero-copy kernel buffer APIs, the list goes on. You end up with something like Pipewire just to abstract over the complexity.