Add a control.ump port property. When true, the port wants UMP and the
mixer will convert to it. When false, the port supports both UMP and
Midi1 and no conversions will happen. When unset, the mixer will always
convert UMP to midi1.
Remove the CONTROL_types property from the filter. This causes problems
because this is the format negotiated with peers, which might not
support the types but can still be linked because the mixer will
convert.
The control.ump port property is supposed to be a temporary fix until we
can negotiate the mixer ports properly with the CONTROL_types.
Remove UMP handling from bluetooth midi, just use the raw Midi1 events
now that the mixer will give those and we are supposed to output our
unconverted format.
Fix midi events in-place in netjack because we can.
Update docs and pw-mididump to note that we are back to midi1 as the
default format.
With this, most of the midi<->UMP conversion should be gone again and we
should be able to avoid conversion problems in ALSA and PipeWire.
Fixes#5183
A DMA buffer from a DRM device are typically accessed using API related
to a DRM device, e.g. Vulkan or EGL. To create such a context for using
with a PipeWire stream that passed DRM device DMA buffers applications
have so far usually guessed or made use of the same context as the
stream content will be presented. This has mostly been the Wayland
EGL/Vulkan context, and while this has most of the time worked, it's
somewhat by accident, and for reliable operation, PipeWire must be aware
of what DRM device a DMA buffer should be accessed using.
To address this, introduce device ID negotation, allowing sources and
sinks to negotiate what DRM device is supported, and what formats and
modifiers are supported by them.
This will allow applications to stop relying on luck or the windowing
system to figure out how to access the DMA buffers. It also paves the
way for being able to use multiple GPUs for different video streams,
depending on what the sources and sinks support.
Automatically make an empty PeerCapability param when we receive a
Latency event without a PeerCapability. This makes new client always
receive a PeerCapability param, even when the other side did not provide
anything or when the server is too old to collect them.
Update the scheduling doc with some information about how async
scheduling works. Also add something about the latency.
Async links add 1 quantum of latency so take that into account when
aggregating latencies.
Also a source directly linked to an async node does not add latency
(we evaluate the tee before incrementing the cycle so that it effectively
is executed in the previous cycle and consumed immediately by async
nodes). We can do this because the driver source always provides data
before the async node, and never concurrently.
Add a listener to the link for the node driver change as well because
that can now influence the latency for async nodes.
The current situation is:
- The ALSA sequencer produces and consumes raw UMP only. Legacy input
is converted with the control mixer to UMP.
- All apps and plugins are made to consume and produce UMP.
- The control mixer can convert between UMP and MIDI when required.
- Legacy apps (pw-filter) will still receive MIDI1 events (converted by
the control mixer).
- Helper functions to convert UMP to and from MIDI can be used to ease
implementation when legacy MIDI is still required.
Using UMP natively over raw MIDI has some advantages:
- Transparent support for MIDI2 hardware and the new MIDI2 features
such as increased resolution for events, microtonal support, etc..
- Easy to convert between legacy MIDI and UMP
- Large SysEx can be fragmented properly.
- Fixed size messages are easier to parse and handle.
