Fixespipewire/pipewire#502.
Also move media application creating from filter callback to initialization.
Application object path and endpoint paths only need to be registered once.
Signed-off-by: Huang-Huang Bao <eh5@sokka.cn>
Backends don't necessarily allow for opening the same device multiple
times, and it shouldn't be necessary.
Since source and sink are not necessarily both running at the same time,
refcount the transport acquire/release so that it knows to close the fd
only when no source/sink is running.
Let the transport manage the fd lifecycle, also closing it once it is
not needed.
Don't return the fd from acquire(), since each transport is associated
with a single socket fd.
Instead of using a hardcoded value for the minimum delay between writes,
select it according to the mtu/packet size that is currently used.
This is necessary for correct playback with lower mtu values.
Kernel should provide the correct mtu/packet size to use for SCO socket
I/O, but it does not currently appear to (as of linux 5.9), see
https://lore.kernel.org/linux-bluetooth/20201210003528.3pmaxvubiwegxmhl@pali/T/
When using mSBC, instead of using the (incorrect) kernel-provided value,
hardcode mtu to 24, corresponding to ALT1 mode. BT-UART adapters should
not require specific mtu, and it appears most BT-USB adapters only
support ALT1, see
https://lore.kernel.org/linux-bluetooth/20201210012003.133000-1-tpiepho@gmail.com/
This code needs to be revised when the issue is sorted out on the kernel
side.
Add setting bluez5.msbc-force-mtu for easier debugging in special cases.
Leave read_mtu as the detected value --- it does not seem to affect
whether BT-USB can record, but Raspberry Pi BT-UART fails to record if a
different value is used.
oFono tries to use the best codec when setting up the audio connection, so
the codec to use is known during call to `acquire` function, after the
transport has been created.
To get the codec before creating the transport, an audio connection is
set-up and discarded during `ofono_audio_card_found()`. It should return
the best codec available, which should not change during the time the
remote is connected.
mSBC can be enabled by passing "bluez5.msbc-support=true" parameter to
pipewire-media-session.
mSBC is automatically selected if remote device supports it.
Some codecs need the MTU as a parameter so wait until we acquire
with creating the codec context.
Make some method to enumerate the parameters from the transport
config and use that for the EnumFormat param.
