Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 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 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 legacy bitpool during negociation) >> > > > > > >> > > > > > The remaining (1% ?) : will need a simple boolean swicth in one of >> > > > > > the PA config files to restrict negociation to legacy bitpool (a >> > > > > > module option ? or daemon.conf ?). >> > > > > > >> > > > > > I think it's really "simple", efficient, and not dependent of any >> > > > > > upcoming Bluez feature. >> > > > > > >> > > > > > "The complex solution is always the best until one find a simpler >> one" >> > > > > >> > > > > I don't know the number of users who use bluetooth headsets with >> > > > > PulseAudio, but even just 1% regression rate can mean quite a few >> > > > > unhappy users. When your headset suddenly stops working, it's not >> > > > > trivial to figure out that you may need to pass a special argument >> to >> > > > > module-bluetooth-discover in order to make it work again. >> > > > > >> > > > > It would be better to have a module argument to enable the XQ >> settings. >> > > > >> > > > Main question, do we really need this special "settings"? Because my >> > > > patch series introduce also SBC XQ profile and basically replaces >> above >> > > > module parameter, by runtime configuration. >> > > > >> > > > For me above solution looks like a hack. It adds some module parameter >> > > > for tweaking configuration. And what would happen with that parameter >> > > > after we have "proper" support for multiple codecs? Do we need to >> > > > maintain backward compatibility? Or would we remove that configuration >> > > > and therefore revert to state prior existence of new module parameter >> > > > (which is current situation)? >> > > >> > > After your patches there's still the "automatic bitpool" mode >> > > available, right? >> > >> > Yes, I wanted to have it there for legacy/backward compatibility reasons >> > for those devices which could be broken with new settings. That is the >> > reason I do not wanted to touch Automatic mode, to have exact same >> > behavior as in current (and older) pulseaudio versions. >> > >> > But if automatic mode is going to be changed, I do not see reason for >> > keeping it (the argument for backward compatibility would not apply >> > anymore, if it is going to be changed). My patch series with new A2DP >> > API can fully replace that automatic mode. >> >> I don't see how the proposed option changes anything about >> compatibility. The option will be disabled by default, so the default >> behaviour will be the same as always. > > And what should happen after support for multiple A2DP codecs (from my > patch series) would be there? Basically it obsoletes that config option. > As all such settings can be set at runtime. > >> > Automatic mode is also main objection against usage of SBC codec (it >> > does not specify, say or enforce specific bitrate or quality; it can be >> > anything) and also reason why there are vendor codecs like aptX. >> > Defining SBC LQ, MQ, HQ or XQ just allows to compare it with other >> > codecs and guarantee same settings and quality across all devices. >> >> Doesn't the automatic mode have the benefit that it automatically >> adapts to bad radio conditions so that users get the best quality >> possible without needing to fiddle with any options in case the initial >> bitrate is too high? So it's not entirely pointless. > > Yes, but it make sense only for lower bitpool values. Higher bitpool > increase size of SBC frames and with larger SBC frames there would be > lot of wasted space in bluetooth packets as pulseaudio pulseaudio does > not support SBC fragmentation. There are only some higher bitpool values > which make sense to use. > > Plus pulseaudio's implementation of (current) automatic mode only > decrease bitpool. It never increase it. Yes, it's a good improvement of your patch ! > > So yes, it is not pointless, but in current state not very useful for > higher bitpool values. > > -- > Pali Rohár > pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 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 legacy bitpool during negociation) >> > > > >> > > > The remaining (1% ?) : will need a simple boolean swicth in one of >> > > > the PA config files to restrict negociation to legacy bitpool (a >> > > > module option ? or daemon.conf ?). >> > > > >> > > > I think it's really "simple", efficient, and not dependent of any >> > > > upcoming Bluez feature. >> > > > >> > > > "The complex solution is always the best until one find a simpler one" >> > > >> > > I don't know the number of users who use bluetooth headsets with >> > > PulseAudio, but even just 1% regression rate can mean quite a few >> > > unhappy users. When your headset suddenly stops working, it's not >> > > trivial to figure out that you may need to pass a special argument to >> > > module-bluetooth-discover in order to make it work again. >> > > >> > > It would be better to have a module argument to enable the XQ settings. >> > >> > Main question, do we really need this special "settings"? Because my >> > patch series introduce also SBC XQ profile and basically replaces above >> > module parameter, by runtime configuration. >> > >> > For me above solution looks like a hack. It adds some module parameter >> > for tweaking configuration. No : if true it would mean that most of PA config options are hacks, since they nearly all rely on config files options and modules parameters. It's a clean solution to provide legacy SBC by default and XQ as an option. >> > And what would happen with that parameter >> > after we have "proper" support for multiple codecs? Having Bluez support codec switching in the future will allow to change codec "at runtime", but it's only for users who care about BT sound quality. The good solution, imho, would be to use Pali's code, witch is more advanced, WITH ADDED module parameter (sbc_quality= ?) AND ADDED "XQ automatic" mode (my patch). This way : as long as Bluez has no codec switching, the default mode (without sbc_quality module param OR sbc_quality=legacy) is still "legacy automatic" (current PA code), and with the sbc_quality=XQ codec param : the mode would switch to "XQ automatic" (my patch). When Bluez happens to provide codec switching : the sbc_quality module param would keep doing the same thing : activating XQ quality, but then : it will also activate "fixed bitpool XQ modes" and APTX, ... (Pali's patch). Note that the ability of Bluez to do codec switching SHOULD be auto detected. Note that Linux distribution packagers will be able to package PA with the XQ mode activated by default : freedom for everybody. >> > Do we need to >> > maintain backward compatibility? Or would we remove that configuration >> > and therefore revert to state prior existence of new module parameter >> > (which is current situation)? >> >> After your patches there's still the "automatic bitpool" mode >> available, right? > > Yes, I wanted to have it there for legacy/backward compatibility reasons > for those devices which could be broken with new settings. That is the > reason I do not wanted to touch Automatic mode, to have exact same > behavior as in current (and older) pulseaudio versions. > > But if automatic mode is going to be changed, I do not see reason for > keeping it (the argument for backward compatibility would not apply > anymore, if it is going to be changed). My patch series with new A2DP > API can fully replace that automatic mode. > > Automatic mode is also main objection against usage of SBC codec (it > does not specify, say or enforce specific bitrate or quality; it can be > anything) and also reason why there are vendor codecs like aptX. > Defining SBC LQ, MQ, HQ or XQ just allows to compare it with other > codecs and guarantee same settings and quality across all devices. > >> To me it seems that the new option discussed here >> would still be useful, if there are users who prefer to use the >> automatic bitpool mode. > > -- > Pali Rohár > pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 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 mode, and some in legacy mode because they will fall > > > > > > back to legacy bitpool during negociation) > > > > > > > > > > > > The remaining (1% ?) : will need a simple boolean swicth in one of > > > > > > the PA config files to restrict negociation to legacy bitpool (a > > > > > > module option ? or daemon.conf ?). > > > > > > > > > > > > I think it's really "simple", efficient, and not dependent of any > > > > > > upcoming Bluez feature. > > > > > > > > > > > > "The complex solution is always the best until one find a simpler > > > > > > one" > > > > > > > > > > I don't know the number of users who use bluetooth headsets with > > > > > PulseAudio, but even just 1% regression rate can mean quite a few > > > > > unhappy users. When your headset suddenly stops working, it's not > > > > > trivial to figure out that you may need to pass a special argument to > > > > > module-bluetooth-discover in order to make it work again. > > > > > > > > > > It would be better to have a module argument to enable the XQ > > > > > settings. > > > > > > > > Main question, do we really need this special "settings"? Because my > > > > patch series introduce also SBC XQ profile and basically replaces above > > > > module parameter, by runtime configuration. > > > > > > > > For me above solution looks like a hack. It adds some module parameter > > > > for tweaking configuration. And what would happen with that parameter > > > > after we have "proper" support for multiple codecs? Do we need to > > > > maintain backward compatibility? Or would we remove that configuration > > > > and therefore revert to state prior existence of new module parameter > > > > (which is current situation)? > > > > > > After your patches there's still the "automatic bitpool" mode > > > available, right? > > > > Yes, I wanted to have it there for legacy/backward compatibility reasons > > for those devices which could be broken with new settings. That is the > > reason I do not wanted to touch Automatic mode, to have exact same > > behavior as in current (and older) pulseaudio versions. > > > > But if automatic mode is going to be changed, I do not see reason for > > keeping it (the argument for backward compatibility would not apply > > anymore, if it is going to be changed). My patch series with new A2DP > > API can fully replace that automatic mode. > > I don't see how the proposed option changes anything about > compatibility. The option will be disabled by default, so the default > behaviour will be the same as always. And what should happen after support for multiple A2DP codecs (from my patch series) would be there? Basically it obsoletes that config option. As all such settings can be set at runtime. > > Automatic mode is also main objection against usage of SBC codec (it > > does not specify, say or enforce specific bitrate or quality; it can be > > anything) and also reason why there are vendor codecs like aptX. > > Defining SBC LQ, MQ, HQ or XQ just allows to compare it with other > > codecs and guarantee same settings and quality across all devices. > > Doesn't the automatic mode have the benefit that it automatically > adapts to bad radio conditions so that users get the best quality > possible without needing to fiddle with any options in case the initial > bitrate is too high? So it's not entirely pointless. Yes, but it make sense only for lower bitpool values. Higher bitpool increase size of SBC frames and with larger SBC frames there would be lot of wasted space in bluetooth packets as pulseaudio pulseaudio does not support SBC fragmentation. There are only some higher bitpool values which make sense to use. Plus pulseaudio's implementation of (current) automatic mode only decrease bitpool. It never increase it. So yes, it is not pointless, but in current state not very useful for higher bitpool values. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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: > > > > > 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 legacy bitpool during negociation) > > > > > > > > > > The remaining (1% ?) : will need a simple boolean swicth in one of > > > > > the PA config files to restrict negociation to legacy bitpool (a > > > > > module option ? or daemon.conf ?). > > > > > > > > > > I think it's really "simple", efficient, and not dependent of any > > > > > upcoming Bluez feature. > > > > > > > > > > "The complex solution is always the best until one find a simpler one" > > > > > > > > I don't know the number of users who use bluetooth headsets with > > > > PulseAudio, but even just 1% regression rate can mean quite a few > > > > unhappy users. When your headset suddenly stops working, it's not > > > > trivial to figure out that you may need to pass a special argument to > > > > module-bluetooth-discover in order to make it work again. > > > > > > > > It would be better to have a module argument to enable the XQ settings. > > > > > > Main question, do we really need this special "settings"? Because my > > > patch series introduce also SBC XQ profile and basically replaces above > > > module parameter, by runtime configuration. > > > > > > For me above solution looks like a hack. It adds some module parameter > > > for tweaking configuration. And what would happen with that parameter > > > after we have "proper" support for multiple codecs? Do we need to > > > maintain backward compatibility? Or would we remove that configuration > > > and therefore revert to state prior existence of new module parameter > > > (which is current situation)? > > > > After your patches there's still the "automatic bitpool" mode > > available, right? > > Yes, I wanted to have it there for legacy/backward compatibility reasons > for those devices which could be broken with new settings. That is the > reason I do not wanted to touch Automatic mode, to have exact same > behavior as in current (and older) pulseaudio versions. > > But if automatic mode is going to be changed, I do not see reason for > keeping it (the argument for backward compatibility would not apply > anymore, if it is going to be changed). My patch series with new A2DP > API can fully replace that automatic mode. I don't see how the proposed option changes anything about compatibility. The option will be disabled by default, so the default behaviour will be the same as always. > Automatic mode is also main objection against usage of SBC codec (it > does not specify, say or enforce specific bitrate or quality; it can be > anything) and also reason why there are vendor codecs like aptX. > Defining SBC LQ, MQ, HQ or XQ just allows to compare it with other > codecs and guarantee same settings and quality across all devices. Doesn't the automatic mode have the benefit that it automatically adapts to bad radio conditions so that users get the best quality possible without needing to fiddle with any options in case the initial bitrate is too high? So it's not entirely pointless. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 00/10] Bluetooth A2DP codecs
On Thu, 2019-10-17 at 15:45 +0300, Tanu Kaskinen wrote: > On Thu, 2019-10-17 at 12:06 +0200, Pali Rohár wrote: > > Hello! > > > > On Sunday 06 October 2019 19:58:32 Pali Rohár wrote: > > > Changes in v13: > > > * Do not use read smoother for A2DP sink when backchannel is in use > > > * Use new bluez org.freedesktop.DBus.ObjectManager and RegisterApplication > > > DBus APIs for codec switching > > > * Add FastStream codec profile without microphone support > > > * Correctly calculate and fill RTP sequence number in aptX-HD encoded > > > frames > > > > > > Pali Rohár (10): > > > bluetooth: Implement reading SO_TIMESTAMP for A2DP source > > > bluetooth: Print SO_TIMESTAMP warning for SCO source only once > > > bluetooth: Parse remote timestamp from A2DP RTP packets when available > > > bluetooth: Set initial A2DP profile which bluez already activated > > > > May I ask for review at least for these first 4 patches? > > Sure, I'll put you in the queue of people who have requested me to > review their patches. The queue so far: > > 1. Improvements to reconfiguration > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/24 > > 2. Adds SBC XQ negotiated at the best of capabilities of the BT device > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 > > 3. alsa-ucm: Support Playback/CaptureVolume > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/32 > > 4. [PATCH v13 00/10] Bluetooth A2DP codecs Update: Georg rightfully complained that I've for a long time promised to review his message API patches, so I put that to the second position in this priority list. Georg said he could review the A2DP codec patches, so that's not blocking on me any more. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 : 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 legacy bitpool during negociation) > > > > > > > > The remaining (1% ?) : will need a simple boolean swicth in one of > > > > the PA config files to restrict negociation to legacy bitpool (a > > > > module option ? or daemon.conf ?). > > > > > > > > I think it's really "simple", efficient, and not dependent of any > > > > upcoming Bluez feature. > > > > > > > > "The complex solution is always the best until one find a simpler one" > > > > > > I don't know the number of users who use bluetooth headsets with > > > PulseAudio, but even just 1% regression rate can mean quite a few > > > unhappy users. When your headset suddenly stops working, it's not > > > trivial to figure out that you may need to pass a special argument to > > > module-bluetooth-discover in order to make it work again. > > > > > > It would be better to have a module argument to enable the XQ settings. > > > > Main question, do we really need this special "settings"? Because my > > patch series introduce also SBC XQ profile and basically replaces above > > module parameter, by runtime configuration. > > > > For me above solution looks like a hack. It adds some module parameter > > for tweaking configuration. And what would happen with that parameter > > after we have "proper" support for multiple codecs? Do we need to > > maintain backward compatibility? Or would we remove that configuration > > and therefore revert to state prior existence of new module parameter > > (which is current situation)? > > After your patches there's still the "automatic bitpool" mode > available, right? Yes, I wanted to have it there for legacy/backward compatibility reasons for those devices which could be broken with new settings. That is the reason I do not wanted to touch Automatic mode, to have exact same behavior as in current (and older) pulseaudio versions. But if automatic mode is going to be changed, I do not see reason for keeping it (the argument for backward compatibility would not apply anymore, if it is going to be changed). My patch series with new A2DP API can fully replace that automatic mode. Automatic mode is also main objection against usage of SBC codec (it does not specify, say or enforce specific bitrate or quality; it can be anything) and also reason why there are vendor codecs like aptX. Defining SBC LQ, MQ, HQ or XQ just allows to compare it with other codecs and guarantee same settings and quality across all devices. > To me it seems that the new option discussed here > would still be useful, if there are users who prefer to use the > automatic bitpool mode. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 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 legacy bitpool during negociation) > > > > > > The remaining (1% ?) : will need a simple boolean swicth in one of > > > the PA config files to restrict negociation to legacy bitpool (a > > > module option ? or daemon.conf ?). > > > > > > I think it's really "simple", efficient, and not dependent of any > > > upcoming Bluez feature. > > > > > > "The complex solution is always the best until one find a simpler one" > > > > I don't know the number of users who use bluetooth headsets with > > PulseAudio, but even just 1% regression rate can mean quite a few > > unhappy users. When your headset suddenly stops working, it's not > > trivial to figure out that you may need to pass a special argument to > > module-bluetooth-discover in order to make it work again. > > > > It would be better to have a module argument to enable the XQ settings. > > Main question, do we really need this special "settings"? Because my > patch series introduce also SBC XQ profile and basically replaces above > module parameter, by runtime configuration. > > For me above solution looks like a hack. It adds some module parameter > for tweaking configuration. And what would happen with that parameter > after we have "proper" support for multiple codecs? Do we need to > maintain backward compatibility? Or would we remove that configuration > and therefore revert to state prior existence of new module parameter > (which is current situation)? After your patches there's still the "automatic bitpool" mode available, right? To me it seems that the new option discussed here would still be useful, if there are users who prefer to use the automatic bitpool mode. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 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 legacy bitpool during negociation) > > > > The remaining (1% ?) : will need a simple boolean swicth in one of > > the PA config files to restrict negociation to legacy bitpool (a > > module option ? or daemon.conf ?). > > > > I think it's really "simple", efficient, and not dependent of any > > upcoming Bluez feature. > > > > "The complex solution is always the best until one find a simpler one" > > I don't know the number of users who use bluetooth headsets with > PulseAudio, but even just 1% regression rate can mean quite a few > unhappy users. When your headset suddenly stops working, it's not > trivial to figure out that you may need to pass a special argument to > module-bluetooth-discover in order to make it work again. > > It would be better to have a module argument to enable the XQ settings. Main question, do we really need this special "settings"? Because my patch series introduce also SBC XQ profile and basically replaces above module parameter, by runtime configuration. For me above solution looks like a hack. It adds some module parameter for tweaking configuration. And what would happen with that parameter after we have "proper" support for multiple codecs? Do we need to maintain backward compatibility? Or would we remove that configuration and therefore revert to state prior existence of new module parameter (which is current situation)? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 loads module-bluez5-discover, and the module argument needs to be added there too. Finally, module-bluez5-discover loads module-bluez5-device, which is the place where the option is actually used. The module argument needs to be added to all three modules. By the way, most technical mailing lists, including this one, prefer the interleaved reply style: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style -- Tanu > 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 the "XQ max negociated bitpool" > > (my patch). > > > > This way it's less likely to cause regressions than Pali's "forced > > bitpool" XQ modes : by default PA behaves like current version. > > > > And it doesn't rely on future Bluez features. > > > > Jp > > > > 14:29, 18 octobre 2019, "Tanu Kaskinen" : > > > 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 mode, and some in legacy mode because they will fall > > > > back to legacy bitpool during negociation) > > > > > > > > The remaining (1% ?) : will need a simple boolean swicth in one of > > > > the PA config files to restrict negociation to legacy bitpool (a > > > > module option ? or daemon.conf ?). > > > > > > > > I think it's really "simple", efficient, and not dependent of any > > > > upcoming Bluez feature. > > > > > > > > "The complex solution is always the best until one find a simpler one" > > > > > > I don't know the number of users who use bluetooth headsets with > > > PulseAudio, but even just 1% regression rate can mean quite a few > > > unhappy users. When your headset suddenly stops working, it's not > > > trivial to figure out that you may need to pass a special argument to > > > module-bluetooth-discover in order to make it work again. > > > > > > It would be better to have a module argument to enable the XQ settings. > > > > > > -- > > > Tanu > > > > > > https://www.patreon.com/tanuk > > > https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
