It would be nice to be able to capture V4L devices like WebCams and capture cards. The way this works on Pipewire seems similar to how audio works. One example here. I'd like to be able to list v4l devices (name and uuid) and be able to capture video from a v4l device specified by uuid (and perhaps select framerate and resolution mode if that is supported)

Hi, thanks a lot for your library!

I am not that familiar with C++ and Pipewire so sorry if the answer is trivial. But after looking at the link-app-to-mic example, I cant figure out how to delete a link again without deleting the whole microphone (I am searching for something like this). Is this something still missing in the library or am I just doing something wrong?

build/_deps/rohrkabel-src/include/rohrkabel/context.hpp:26:45: error: declaration of ‘std::shared_ptrpipewire::core pipewire::context::core()’ changes meaning of ‘core’ [-fpermissive]
[build] 26 | [[nodiscard]] std::shared_ptr core();

Rohrkabel needs some heavy improvements regarding the Thread-Loop.

The current support for the thread-loop is a bit unintuitive, namely the following things are not as clear and simple as I'd like them to be:

• Thread Loop
  • All created objects (through core::create(_simple)) are not safe to be deleted without locking the thread-loop
    This means that one has to lock the thread-loop and then explicitly delete the created object
    This is a big caveat and can cause problems when a user is not aware of this, also it's really ugly.
  • When using any form of events the callback for the event will be called from the thread-loops thread.
    This is really problematic because you can't update from within it.

(implemented in f531d2c)

Possible Solutions

1. Revert the thread-loop changes and bring back call_safe.

Pros:

• Would circumvent the events issue.

Cons:

• call_safe had it's own caveats and things I didn't like about it
• Not as elegant as I'd like it to be

2. Make object constructors (i.e. node, port, ...) private and use static method to instantiate the object

And return shared_ptr that has custom deleter to make sure object is deleted safely.

Pros:

• Would solve the destruction thread-safety issue
• Is somewhat elegant

Cons:

• Would not solve the events issue

3. The pipewire-rs appraoch

See https://pipewire.pages.freedesktop.org/pipewire-rs/pipewire/channel/index.html#examples

Design:

• Channel

  • Can send and receive messages to/from the main-loop
    • The exchanged messages can be of any arbitrary type
      • In case the channel tries to send a pipewire-object (i.e. node, device, proxy) we throw a compile-time error (in case the passed object is not a const-reference or borrow_ptr) to make sure the passed object stays in the loop thread

• Required changes to current code

  • Core, Context, Registry should assert that the main-loop they get bound to was initialized on the same thread.
  • main_loop::run() should assert that the creation thread is also the execution thread

Pros:

• Is pretty elegant
• Solves the events issue
• Would have no additional impact on the current implementation

Cons:

• None

4. Design all inherently unsafe methods to be async

Design:

• All unsafe methods will ...
  • ... _{^{(in case the loop is a thread_loop)}} lock the core and bind / create the object, then unlock it and return the not yet evaluated result
    • we can not wait for the object to be evaluated here because it would not work when called from an event
  • ... _{^{(in case the loop is a main_loop)}} bind / create the object, trigger an update and return the promise
• The promise can be waited upon (i.e. promise::get(), promise::wait()
  • However it would assert if called from within the thread-loops thread.
• The promise has a method promise::error() that takes a callback which is invoked in case of an error
• The promise has a method promise::then() that takes a callback which is invoked once the result is ready
  • The promise will have a state which will live until the callback has been called
  • This would ensure that the objects destructor is called from within the thread-loops thread (as long as the object is not movable, copyable, ...)
  • This would be safe to use even from within the thread-loops thread

Pros:

• inherently solves some issues the call_safe mechanism had (namely that the object is guaranteed to die within the thread-loops thread)
• may be a little more intuitive than the call_safe approach, as all functions that would require special care would return a promise

Cons:

• Callback Hell
• More complex and while it's a little harder to mess things up with this approach (in comparison to call_safe) it's still easy to do things wrong by accident
• Will make the code way more complex depending on how it's implemented (would best be implemented with templates, which will in turn bring caveats when used on all major classes)
• Also not the most elegant solution

This issue currently serves as an outlet for my ideas regarding this issue.
I will keep updating this post with ideas that come to mind and will leave it open until I have found a solution that I'm pleased with.

💡 Help is always appreciated!
In case you're reading this issue and have any ideas or suggestions on how to tackle this problem, feel free to comment!

Current proposed solution

After some back and forth I think I will settle with solution 3

Maybe optionally, using __has_include built-in preprocessor macro.