Hi, la, 2023-09-23 kello 12:14 +0300, Pauli Virtanen kirjoitti: > Hi Luiz, > > pe, 2023-09-22 kello 12:23 -0700, Luiz Augusto von Dentz kirjoitti: > > From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> > > > > This splits media-api.rst into org.bluez.Media<interface>.rst and > > generate manpages for them. > > I made a pass looking at the implementations of the transport/endpoint > and SetConfiguration/SelectProperties/SelectConfiguration and comparing > to docs. > > Note that the SelectProperties API has a problem with BAP endpoint > configuration. We maybe should redesign it while we still can? > > I think generally at least from Pipewire side there's no need to keep > backward compatibility while this is experimental. We can target BlueZ > master branch. > > > SelectProperties API problem: > > As BAP client one first does Config Codec (ASCS §5.1) which takes > Target_Latency, Target_PHY and Codec. > > After this, the ASE properties (ACSS Table 4.3) in Codec Configured > state contain the server supported values for Max_Transport_Latency, > Presentation_Delay_Min/Max etc. > > SelectProperties is called before Config Codec, so it cannot > necessarily know the server supported values. In this case the sound > server cannot fill in QoS correctly. > > The client-invoked SetConfiguration API also seems to have similar > issue. > > Probably: SelectProperties should be called twice, once to get > parameters for Config Codec, and then again to get parameters for > Config QoS. Or, there should be a separate "SelectCodec" and > "SelectQoS" calls. Calling "SelectProperties" twice could be simpler > for everyone. > > In client-invoked "SetConfiguration" API, one probably should only pass > in the parameters needed for Config Codec, and BlueZ should then make a > SelectProperties call to get the QoS ones once the server-side values > are known. > > I can take a look at this... > > > MediaTransport: > > "Delay" field only exists for A2DP in code. > > "Volume" field only exists for A2DP in code. > > "Links" is ucast only in code. > > "QoS.TargetLatency" does not exist in code. Maybe it should be exposed > for consistency, since it's expected as return from SelectProperties. > > > SetConfiguration: > > SetConfiguration properties dict when called by BlueZ contains exactly > the properties of the transport. The documentation probably should say > that this is so. > > When called by client, the contents of the properties dict are expected > to be different. QoS parameters are not packed in a "QoS" dict. Maybe > they should be. The "PHY" key is also still a string here. Also, "Framing" is boolean here (elsewhere it's byte). > > The documented input parameters expected from client are wrong, the > documentation explains fields of struct bt_bap_pac_qos, but what the > code parses are that of struct bt_bap_qos. > > "MaximumLatency": no such field in code, seems to be called "Latency" > everywhere. > > > SelectProperties: > > In code, the return parameter expects QoS parameters (struct > bt_bap_qos) to be packed in "QoS" dict. > > They are not packed in "QoS" dict in the input parameters. These are > not exactly QoS, but instead struct bt_bap_pac_qos, so not clear if > they should be packed. > > The input and return parameters are not documented. The input QoS > contains fields of struct bt_bap_pac_qos. The return QoS has fields of > struct bt_bap_qos. > > > MediaEndpoint: > > The endpoints published by BlueZ only have the properties > "UUID", "Codec", "Capabilities", "Device". > > The documentation lists various other things, but they are not > implemented as server endpoint properties. > > As client endpoint properties: > > "RTN" is expected to be present in code, but is not documented. "RTN" is called "Retransmissions" elsewhere. > > "MaximumLatency" "Location" "SupportedContext" "Context" are documented > but not present in code. > >
