mixer: handle control.ump property

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
This commit is contained in:
Wim Taymans 2026-03-25 11:47:01 +01:00
parent 7fe191bc10
commit 9eeb2f1930
9 changed files with 88 additions and 105 deletions

View file

@ -62,6 +62,13 @@ As of 1.4, SPA_CONTROL_UMP (Universal Midi Packet) is the prefered format
for the MIDI 1.0 and 2.0 messages in the \ref spa_pod_sequence. Conversion
to SPA_CONTROL_Midi is performed for legacy applications.
As of 1.7 the prefered format is Midi1 again because most devices and
applications are still Midi1 and conversions between Midi1 and UMP are not
completely transparent in ALSA and PipeWire. UMP in the ALSA sequencer
and consumers must be enabled explicitly. UMP in producers is supported
still and will be converted to Midi1 by all consumers that did not explicitly
enable UMP support.
## The PipeWire Daemon
Nothing special is implemented for MIDI. Negotiation of formats
@ -104,13 +111,14 @@ filtering out the \ref SPA_CONTROL_Midi, \ref SPA_CONTROL_OSC and
\ref SPA_CONTROL_UMP types. On output ports, the JACK event stream is
converted to control messages in a similar way.
Normally, all MIDI and UMP messages are converted to MIDI1 jack events unless
the JACK port was created with an explcit "32 bit raw UMP" format or with
the JackPortIsMIDI2 flag, in which case the raw UMP is passed to the JACK
application directly. For output ports,
the JACK events are assumed to be MIDI1 and converted to UMP unless the port
has the "32 bit raw UMP" format or the JackPortIsMIDI2 flag, in which case
the UMP messages are simply passed on.
Normally, all MIDI and UMP input messages are converted to MIDI1 jack
events unless the JACK port was created with an explcit "32 bit raw UMP"
format or with the JackPortIsMIDI2 flag, in which case the messages are
converted to UMP or passed on directly.
For output ports, the JACK events are assumed to be
MIDI1 unless the port has the "32 bit raw UMP" format or the JackPortIsMIDI2
flag, in which case the control messages are assumed to be UMP.
There is a 1 to 1 mapping between the JACK events and control
messages so there is no information loss or need for complicated