libvisual icon indicating copy to clipboard operation
libvisual copied to clipboard

Support PipeWire

Open kaixiong opened this issue 2 years ago • 4 comments

PipeWire is becoming a standard on Linux and we should have an actor and an input plugin supporting it.

kaixiong avatar Feb 08 '23 12:02 kaixiong

@kaixiong I agree and already played a bit with client code but it's a bit of bumpy road, and https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2997 only is the start of it. If it was less bumpy I had already added a version to my https://github.com/hartwork/audio_pump_demo . Note that their API seems to be fully asynchronous, so we'll need tricks similar to what we have for PulseAudio's synchronous API. Happy to learn I'm wrong about any of this :smiley:

hartwork avatar Feb 08 '23 15:02 hartwork

PS: What I find interesting is how they hand out and take in buffers with pw_stream_dequeue_buffer and pw_stream_queue_buffer.

hartwork avatar Feb 09 '23 04:02 hartwork

@kaixiong I agree and already played a bit with client code but it's a bit of bumpy road, and https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2997 only is the start of it. If it was less bumpy I had already added a version to my https://github.com/hartwork/audio_pump_demo

@hartwork That is.. surprising :facepalm:

Note that their API seems to be fully asynchronous, so we'll need tricks similar to what we have for PulseAudio's synchronous API. Happy to learn I'm wrong about any of this smiley.

It's probably time to convert all the input plugins to use asynchronous calls. We can maybe factor out the lock-free ring buffer implementation in input_pulseaudio and make it part of the low-level or 'primitives' API for a start. Some ideas for the high-level API for input plugins were brought up in #54.

kaixiong avatar Feb 13 '23 14:02 kaixiong

@kaixiong we definitely need a way to support asynchronous input APIs out of the box, I agree.

hartwork avatar Feb 13 '23 16:02 hartwork