Add a flag A2DP_CODEC_FLAG_SINK to incidate a sink endpoint.
Also enum_config and caps_preference_cmp may need to know whether the
codec is being configured for SRC or SNK. Also add the flags argument to
init_props.
Bump codec API version.
a2dp-sink writing duplex data to the BT socket breaks a2dp-source source
polling, also in A2DP source role. Hence, use the timer-based polling
workaround always in duplex mode.
a2dp-source as driver does not produce regularly spaced graph cycles,
because A2DP is not isochronous. This causes e.g. crackling for alsa
etc. that expect regular timings. It also does not rate match.
Change a2dp-source to trigger graph on regular intervals. Change recv to
only accumulate data to a buffer, and put data to buffers in process().
Rate match with DLL, keeping average buffer level constant. Keep track
of jitter to determine a safe target value.
LC3plus expands 509 bytes input -> 7680 bytes output, which is bigger
than current decode buffer.
Make the decode buffer bigger, and put it on heap, not stack.
The PropInfo either has a registered id (and then also a name from the
type-info) or a custom name as a string.
In all cases, the description contains a free form text that clarifies
the property.
Use the description in the stream controls name.
Remove quantum limitation from a2dp-sink, and adjust how flushing is
done.
The "low-latency" A2DP codecs are not able to flush all data at once, so
for them flush based on a timeout, such that "excess samples" for each
quantum is bounded. We also limit excess samples for the other A2DP
codecs, based on some testing on flaky headset/adapter combinations (for
most cases, this does not appear to matter).
Leave decision of packet sizes to the codecs. Currently, we send packets
based on min_latency, but sendinf full packets might help with stutter
on some headset/adapter combinations. The slightly increased latency
hardly matters against the 100ms delays in BT headsets.
Bump codec API version.
Make the alignment parameter optional when negotiating buffers.
Default to a 16 bytes alignment and adjust for the max cpu
alignment.
Remove the useless align buffer parameter in plugins, we always
set it to 16 anyway.
For unknown reason the BT socket when working with A2DP "duplex" stream,
sometimes stops waking up poll when data arrives. Regardless, recv() can
read data packets from it.
To work around this, when A2DP source is in duplex mode, instead of
polling on data, we poll on a timer.
Some non-standard A2DP codecs (FastStream/aptX-LL) have "voice duplex
channel" that can be used to provide an A2DP duplex mode.
Add support for duplex channels, accounting for the fact that the two
directions may be encoded with different actual codecs.
When we add a new listener to an object, it will emit the full state
of the object. For this it temporarily sets the change_mask to all
changes. Restore the previous state after this or else we might not
emit the right change_mask for the next listener.
Consider the case where one there are two listeners on an object.
The object emits a change and the first listener wants to enumerate the
changed params. For this is adds a new listener and then triggers the
enumeration. If we set the change_mask to 0 after adding the listener,
the second listener would get a 0 change_mask and fail to update
its state.
Initial Props value are parsed from device settings, further changes are triggered by 'set_param' on a2dp node.
Codec can then use props to tweak its transcoder.
Typically a source stops the connection when it has nothing to play
and this causes the transport to become "idle" and our A2DP source
also stops. However, the node is still present and "running" (if linked),
which causes the graph to underrun as it receives no data from this node.
This patch dynamically creates and destroys the a2dp source node depending
on the transport state. So, when the transport is idle, there is no node
in the graph at all.
This may avoid infinite loops if parameters are being set based on events
sent by parameter changes. It's also what alsa-acp devices do, so bluez5
should follow.
Release the transport if it went idle, ensuring that the fd is closed,
and add safeguards we won't double-acquire/release it.
This can occur if the device pauses the playback. The transport may also
activate again later on, and in this case we need to reacquire a new fd.
Not closing the old fd causes problems in this case.
However, apparently the BlueZ Release() call fails if the transport is
idle. We just ignore the error and downgrade the error message; it might
not be safe to not call Release() because the idle property update is
async.
Make a2dp clock advance at the correct rate.
Revert back to accumulating to a single buffer before sending it out.
What it did previously seemed hard to get to work properly with e.g.
aptx which produces block of varying sizes on decoding.
Since the data thread accesses the spa_bt_transport, its destroy event
needs to sync with data thread to avoid races.
Also check transport is present in places that need 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.
Use codec methods. Init codec at start.
Remove rate match until we actually implement this
Add some buffering of packets before we hand them out.
Always simply fill a buffer and hand it out.
don't emit signals when we are following another driver.
Acquire transport as soon as it goes to PENDING.
