Bluez multi-codec support is no longer a subject since today :
So I propose to test Pali's patch in master and see if it gets any regression
reports. If automatic fallback to legacy profile works, there shouldn't be any.
31.10.2019, 14:02, "Tanu Kaskinen" :
> On Mon, 2019-10-28 at 17:12 +0100, Hyp
On Mon, 2019-10-28 at 17:12 +0100, Hyperion wrote:
> - Bluetooth packet size is not constant : BT traffic is splited in radio
> slots
> that have fixed time lengh : so for a given bandwidth : slots size vary
It's still not clear to me whether the bluetooth packets have constant
size within one A
29.10.2019, 11:42, "Pali Rohár" :
> On Tuesday 29 October 2019 11:24:06 Hyperion wrote:
>> 29.10.2019, 10:24, "Pali Rohár" :
>> > On Monday 28 October 2019 17:12:45 Hyperion wrote:
>> >> 28.10.2019, 16:11, "Tanu Kaskinen" :
>> >> > On Sat, 2019-10-26 at 20:23 +0200, Hyperion wrote:
>> >>
On Tuesday 29 October 2019 11:24:06 Hyperion wrote:
>
>
> 29.10.2019, 10:24, "Pali Rohár" :
> > On Monday 28 October 2019 17:12:45 Hyperion wrote:
> >> 28.10.2019, 16:11, "Tanu Kaskinen" :
> >> > On Sat, 2019-10-26 at 20:23 +0200, Hyperion wrote:
> >> >> 26.10.2019, 14:39, "Tanu Kaskinen" :
>
29.10.2019, 10:24, "Pali Rohár" :
> On Monday 28 October 2019 17:12:45 Hyperion wrote:
>> 28.10.2019, 16:11, "Tanu Kaskinen" :
>> > On Sat, 2019-10-26 at 20:23 +0200, Hyperion wrote:
>> >> 26.10.2019, 14:39, "Tanu Kaskinen" :
>> >> > On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote:
>>
On Monday 28 October 2019 17:12:45 Hyperion wrote:
> 28.10.2019, 16:11, "Tanu Kaskinen" :
> > On Sat, 2019-10-26 at 20:23 +0200, Hyperion wrote:
> >> 26.10.2019, 14:39, "Tanu Kaskinen" :
> >> > On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote:
> >> > > On Saturday 19 October 2019 19:27:19 Tan
28.10.2019, 16:11, "Tanu Kaskinen" :
> On Sat, 2019-10-26 at 20:23 +0200, Hyperion wrote:
>> 26.10.2019, 14:39, "Tanu Kaskinen" :
>> > On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote:
>> > > On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote:
>> > > > On Sat, 2019-10-19 at 18:16 +02
On Sat, 2019-10-26 at 20:23 +0200, Hyperion wrote:
>
> 26.10.2019, 14:39, "Tanu Kaskinen" :
> > On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote:
> > > On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote:
> > > > On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote:
> > > > > On Saturday
On Sat, 2019-10-26 at 14:54 +0200, Pali Rohár wrote:
> On Saturday 26 October 2019 15:39:51 Tanu Kaskinen wrote:
> > On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote:
> > > On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote:
> > > > On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote:
> >
26.10.2019, 20:23, "Hyperion" :
> 26.10.2019, 14:39, "Tanu Kaskinen" :
>> On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote:
>>> On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote:
>>> > On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote:
>>> > > On Saturday 19 October 2019 19:07:
26.10.2019, 14:39, "Tanu Kaskinen" :
> On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote:
>> On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote:
>> > On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote:
>> > > On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote:
>> > > > On Sat,
On Saturday 26 October 2019 15:39:51 Tanu Kaskinen wrote:
> On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote:
> > On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote:
> > > On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote:
> > > > On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote:
On Sat, 2019-10-19 at 18:42 +0200, Pali Rohár wrote:
> On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote:
> > On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote:
> > > On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote:
> > > > On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote:
> >
19.10.2019, 18:42, "Pali Rohár" :
> On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote:
>> On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote:
>> > On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote:
>> > > On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote:
>> > > > On Friday 1
19.10.2019, 18:16, "Pali Rohár" :
> On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote:
>> On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote:
>> > On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote:
>> > > On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote:
>> > > > Regression woul
On Saturday 19 October 2019 19:27:19 Tanu Kaskinen wrote:
> On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote:
> > On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote:
> > > On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote:
> > > > On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote:
>
On Sat, 2019-10-19 at 18:16 +0200, Pali Rohár wrote:
> On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote:
> > On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote:
> > > On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote:
> > > > On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote:
> > > >
On Saturday 19 October 2019 19:07:44 Tanu Kaskinen wrote:
> On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote:
> > On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote:
> > > On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote:
> > > > Regression would mean that some devices can't connect anymore
On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote:
> On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote:
> > On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote:
> > > Regression would mean that some devices can't connect anymore : this
> > > won't happen if a workaround is provided, and this w
On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote:
> On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote:
> > Regression would mean that some devices can't connect anymore : this
> > won't happen if a workaround is provided, and this workaround won't
> > be used often.
> >
> > Most (99% ?) of t
On Fri, 2019-10-18 at 15:01 +0200, Hyperion wrote:
> Yes !!! for the module argument ! (just a boolean is needed).
>
> Which module ? (module-bluez5-device ?).
Users load only module-bluetooth-discover, so the module argument has
to be added to that module. module-bluetooth-discover in turn load
Yes !!! for the module argument ! (just a boolean is needed). Which module ? (module-bluez5-device ?). JP 18.10.2019, 14:52, "Hyperion" :That's Why I proposed to set the config switch to "legacy max negotiated bitpool" (current code) by default, and let the user decide if he/she wants to activate
That's Why I proposed to set the config switch to "legacy max negotiated bitpool" (current code) by default, and let the user decide if he/she wants to activate the "XQ max negociated bitpool" (my patch). This way it's less likely to cause regressions than Pali's "forced bitpool" XQ modes : by def
On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote:
> Regression would mean that some devices can't connect anymore : this
> won't happen if a workaround is provided, and this workaround won't
> be used often.
>
> Most (99% ?) of the devices will work correctly with my patch (many
> of them in XQ m
Regression would mean that some devices can't connect anymore : this won't
happen if a workaround is provided, and this workaround won't be used often.
Most (99% ?) of the devices will work correctly with my patch (many of them in
XQ mode, and some in legacy mode because they will fall back to l
The SRC (PA) does not announce XQ bitpool. It takes the max bitpool value announce by the SNK (the BT device) and then decide if XQ is possible, or not, depending on the value announced by the SNK and its ability to do dual channel (also announced by the SNK during negociation).As stated in the REA
On Thursday 17 October 2019 16:11:26 Tanu Kaskinen wrote:
> On Thu, 2019-10-17 at 14:55 +0200, Pali Rohár wrote:
> > On Thursday 17 October 2019 15:52:00 Tanu Kaskinen wrote:
> > > On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote:
> > > > Automatic SBC profile is not going to be changed. It is t
On Thu, 2019-10-17 at 14:55 +0200, Pali Rohár wrote:
> On Thursday 17 October 2019 15:52:00 Tanu Kaskinen wrote:
> > On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote:
> > > Automatic SBC profile is not going to be changed. It is there to support
> > > all devices without any tweaks. ValdikSS alr
On Thursday 17 October 2019 15:52:00 Tanu Kaskinen wrote:
> On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote:
> > Automatic SBC profile is not going to be changed. It is there to support
> > all devices without any tweaks. ValdikSS already did more tests and
> > there are devices which do not wo
On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote:
> Automatic SBC profile is not going to be changed. It is there to support
> all devices without any tweaks. ValdikSS already did more tests and
> there are devices which do not work with higher SBC bitpool. So
> increasing max value of bitpool i
Hi Pali, To go away from the debate about "what's deprecated and what's not?" , and if yes or no : devices that don't implement a MANDATORY A2DP feature like DUAL CHANNEL, while FAKING that they DO IMPLEMENT IT (which is the only case where my algorithm fails) : have to be the main target, or not .
I disagree. As an engineer you should know that an implementation should not be based on broken devices , but rarher on good standard specifications. Rare broken devices, and rare very old devices that don't follow A2DP specifications shouldn't be the main design target for Pulseaudio.Jp18:29, 8 oc
Automatic SBC profile is not going to be changed. It is there to support
all devices without any tweaks. ValdikSS already did more tests and
there are devices which do not work with higher SBC bitpool. So
increasing max value of bitpool in Automatic SBC profile would lead to
broken support for thes
I'm not talking about old Bluez versions : only about the current stable 5.51,
and not talking about codec switchin either.
Just talking about improvement of MAX negociated values for SBC. Please take a
look at my latest patch.
07.10.2019, 16:22, "Pali Rohár" :
> Old bluez versions have bugs an
Old bluez versions have bugs and different behavior. So not break
anything else and still have working audio playback, it is better to not
touch it and use what is currently supported / provided.
New features like additional codec support, codec switching, etc...
needs new bluez API and new functi
I disagree with "Also there would not be any feature/functional changes in
pulseaudio when older bluez version is in use".
Tests prove that there's no reason for this, if only one mode/profile is used.
JP
07.10.2019, 15:36, "Pali Rohár" :
> I will try to look what is the problem without --exper
I will try to look what is the problem without --experimental. This
should work correctly prior merging this PR.
Need to --experimental is just temporary until support in bluez is not
fully stable. I guess it would be non-experimental in next bluez
version.
Also there would not be any feature/fun
Without the --experimental flag : negociation stops (see hcidump below) and
device falls back to "Off" status.
btw : if you implement my (simple) negociation algorithm for the "Automatic
Quality" mode ; AND make it to work without --experimental Bluez flag : it
woiuld be close to perfect.
See
And what happened without --experimental?
Aim is to support all bluez versions also with and without
--experimental flag. Just for older versions (or without experimental)
it should behave like before this patch series -- only SBC codec in
automatic mode and no codec switching.
On Monday 07 Octob
Thanks, I forgot the "--experimental" param.
Works as expected, like the previous v12 serie of patches
JP
07.10.2019, 15:15, "Pali Rohár" :
> Can you check if you have Bluez 5.51 and bluetoothd daemon is running with
> --experimental param?
>
> And is not it possible to change profile from Off
Can you check if you have Bluez 5.51 and bluetoothd daemon is running with
--experimental param?
And is not it possible to change profile from Off to Automatic Quality?
On Monday 07 October 2019 15:08:59 Hyperion wrote:
> The 10 patches compile OK on PA master without warnings.
>
> But doesn't
The 10 patches compile OK on PA master without warnings.
But doesn't work (device is Off with "Automatic Quality unavailable" status).
Tested on 2 devices.
hcidump avdtp
HCI sniffer - Bluetooth packet analyzer ver 5.51
device: hci0 snap_len: 1500 filter: 0x400
< AVDTP(s): Discover cmd: transacti
Previously module-bluetooth-policy was switching from A2DP to HSP profile
when VOIP application started recording of source. Now it switch to profile
with the highest priority which has both sink and source. In most cases it
is HSP profile, but it can be also bi-directional A2DP profile (e.g.
FastS
43 matches
Mail list logo
