Re: [pulseaudio-discuss] [PATCH v15 10/10] bluetooth: Add more variants of SBC codec
Hi, v15 works, as expected : 90% of the time. As already discussed (for too long) : forcing bitpools for XQ modes is not a good idea, and doesn't work with all speakers. bitpool must always be negotiated : for standard "high quality" mode AND for xq MODES. My patch, available since months : already implement XQ this way (many too simple ?), and it never failed with any BT speaker or headphone : it provides XQ when negocieted bitpools are possible for the receiver : mostly always. JP 15.04.2020, 21:07, "Pali Rohár" :Specify configuration for Low, Middle, High and eXtreme Quality of SBCcodec. SBC codec in eXtreme Quality has higher quality than aptX.Automatic Quality mode matches configuration of SBC codec which was usedbefore this change. Which means that it accept configuration between Lowand High quality.Current SBC code was extended to allow definitions of arbitraryconfiguration variants of SBC codec parameters.SBC XQ testing is in following article:http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec--- src/modules/bluetooth/a2dp-codec-sbc.c | 655 +++- src/modules/bluetooth/a2dp-codec-util.c | 18 +- 2 files changed, 534 insertions(+), 139 deletions(-)diff --git a/src/modules/bluetooth/a2dp-codec-sbc.c b/src/modules/bluetooth/a2dp-codec-sbc.cindex ba47fa066..f275586ef 100644--- a/src/modules/bluetooth/a2dp-codec-sbc.c+++ b/src/modules/bluetooth/a2dp-codec-sbc.c@@ -36,8 +36,71 @@ #include "a2dp-codec-api.h" #include "rtp.h"-#define SBC_BITPOOL_DEC_LIMIT 32-#define SBC_BITPOOL_DEC_STEP 5+/* Below are capabilities tables for different qualities. Order of capabilities in tables are from the most preferred to the least preferred. */++#define FIXED_SBC_CAPS(mode, freq, bitpool) { .channel_mode = (mode), .frequency = (freq), .min_bitpool = (bitpool), .max_bitpool = (bitpool), .allocation_method = SBC_ALLOCATION_LOUDNESS, .subbands = SBC_SUBBANDS_8, .block_length = SBC_BLOCK_LENGTH_16 }++/* SBC Low Quality, Joint Stereo is same as FastStream's SBC codec configuration, Mono was calculated to match Joint Stereo */+static const a2dp_sbc_t sbc_lq_caps_table[] = {+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_44100, 29), /* 195.7 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_48000, 29), /* 213 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_44100, 15), /* 104.7 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_48000, 15), /* 114 kbps */+};++/* SBC Middle Quality, based on A2DP spec: Recommended sets of SBC parameters */+static const a2dp_sbc_t sbc_mq_caps_table[] = {+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_44100, SBC_BITPOOL_MQ_JOINT_STEREO_44100), /* bitpool = 35, 228.8 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_48000, SBC_BITPOOL_MQ_JOINT_STEREO_48000), /* bitpool = 33, 237 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_44100, SBC_BITPOOL_MQ_MONO_44100), /* bitpool = 19, 126.8 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_48000, SBC_BITPOOL_MQ_MONO_48000), /* bitpool = 18, 132 kbps */+};++/* SBC High Quality, based on A2DP spec: Recommended sets of SBC parameters */+static const a2dp_sbc_t sbc_hq_caps_table[] = {+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_44100, SBC_BITPOOL_HQ_JOINT_STEREO_44100), /* bitpool = 53, 328 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_48000, SBC_BITPOOL_HQ_JOINT_STEREO_48000), /* bitpool = 51, 345 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_44100, SBC_BITPOOL_HQ_MONO_44100), /* bitpool = 31, 192.9 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_48000, SBC_BITPOOL_HQ_MONO_48000), /* bitpool = 29, 210 kbps */+};++/* SBC eXtreme Quality, calculated to minimize wasted bytes for EDR-2 and to+ * be below max possible 512 kbps. In most cases bluetooth headsets would+ * support only sbc dual channel mode for 2 channels as they have limited+ * maximal bitpool value to 53. We need to define it in two tables to disallow+ * invalid combination of joint stereo with bitpool 38 which is not XQ. */+static const a2dp_sbc_t sbc_xq1_caps_table[] = {+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_44100, 76), /* 454.8 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_48000, 76), /* 495 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_STEREO, SBC_SAMPLING_FREQ_44100, 76), /* 452 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_STEREO, SBC_SAMPLING_FREQ_48000, 76), /* 492 kbps */+};+static const a2dp_sbc_t sbc_xq2_caps_table[] = {+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_DUAL_CHANNEL, SBC_SAMPLING_FREQ_44100, 38), /* 452 kbps */+FIXED_SBC_CAPS(SBC_CHANNEL_MODE_DUAL_CHANNEL, SBC_SAMPLING_FREQ_48000, 38), /* 492 kbps
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
The dev team seems to be more concerned about discussing about doc and concepts for decades, than implementing a well engineered, simple, efficient, and reliable solution.Meanwhile thousands users are using my SBC XQ patch and nobody reported any problem : for a good reason: it's simple enough to be reliable.I hope you will manage to merge Pali's patch set before 2030.I have to remind you about reality: Bluetooth and DLNA are the way 90% of the people are listening to music in 2020. Everything else can be delayed.Oups : sorry, there's no DLNA support at all in Pulseaudio. .. so it's maybe time to start implememting it before PA version 0.1 ? Oups we passed version 0.1 without wireless audio support worth a Black Mirror episode ?Jp13:57, 9 décembre 2019, Hyperion :09.12.2019, 12:33, "Andrey Semashev" <andrey.semas...@gmail.com>: I have another piece of feedback to provide. Sometimes I experience audio dropouts. Sometimes in both left and right headphones, sometimes just one. In particular, I noticed this happen when I have a Bluetooth-connected DualShock 4 gamepad connected and playing games, but it also happens without it, although less often. I assume this is caused by Bluetooth bandwidth limitation. Note that EOZ Air are "truly wireless" (i.e. the two headphones connect wirelessly), and I have multiple WiFi networks available (one access point in the same room as the Bluetooth transmitter, a few others behind walls). I expect 2.4 GHz radio to be rather crowded. The gamepad and the headphones are in the same room as the Bluetooth transmitter, in clear direct visibility, so it can't get better than that. I can see Pali's patches offer reduce_encoder_bitrate API that is supposed to mitigate this problem, but both SBC XQ profiles don't allow bitrate reduction. I think, SBC XQ desperately needs to support bitrate reduction, as the codec with the highest bitrate out of all.Yes, and my patch was providing 100% adaptative SBC XQ, with native bitpool reduction, as you suggest. But something more complex and yet more "static"' has been preferred. Users might actually have reduced experience due to audio dropouts compared to the previously supported SBC HQ. On 2019-12-07 21:09, Andrey Semashev wrote: FWIW, I tested the patch[1] from your github repository with PulseAudio 13.0 on Ubuntu 19.10 with my EOZ Air. It works, and the sound quality is subjectively better compared to the stock PA 13.0. The noise level that can be heard on silent audio sections seems to be lower. However, I can still hear compression artefacts on quiet or nearly silent audio sections, which sound like high-pitch squeaking sounds. It can often be heard on various music fade out sections. I don't know if this is inherrent from SBC codec itself or is a deficiency of libsbc implementation, or the headphones. These artefacts are my main complaint about SBC. My EOZ Air also supports AAC, and the audio quality is better still with it (I tested with pulseaudio-modules-bt[2] and my Android phone). There are no squeaky artefacts with AAC. Which brings me to my question to PA developers. Would an addition of support for AAC be possible? pulseaudio-modules-bt uses libfdk-aac to implement AAC, and if possible, I would prefer that library as it provides the best quality available on Linux. However, if licensing is an issue, there is also a built-in implementation in ffmpeg. [1]: Patch obtained with `git diff 200618b32f0964a479d69c9b6e5073e6931c370a..0853d7465729c1fb6c25745c05dc749a1b9a8d6f` [2]: https://github.com/EHfive/pulseaudio-modules-bt On 2019-09-20 12:45, Hyperion wrote: HI, I have reworked my mod so that it can safely achieve bitpool 94 in both dual channel and joint stereo, as long as the device supports it (only my high end Harman Kardon support 94 in joint stereo). Devices supporting only bitpool 53 are kept safe (bitpool is always negociated, never forced : this doesn't use fixed caps). Anyway most devices support at least bitpool 47 in dual channel mode, and BT (version 3 and up) bandwidth is much higher : so this patch deprecates both APTX and LDAC. The Git is up to date : https://github.com/JPGuillemin/pulseaudio This patch is likely safe to be applied on the official master cause it doesn't need Bluez multi-codec API, and doesn't introduce any patent issue (mainly from CSR, openaptx being underground reverse ingeniering). All the best JP 19.09.2019, 13:07, "Hyperion" <h1p8r...@yandex.com>: The Git branch with my mods : https://github.com/JPGuillemin/pulseaudio/tree/SBC-XQ I'm sure it needs improvement, but I need testers ;) for now it works as expected on all my devices... JP 19.09.2019, 11:21, "Hyperion" <h1p8r...@yandex.com>:Yes, thanks, you're right, I'm going to do it as soon as I get enough testing feedback.Talking about tests : I'm going to switch back to Pali's default values for announced bitpoo
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
09.12.2019, 12:47, "Andrey Semashev" : > On 2019-12-09 14:39, Pali Rohár wrote: >> On Monday 09 December 2019 14:32:52 Andrey Semashev wrote: >>> I have another piece of feedback to provide. Sometimes I experience audio >>> dropouts. Sometimes in both left and right headphones, sometimes just one. >>> In particular, I noticed this happen when I have a Bluetooth-connected >>> DualShock 4 gamepad connected and playing games, but it also happens >>> without >>> it, although less often. >>> >>> I assume this is caused by Bluetooth bandwidth limitation. Note that EOZ >>> Air >>> are "truly wireless" (i.e. the two headphones connect wirelessly), and I >>> have multiple WiFi networks available (one access point in the same room as >>> the Bluetooth transmitter, a few others behind walls). I expect 2.4 GHz >>> radio to be rather crowded. The gamepad and the headphones are in the same >>> room as the Bluetooth transmitter, in clear direct visibility, so it can't >>> get better than that. >> >> Yes, 2.4 GHz is shared by both Bluetooth and WiFi, so it may be a >> problem. >> >>> I can see Pali's patches offer reduce_encoder_bitrate API that is supposed >>> to mitigate this problem, but both SBC XQ profiles don't allow bitrate >>> reduction. >> >> Yes, SBC XQ is there the highest available quality profile of SBC. >> >>> I think, SBC XQ desperately needs to support bitrate reduction, >> >> No, this is main reason for usage of SBC XQ it is high quality codec. >> SBC XQ needs high bitrate by its definition. >> >>> as the codec with the highest bitrate out of all. Users might actually have >>> reduced experience due to audio dropouts compared to the previously >>> supported SBC HQ. >> >> If you cannot use high bitrate codecs, then do not use high bitrate >> codecs. There are other profiles of SBC which lower bitpool value and >> therefore lower bitrate. E.g. SBC MQ or SBC LQ (medium and low quality). >> >> Or you can use SBC in automatic mode where bitrate is automatically >> decreased. > > As a user, I don't know whether I can use SBC XQ. I don't know whether > its bitrate will fit in my radio conditions. If my device happens to > support SBC XQ, that is the codec that will get picked upon connection. > Please, correct me if I'm wrong, but I don't see a way to influence that. > > SBC XQ is high quality and high bitrate, true, but PA should adapt to > the actual use conditions. More so if it actually has the means to do > so. If PA detects that SBC XQ does not fit in BT bandwidth, it should > gradually drop quality. Please take a look at the many discussions, experiments, specifications analysis and calculations about SBC XQ, before posting this kind of complaint. You make devs waste a lot of time at this point of implementation. > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
09.12.2019, 12:33, "Andrey Semashev" : > I have another piece of feedback to provide. Sometimes I experience > audio dropouts. Sometimes in both left and right headphones, sometimes > just one. In particular, I noticed this happen when I have a > Bluetooth-connected DualShock 4 gamepad connected and playing games, but > it also happens without it, although less often. > > I assume this is caused by Bluetooth bandwidth limitation. Note that EOZ > Air are "truly wireless" (i.e. the two headphones connect wirelessly), > and I have multiple WiFi networks available (one access point in the > same room as the Bluetooth transmitter, a few others behind walls). I > expect 2.4 GHz radio to be rather crowded. The gamepad and the > headphones are in the same room as the Bluetooth transmitter, in clear > direct visibility, so it can't get better than that. > > I can see Pali's patches offer reduce_encoder_bitrate API that is > supposed to mitigate this problem, but both SBC XQ profiles don't allow > bitrate reduction. I think, SBC XQ desperately needs to support bitrate > reduction, as the codec with the highest bitrate out of all. Yes, and my patch was providing 100% adaptative SBC XQ, with native bitpool reduction, as you suggest. But something more complex and yet more "static"' has been preferred. Users might > actually have reduced experience due to audio dropouts compared to the > previously supported SBC HQ. > > On 2019-12-07 21:09, Andrey Semashev wrote: >> FWIW, I tested the patch[1] from your github repository with PulseAudio >> 13.0 on Ubuntu 19.10 with my EOZ Air. It works, and the sound quality is >> subjectively better compared to the stock PA 13.0. The noise level that >> can be heard on silent audio sections seems to be lower. >> >> However, I can still hear compression artefacts on quiet or nearly >> silent audio sections, which sound like high-pitch squeaking sounds. It >> can often be heard on various music fade out sections. I don't know if >> this is inherrent from SBC codec itself or is a deficiency of libsbc >> implementation, or the headphones. These artefacts are my main complaint >> about SBC. >> >> My EOZ Air also supports AAC, and the audio quality is better still with >> it (I tested with pulseaudio-modules-bt[2] and my Android phone). There >> are no squeaky artefacts with AAC. >> >> Which brings me to my question to PA developers. Would an addition of >> support for AAC be possible? >> >> pulseaudio-modules-bt uses libfdk-aac to implement AAC, and if possible, >> I would prefer that library as it provides the best quality available on >> Linux. However, if licensing is an issue, there is also a built-in >> implementation in ffmpeg. >> >> [1]: Patch obtained with `git diff >> >> 200618b32f0964a479d69c9b6e5073e6931c370a..0853d7465729c1fb6c25745c05dc749a1b9a8d6f` >> >> [2]: https://github.com/EHfive/pulseaudio-modules-bt >> >> On 2019-09-20 12:45, Hyperion wrote: >>> HI, >>> >>> I have reworked my mod so that it can safely achieve bitpool 94 in >>> both dual channel and joint stereo, as long as the device supports it >>> (only my high end Harman Kardon support 94 in joint stereo). >>> Devices supporting only bitpool 53 are kept safe (bitpool is always >>> negociated, never forced : this doesn't use fixed caps). >>> >>> Anyway most devices support at least bitpool 47 in dual channel mode, >>> and BT (version 3 and up) bandwidth is much higher : so this patch >>> deprecates both APTX and LDAC. >>> >>> The Git is up to date : https://github.com/JPGuillemin/pulseaudio >>> >>> This patch is likely safe to be applied on the official master cause >>> it doesn't need Bluez multi-codec API, and doesn't introduce any >>> patent issue (mainly from CSR, openaptx being underground reverse >>> ingeniering). >>> >>> All the best >>> JP >>> >>> 19.09.2019, 13:07, "Hyperion" : >>>> The Git branch with my mods : >>>> https://github.com/JPGuillemin/pulseaudio/tree/SBC-XQ >>>> >>>> I'm sure it needs improvement, but I need testers ;) for now it works >>>> as expected on all my devices... >>>> >>>> JP >>>> >>>> 19.09.2019, 11:21, "Hyperion" : >>>>> Yes, thanks, you're right, I'm going to do it as soon as I get >>>>> enough testing feedback. >>>>> >>>>> Talking about tests
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
09.12.2019, 12:57, "Pali Rohár" : > On Monday 09 December 2019 14:47:26 Andrey Semashev wrote: >> As a user, I don't know whether I can use SBC XQ. I don't know whether its >> bitrate will fit in my radio conditions. If my device happens to support SBC >> XQ, that is the codec that will get picked upon connection. Please, correct >> me if I'm wrong, but I don't see a way to influence that. > > You can ask same question for aptX-HD codec. It has also fixed high > bitrate. > >> SBC XQ is high quality and high bitrate, true, but PA should adapt to the >> actual use conditions. > > SBC XQ is defined with usage of one specific bitpool value. > >> More so if it actually has the means to do so. If PA >> detects that SBC XQ does not fit in BT bandwidth, it should gradually drop >> quality. > > Maybe we can implement disconnecting SBC XQ profile when problem happen > and connect again with SBC in Automatic quality. Which would already be covered if my suggestion of a config switch had been taken in consideration ;) And all this timeless discussion wouldn't happen... my 2 cents > > But there is another problem. People who chose high quality codec do not > want to see that application itself without their instruction decide to > change codec to low quality. This is reason why non-SBC codecs are used. > Because they provide one fixed quality which is same whatever bluetooth > adapter or headphone you will use. SBC is criticized for a long time > because current implementations automatically choose some quality which > is not under user control. So for these reasons there is SBC LQ, MQ, HQ > and XQ. You can choose what you want to use. By default is automatic > mode which decreasing quality. > > -- > Pali Rohár > pali.ro...@gmail.com > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ___ 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
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, 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 A2DP stream or not. Pali wrote earlier: > > For established connection, bluetooth packet size is fixed. SBC > packet size depends on SBC bitpool (and other) parameters. And > because pulseaudio does not support generating fragmented SBC > packets, it can only fill those SBC frames which fits into > bluetooth packet size. > > That sounded like reducing the bitpool and therefore the SBC packet > size mid-stream wouldn't help, because the lower level bluetooth packet > size is constant for the duration of the stream. However, if the > bluetooth packet size dynamically reacts to changes in the SBC packet > sizes, then reducing the bitpool mid-stream is useful. Can someone > confirm which it is? > > -- > 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
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: >> >> >> 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, 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 >> >> >&g
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 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? >&
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 +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 >> &
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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: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. >>> > &g
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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, 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. > > If the "enab
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
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 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" <ta...@iki.fi>: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 withPulseAudio, but even just 1% regression rate can mean quite a fewunhappy users. When your headset suddenly stops working, it's nottrivial to figure out that you may need to pass a special argument tomodule-bluetooth-discover in order to make it work again.It would be better to have a module argument to enable the XQ settings. --Tanuhttps://www.patreon.com/tanukhttps://liberapay.com/tanuk --Sent from Yandex.Mail for mobile,___pulseaudio-discuss mailing listpulseaudio-discuss@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss___ 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
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.Jp14: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 withPulseAudio, but even just 1% regression rate can mean quite a fewunhappy users. When your headset suddenly stops working, it's nottrivial to figure out that you may need to pass a special argument tomodule-bluetooth-discover in order to make it work again.It would be better to have a module argument to enable the XQ settings.-- Tanuhttps://www.patreon.com/tanukhttps://liberapay.com/tanuk-- Sent from Yandex.Mail for mobile___ 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
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" Just my 2 cents JP 17.10.2019, 15:14, "Pali Rohár" : > 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 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 these devices and therefore regressions. >> > > > >> > > > As Automatic SBC profile is the only one available for systems where >> > > > codec switching is not supported, it would mean complete regression as >> > > > these devices completely stops working on those systems. >> > > > >> > > > Upgrading either pulseaudio or bluez must not lead to problem that >> some >> > > > bluetooth devices stop working (if they worked before upgrade). >> > > > >> > > > So no, there would not be any changes in Automatic SBC profile. This >> one >> > > > should stay untouched, to make it always working with all existing >> > > > devices without any regression. >> > > >> > > I wasn't aware that advertising the XQ settings during negotiation >> > > breaks some devices. I guess this means that JP Guillaume's SBC XQ >> > > patch can't be accepted, assuming that we value avoiding regressions >> > > more than the improved quality for most headsets? >> > >> > In this patch series I'm reworking and proposing also XQ profiles at >> > separate endpoints. So in case XQ is broken for paricular device, with >> > codec switching API, user would be able to switch back to automatic SBC >> > profile (on different SEP) which should stay as it is in current >> > version, which is working with all devices. >> >> Yes, but what about JP Guillaume's patch, which is a simple way of >> achieving XQ support before your patches have been accepted? I planned >> to review it first (because he asked), but now it looks like that may >> not be a good idea (I don't want regressions). > > With that "simple way" patch there would be regressions for "broken" > devices. That is the reason why codec switching from bluez side is > needed and having separate SEPs for XQ. So Automatic profile (current > one) could be freezed and would be used like before for all devices. > >> > > Here's that patch: >> > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177 >> > > > > -- > 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
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 README of my patch : in case the device can't do XQ : PA falls back to legacy bitpool. JP14:52, 17 octobre 2019, "Tanu Kaskinen" :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 in Automatic SBC profile would lead to broken support for these devices and therefore regressions. As Automatic SBC profile is the only one available for systems where codec switching is not supported, it would mean complete regression as these devices completely stops working on those systems. Upgrading either pulseaudio or bluez must not lead to problem that some bluetooth devices stop working (if they worked before upgrade). So no, there would not be any changes in Automatic SBC profile. This one should stay untouched, to make it always working with all existing devices without any regression.I wasn't aware that advertising the XQ settings during negotiationbreaks some devices. I guess this means that JP Guillaume's SBC XQpatch can't be accepted, assuming that we value avoiding regressionsmore than the improved quality for most headsets?Here's that patch: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177-- Tanuhttps://www.patreon.com/tanukhttps://liberapay.com/tanuk-- Sent from Yandex.Mail for mobile___ 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
Will test12:06, 17 octobre 2019, "Pali Rohár" :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 activatedMay I ask for review at least for these first 4 patches?-- Pali Rohárpali.ro...@gmail.com___pulseaudio-discuss mailing listpulseaudio-discuss@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss-- Sent from Yandex.Mail for mobile___ 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
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 have a proposal : IMHO : what could be a good compromise would be to keep the Automatic mode that you already implemented it as DEFAULT, calling it "Legacy Automatic" or so. AND add an alternative Automatic mode called "XQ Automatic" (following negotiation strategy similar to my patch). This secondary Automatic mode could replace "forced bitpool" modes. If you really want to keep forced bitpool modes, it doesn't hurt, btw. All the bestJP 08.10.2019, 18:52, "Hyperion" :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. Jp 18:29, 8 octobre 2019, "Pali Rohár" <pali.ro...@gmail.com>:Automatic SBC profile is not going to be changed. It is there to supportall devices without any tweaks. ValdikSS already did more tests andthere are devices which do not work with higher SBC bitpool. Soincreasing max value of bitpool in Automatic SBC profile would lead tobroken support for these devices and therefore regressions.As Automatic SBC profile is the only one available for systems wherecodec switching is not supported, it would mean complete regression asthese devices completely stops working on those systems.Upgrading either pulseaudio or bluez must not lead to problem that somebluetooth devices stop working (if they worked before upgrade).So no, there would not be any changes in Automatic SBC profile. This oneshould stay untouched, to make it always working with all existingdevices without any regression.On Monday 07 October 2019 16:27:19 Hyperion wrote: 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" <pali.ro...@gmail.com>: > 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 functionality which were introduced in 5.51 > together with fixed more A2DP related bugs. Instead of workarounding > bluez bugs, just to use working one stable SBC codec like before OR > update bluez to new version and have new features. > > On Monday 07 October 2019 16:18:21 Hyperion wrote: >> 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" <pali.ro...@gmail.com>: >> > 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/functional changes in pulseaudio >> > when older bluez version is in use. So also no change in automatic mode >> > for older bluez versions. >> > >> > On Monday 07 October 2019 15:30:49 Hyperion wrote: >> >> 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 my latest patch https://gitlab.freedesktop.org/Hyperion/pulseaudio/tree/SBC-XQ >> >> >> >> jp >> >> >> >> 07.10.2019, 15:25, "Pali Rohár" <pali.ro...@gmail.com>: >> >> > 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 pa
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 octobre 2019, "Pali Rohár" :Automatic SBC profile is not going to be changed. It is there to supportall devices without any tweaks. ValdikSS already did more tests andthere are devices which do not work with higher SBC bitpool. Soincreasing max value of bitpool in Automatic SBC profile would lead tobroken support for these devices and therefore regressions.As Automatic SBC profile is the only one available for systems wherecodec switching is not supported, it would mean complete regression asthese devices completely stops working on those systems.Upgrading either pulseaudio or bluez must not lead to problem that somebluetooth devices stop working (if they worked before upgrade).So no, there would not be any changes in Automatic SBC profile. This oneshould stay untouched, to make it always working with all existingdevices without any regression.On Monday 07 October 2019 16:27:19 Hyperion wrote: 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" <pali.ro...@gmail.com>: > 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 functionality which were introduced in 5.51 > together with fixed more A2DP related bugs. Instead of workarounding > bluez bugs, just to use working one stable SBC codec like before OR > update bluez to new version and have new features. > > On Monday 07 October 2019 16:18:21 Hyperion wrote: >> 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" <pali.ro...@gmail.com>: >> > 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/functional changes in pulseaudio >> > when older bluez version is in use. So also no change in automatic mode >> > for older bluez versions. >> > >> > On Monday 07 October 2019 15:30:49 Hyperion wrote: >> >> 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 my latest patch https://gitlab.freedesktop.org/Hyperion/pulseaudio/tree/SBC-XQ >> >> >> >> jp >> >> >> >> 07.10.2019, 15:25, "Pali Rohár" <pali.ro...@gmail.com>: >> >> > 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 October 2019 15:20:35 Hyperion wrote: >> >> >> 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" <pali.ro...@gmail.com>: >> >> >> > 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
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 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 functionality which were introduced in 5.51 > together with fixed more A2DP related bugs. Instead of workarounding > bluez bugs, just to use working one stable SBC codec like before OR > update bluez to new version and have new features. > > On Monday 07 October 2019 16:18:21 Hyperion wrote: >> 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 --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/functional changes in pulseaudio >> > when older bluez version is in use. So also no change in automatic mode >> > for older bluez versions. >> > >> > On Monday 07 October 2019 15:30:49 Hyperion wrote: >> >> 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 my latest patch >> https://gitlab.freedesktop.org/Hyperion/pulseaudio/tree/SBC-XQ >> >> >> >> jp >> >> >> >> 07.10.2019, 15:25, "Pali Rohár" : >> >> > 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 October 2019 15:20:35 Hyperion wrote: >> >> >> 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 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 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: transaction 9 nsp 0x00 >> >> >> >> > AVDTP(s): Discover rsp: transaction 9 nsp 0x00 >> >> >> >> ACP SEID 1 - Audio Sink >> >> >> >> ACP SEID 2 - Audio Sink >> >> >> >> ACP SEID 3 - Audio Sink >> >> >> >> < AVDTP(s): Set config cmd: transaction 10 nsp 0x00 >
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 --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/functional changes in pulseaudio > when older bluez version is in use. So also no change in automatic mode > for older bluez versions. > > On Monday 07 October 2019 15:30:49 Hyperion wrote: >> 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 my latest patch >> https://gitlab.freedesktop.org/Hyperion/pulseaudio/tree/SBC-XQ >> >> jp >> >> 07.10.2019, 15:25, "Pali Rohár" : >> > 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 October 2019 15:20:35 Hyperion wrote: >> >> 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 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 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: transaction 9 nsp 0x00 >> >> >> > AVDTP(s): Discover rsp: transaction 9 nsp 0x00 >> >> >> ACP SEID 1 - Audio Sink >> >> >> ACP SEID 2 - Audio Sink >> >> >> ACP SEID 3 - Audio Sink >> >> >> < AVDTP(s): Set config cmd: transaction 10 nsp 0x00 >> >> >> ACP SEID 1 - INT SEID 2 >> >> >> Media Transport >> >> >> Media Codec - SBC >> >> >> 44.1kHz >> >> >> DualChannel >> >> >> 16 Blocks >> >> >> 8 Subbands >> >> >> Loudness >> >> >> Bitpool Range 38-38 >> >> >> > AVDTP(s): Set config rsp: transaction 10 nsp 0x00 >> >> >> < AVDTP(s): Open cmd: transaction 11 nsp 0x00 >> >> >> ACP SEID 1 >> >> >> > AVDTP(s): Open rsp: transaction 11 nsp 0x00 >> >> >> >> >> >> 06.10.2019, 19:59, "Pali Rohár" : >> >> >> > 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. >> >> >> > FastStream codec) as it has better audio quality. >> >> >> > --- >> >> >> > src/modules/bluetooth/module-bluetooth-
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 my latest patch
https://gitlab.freedesktop.org/Hyperion/pulseaudio/tree/SBC-XQ
jp
07.10.2019, 15:25, "Pali Rohár" :
> 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 October 2019 15:20:35 Hyperion wrote:
>> 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 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 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: transaction 9 nsp 0x00
>> >> > AVDTP(s): Discover rsp: transaction 9 nsp 0x00
>> >> ACP SEID 1 - Audio Sink
>> >> ACP SEID 2 - Audio Sink
>> >> ACP SEID 3 - Audio Sink
>> >> < AVDTP(s): Set config cmd: transaction 10 nsp 0x00
>> >> ACP SEID 1 - INT SEID 2
>> >> Media Transport
>> >> Media Codec - SBC
>> >> 44.1kHz
>> >> DualChannel
>> >> 16 Blocks
>> >> 8 Subbands
>> >> Loudness
>> >> Bitpool Range 38-38
>> >> > AVDTP(s): Set config rsp: transaction 10 nsp 0x00
>> >> < AVDTP(s): Open cmd: transaction 11 nsp 0x00
>> >> ACP SEID 1
>> >> > AVDTP(s): Open rsp: transaction 11 nsp 0x00
>> >>
>> >> 06.10.2019, 19:59, "Pali Rohár" :
>> >> > 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.
>> >> > FastStream codec) as it has better audio quality.
>> >> > ---
>> >> > src/modules/bluetooth/module-bluetooth-policy.c | 123
>>
>> >> > 1 file changed, 62 insertions(+), 61 deletions(-)
>> >> >
>> >> > diff --git a/src/modules/bluetooth/module-bluetooth-policy.c
>> b/src/modules/bluetooth/module-bluetooth-policy.c
>> >> > index 04313aa84..9652a91fe 100644
>> >> > --- a/src/modules/bluetooth/module-bluetooth-policy.c
>> >> > +++ b/src/modules/bluetooth/module-bluetooth-policy.c
>> >> > @@ -59,7 +59,12 @@ struct userdata {
>> >> > pa_hook_slot *card_init_profile_slot;
>> >> > pa_hook_slot *card_unlink_slot;
>> >> > pa_hook_slot *profile_available_changed_slot;
>> >> > - pa_hashmap *will_need_revert_card_map;
>> >> > + pa_hashmap *profile_switch_map;
>> >> > +};
>> >> > +
>> >> > +struct profile_switch {
>> >> > + const char *from_profile;
>> >> > + const char *to_profile;
>> >> > };
>> >> >
>> >> > /* When a source is created, loopback it to default sink */
>> >> > @@ -142,43 +147,57 @@ static pa_hook_result_t
>> sink_put_hook_callback(pa_core *c, pa_sink *sink, void *
>> >> > return PA_HOOK_OK;
>> >> > }
>> >> >
>> >> > -static void
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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 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 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: transaction 9 nsp 0x00
>> > AVDTP(s): Discover rsp: transaction 9 nsp 0x00
>> ACP SEID 1 - Audio Sink
>> ACP SEID 2 - Audio Sink
>> ACP SEID 3 - Audio Sink
>> < AVDTP(s): Set config cmd: transaction 10 nsp 0x00
>> ACP SEID 1 - INT SEID 2
>> Media Transport
>> Media Codec - SBC
>> 44.1kHz
>> DualChannel
>> 16 Blocks
>> 8 Subbands
>> Loudness
>> Bitpool Range 38-38
>> > AVDTP(s): Set config rsp: transaction 10 nsp 0x00
>> < AVDTP(s): Open cmd: transaction 11 nsp 0x00
>> ACP SEID 1
>> > AVDTP(s): Open rsp: transaction 11 nsp 0x00
>>
>> 06.10.2019, 19:59, "Pali Rohár" :
>> > 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.
>> > FastStream codec) as it has better audio quality.
>> > ---
>> > src/modules/bluetooth/module-bluetooth-policy.c | 123
>>
>> > 1 file changed, 62 insertions(+), 61 deletions(-)
>> >
>> > diff --git a/src/modules/bluetooth/module-bluetooth-policy.c
>> b/src/modules/bluetooth/module-bluetooth-policy.c
>> > index 04313aa84..9652a91fe 100644
>> > --- a/src/modules/bluetooth/module-bluetooth-policy.c
>> > +++ b/src/modules/bluetooth/module-bluetooth-policy.c
>> > @@ -59,7 +59,12 @@ struct userdata {
>> > pa_hook_slot *card_init_profile_slot;
>> > pa_hook_slot *card_unlink_slot;
>> > pa_hook_slot *profile_available_changed_slot;
>> > - pa_hashmap *will_need_revert_card_map;
>> > + pa_hashmap *profile_switch_map;
>> > +};
>> > +
>> > +struct profile_switch {
>> > + const char *from_profile;
>> > + const char *to_profile;
>> > };
>> >
>> > /* When a source is created, loopback it to default sink */
>> > @@ -142,43 +147,57 @@ static pa_hook_result_t
>> sink_put_hook_callback(pa_core *c, pa_sink *sink, void *
>> > return PA_HOOK_OK;
>> > }
>> >
>> > -static void card_set_profile(struct userdata *u, pa_card *card, bool
>> revert_to_a2dp)
>> > -{
>> > +static void card_set_profile(struct userdata *u, pa_card *card, const
>> char *revert_to_profile_name) {
>> > + pa_card_profile *iter_profile;
>> > pa_card_profile *profile;
>> > + struct profile_switch *ps;
>> > + char *old_profile_name;
>> > void *state;
>> >
>> > - /* Find available profile and activate it */
>> > - PA_HASHMAP_FOREACH(profile, card->profiles, state) {
>> > - if (profile->available == PA_AVAILABLE_NO)
>> > - continue;
>> > -
>> > - /* Check for correct profile based on revert_to_a2dp */
>> > - if (revert_to_a2dp) {
>> > - if (!pa_startswith(profile->name, "a2dp_sink"))
>> > + if (revert_to_profile_name) {
>> > + profile = pa_hashmap_get(card->profiles, revert_to_profile_name);
>> > + } else {
>> > + /* Find highest priority profile with both sink and source */
>> > + profile = NULL;
>> > + PA_HASHMAP_FOREACH(iter_profile, card->profiles, state) {
>> > + if (iter_profile->available == PA_AVAILABLE_NO)
>> > continue;
>> > - } else {
>> > - if (!pa_streq(profile->name, "headset_head_unit"))
>> > + if (iter_profile->n_sources == 0 || iter_profile->n_sinks == 0)
>> >
Re: [pulseaudio-discuss] [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP
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: transaction 9 nsp 0x00
> AVDTP(s): Discover rsp: transaction 9 nsp 0x00
ACP SEID 1 - Audio Sink
ACP SEID 2 - Audio Sink
ACP SEID 3 - Audio Sink
< AVDTP(s): Set config cmd: transaction 10 nsp 0x00
ACP SEID 1 - INT SEID 2
Media Transport
Media Codec - SBC
44.1kHz
DualChannel
16 Blocks
8 Subbands
Loudness
Bitpool Range 38-38
> AVDTP(s): Set config rsp: transaction 10 nsp 0x00
< AVDTP(s): Open cmd: transaction 11 nsp 0x00
ACP SEID 1
> AVDTP(s): Open rsp: transaction 11 nsp 0x00
06.10.2019, 19:59, "Pali Rohár" :
> 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.
> FastStream codec) as it has better audio quality.
> ---
> src/modules/bluetooth/module-bluetooth-policy.c | 123
>
> 1 file changed, 62 insertions(+), 61 deletions(-)
>
> diff --git a/src/modules/bluetooth/module-bluetooth-policy.c
> b/src/modules/bluetooth/module-bluetooth-policy.c
> index 04313aa84..9652a91fe 100644
> --- a/src/modules/bluetooth/module-bluetooth-policy.c
> +++ b/src/modules/bluetooth/module-bluetooth-policy.c
> @@ -59,7 +59,12 @@ struct userdata {
> pa_hook_slot *card_init_profile_slot;
> pa_hook_slot *card_unlink_slot;
> pa_hook_slot *profile_available_changed_slot;
> - pa_hashmap *will_need_revert_card_map;
> + pa_hashmap *profile_switch_map;
> +};
> +
> +struct profile_switch {
> + const char *from_profile;
> + const char *to_profile;
> };
>
> /* When a source is created, loopback it to default sink */
> @@ -142,43 +147,57 @@ static pa_hook_result_t sink_put_hook_callback(pa_core
> *c, pa_sink *sink, void *
> return PA_HOOK_OK;
> }
>
> -static void card_set_profile(struct userdata *u, pa_card *card, bool
> revert_to_a2dp)
> -{
> +static void card_set_profile(struct userdata *u, pa_card *card, const char
> *revert_to_profile_name) {
> + pa_card_profile *iter_profile;
> pa_card_profile *profile;
> + struct profile_switch *ps;
> + char *old_profile_name;
> void *state;
>
> - /* Find available profile and activate it */
> - PA_HASHMAP_FOREACH(profile, card->profiles, state) {
> - if (profile->available == PA_AVAILABLE_NO)
> - continue;
> -
> - /* Check for correct profile based on revert_to_a2dp */
> - if (revert_to_a2dp) {
> - if (!pa_startswith(profile->name, "a2dp_sink"))
> + if (revert_to_profile_name) {
> + profile = pa_hashmap_get(card->profiles, revert_to_profile_name);
> + } else {
> + /* Find highest priority profile with both sink and source */
> + profile = NULL;
> + PA_HASHMAP_FOREACH(iter_profile, card->profiles, state) {
> + if (iter_profile->available == PA_AVAILABLE_NO)
> continue;
> - } else {
> - if (!pa_streq(profile->name, "headset_head_unit"))
> + if (iter_profile->n_sources == 0 || iter_profile->n_sinks == 0)
> continue;
> + if (!profile || profile->priority < iter_profile->priority)
> + profile = iter_profile;
> }
> + }
>
> - pa_log_debug("Setting card '%s' to profile '%s'", card->name,
> profile->name);
> + if (!profile) {
> + pa_log_warn("Could not find any suitable profile for card '%s'",
> card->name);
> + return;
> + }
>
> - if (pa_card_set_profile(card, profile, false) != 0) {
> - pa_log_warn("Could not set profile '%s'", profile->name);
> - continue;
> - }
> + old_profile_name = card->active_profile->name;
> +
> + pa_log_debug("Setting card '%s' from profile '%s' to profile '%s'",
> card->name, old_profile_name, profile->name);
>
> - /* When we are not in revert_to_a2dp phase flag this card for
> will_need_revert */
> - if (!revert_to_a2dp)
> - pa_hashmap_put(u->will_need_revert_card_map, card, PA_INT_TO_PTR(1));
> + if (pa_card_set_profile(card, profile, false) != 0) {
> + pa_log_warn("Could not set profile '%s'", profile->name);
> + return;
> + }
>
> - break;
> + /* When not reverting, store data for future reverting */
> + if (!revert_to_profile_name) {
> + ps = pa_xnew0(struct profile_switch, 1);
> + ps->from_profile = old_profile_name;
> + ps->to_profile = profile->name;
> + pa_hashmap_put(u->profile_switch_map, card, ps);
> }
> }
>
> /* Switch profile for one card */
> -static void switch_profile(pa_card *card, bool revert_to_a2dp, void
> *userdata) {
> +static void switch_profile(pa_card *card, bool revert, void *userdata) {
> struct userdata *u = userdata;
> + struct profile_switch *ps;
> + const char *from_profile;
> + const char *to_profile;
> const char *s;
>
>
Re: [pulseaudio-discuss] [PATCH v13 05/10] bluetooth: Add A2DP aptX and aptX HD codecs support
Not sure it's expired worlwide. In case it is, it's good news. Fine for me.10:28, 7 octobre 2019, "Pali Rohár" :If you mean EP0398973B1 then it is already expired. I'm not aware ofother patents covering aptX. So I think libopenaptx should be safe here.But I'm not lawyer and do not understand jurisdiction across wholeworld, but I guess it is same problem as with expired patents for MP3.Why should be prohibited to distribute clean room LGPL written code asbinary?On Monday 07 October 2019 10:11:39 Hyperion wrote: both libraries are comming from the same reverse-engineering of a PROPRIETARY PATENTED codec, and BOTH are subject to lawsuit in case it is widely distributed as binary. JP 07.10.2019, 10:06, "Pali Rohár" <pali.ro...@gmail.com>: > But that is something different. Look at commit message where is link to > correct library for building. > > On Monday 07 October 2019 10:05:52 Hyperion wrote: >> Sorry, I should have provided the link to the source GIT https://github.com/Arkq/openaptx >> >> JP >> >> 07.10.2019, 09:51, "Pali Rohár" <pali.ro...@gmail.com>: >> > On Monday 07 October 2019 09:47:21 Hyperion wrote: >> >> Quotig OpenAPTX Github README : >> >> "This project is for research purposes only. Without a proper license private and commercial usage might be a case of a patent infringement. If you are looking for a library, which can be installed and used legally (commercial, private and educational usage), go to the Qualcomm® aptX™ homepage and contact Qualcomm customer service." >> > >> > Sorry, but I have not found any such quotes in README file. >> > >> >> So APTX support MUST only be provided for researching purposes, and so it should remain an external patch, out of the main PA tree. >> >> >> >> All the best, >> >> >> >> The source code itself is licensed under the terms of the MIT license. However, compression algorithms are patented and licensed under the terms of a proprietary license. Hence, compilation and redistribution in a binary format is forbidden! >> > >> > Library is fully licensed under LGPLv2.1+, not under MIT. And there are >> > no proprietary parts. Maybe you are referring to different library? >> > >> >> 06.10.2019, 19:59, "Pali Rohár" <pali.ro...@gmail.com>: >> >> > This patch provides support for aptX and aptX HD codecs in bluetooth A2DP >> >> > profile. It uses open source LGPLv2.1+ licensed libopenaptx library which >> >> > can be found at https://github.com/pali/libopenaptx. >> >> > >> >> > aptX for s24 stereo samples provides fixed 6:1 compression ratio and >> >> > bitrate 352.8 kbit/s, aptX HD provides fixed 4:1 compression ratio and >> >> > bitrate 529.2 kbit/s. >> >> > >> >> > According to soundexpert research, aptX codec used in bluetooth A2DP is no >> >> > better than SBC High Quality settings. And you cannot hear difference >> >> > between aptX and SBC High Quality, aptX is just a copper-less overpriced >> >> > audio cable. >> >> > >> >> > aptX HD is high-bitrate version of aptX. It has clearly noticeable increase >> >> > in sound quality (not dramatic though taking into account the increase in >> >> > bitrate). >> >> > >> >> > http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx >> >> > --- >> >> > configure.ac | 36 +++ >> >> > src/Makefile.am | 6 + >> >> > src/modules/bluetooth/a2dp-codec-aptx.c | 479 >> >> > src/modules/bluetooth/a2dp-codec-util.c | 8 + >> >> > 4 files changed, 529 insertions(+) >> >> > create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c >> >> > >> >> > diff --git a/configure.ac b/configure.ac >> >> > index 8278353d4..26c625a59 100644 >> >> > --- a/configure.ac >> >> > +++ b/configure.ac >> >> > @@ -1118,6 +1118,40 @@ AC_SUBST(HAVE_BLUEZ_5_NATIVE_HEADSET) >> >> > AM_CONDITIONAL([HAVE_BLUEZ_5_NATIVE_HEADSET], [test "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = x1]) >> >> > AS_IF([test "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = "x1"], AC_DEFINE([HAVE_BLUEZ_5_NATIVE_HEADSET], 1, [Bluez 5 native headset backend enabled])) >> >> > >> >> > + Bluetooth A2DP aptX codec (optional) ### >> >&
Re: [pulseaudio-discuss] [PATCH v13 05/10] bluetooth: Add A2DP aptX and aptX HD codecs support
both libraries are comming from the same reverse-engineering of a PROPRIETARY PATENTED codec, and BOTH are subject to lawsuit in case it is widely distributed as binary. JP 07.10.2019, 10:06, "Pali Rohár" : > But that is something different. Look at commit message where is link to > correct library for building. > > On Monday 07 October 2019 10:05:52 Hyperion wrote: >> Sorry, I should have provided the link to the source GIT >> https://github.com/Arkq/openaptx >> >> JP >> >> 07.10.2019, 09:51, "Pali Rohár" : >> > On Monday 07 October 2019 09:47:21 Hyperion wrote: >> >> Quotig OpenAPTX Github README : >> >> "This project is for research purposes only. Without a proper license >> private and commercial usage might be a case of a patent infringement. If >> you are looking for a library, which can be installed and used legally >> (commercial, private and educational usage), go to the Qualcomm® aptX™ >> homepage and contact Qualcomm customer service." >> > >> > Sorry, but I have not found any such quotes in README file. >> > >> >> So APTX support MUST only be provided for researching purposes, and so >> it should remain an external patch, out of the main PA tree. >> >> >> >> All the best, >> >> >> >> The source code itself is licensed under the terms of the MIT license. >> However, compression algorithms are patented and licensed under the terms of >> a proprietary license. Hence, compilation and redistribution in a binary >> format is forbidden! >> > >> > Library is fully licensed under LGPLv2.1+, not under MIT. And there are >> > no proprietary parts. Maybe you are referring to different library? >> > >> >> 06.10.2019, 19:59, "Pali Rohár" : >> >> > This patch provides support for aptX and aptX HD codecs in bluetooth >> A2DP >> >> > profile. It uses open source LGPLv2.1+ licensed libopenaptx library >> which >> >> > can be found at https://github.com/pali/libopenaptx. >> >> > >> >> > aptX for s24 stereo samples provides fixed 6:1 compression ratio and >> >> > bitrate 352.8 kbit/s, aptX HD provides fixed 4:1 compression ratio and >> >> > bitrate 529.2 kbit/s. >> >> > >> >> > According to soundexpert research, aptX codec used in bluetooth A2DP >> is no >> >> > better than SBC High Quality settings. And you cannot hear difference >> >> > between aptX and SBC High Quality, aptX is just a copper-less >> overpriced >> >> > audio cable. >> >> > >> >> > aptX HD is high-bitrate version of aptX. It has clearly noticeable >> increase >> >> > in sound quality (not dramatic though taking into account the >> increase in >> >> > bitrate). >> >> > >> >> > http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx >> >> > --- >> >> > configure.ac | 36 +++ >> >> > src/Makefile.am | 6 + >> >> > src/modules/bluetooth/a2dp-codec-aptx.c | 479 >> >> >> > src/modules/bluetooth/a2dp-codec-util.c | 8 + >> >> > 4 files changed, 529 insertions(+) >> >> > create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c >> >> > >> >> > diff --git a/configure.ac b/configure.ac >> >> > index 8278353d4..26c625a59 100644 >> >> > --- a/configure.ac >> >> > +++ b/configure.ac >> >> > @@ -1118,6 +1118,40 @@ AC_SUBST(HAVE_BLUEZ_5_NATIVE_HEADSET) >> >> > AM_CONDITIONAL([HAVE_BLUEZ_5_NATIVE_HEADSET], [test >> "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = x1]) >> >> > AS_IF([test "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = "x1"], >> AC_DEFINE([HAVE_BLUEZ_5_NATIVE_HEADSET], 1, [Bluez 5 native headset backend >> enabled])) >> >> > >> >> > + Bluetooth A2DP aptX codec (optional) ### >> >> > + >> >> > +AC_ARG_ENABLE([aptx], >> >> > + AS_HELP_STRING([--disable-aptx],[Disable optional bluetooth A2DP >> aptX and aptX HD codecs support (via libopenaptx)])) >> >> > +AC_ARG_VAR([OPENAPTX_CPPFLAGS], [C preprocessor flags for openaptx]) >> >> > +AC_ARG_VAR([OPENAPTX_LDFLAGS], [linker flags for openaptx]) >> >> &g
Re: [pulseaudio-discuss] [PATCH v13 05/10] bluetooth: Add A2DP aptX and aptX HD codecs support
Sorry, I should have provided the link to the source GIT https://github.com/Arkq/openaptx JP 07.10.2019, 09:51, "Pali Rohár" : > On Monday 07 October 2019 09:47:21 Hyperion wrote: >> Quotig OpenAPTX Github README : >> "This project is for research purposes only. Without a proper license >> private and commercial usage might be a case of a patent infringement. If >> you are looking for a library, which can be installed and used legally >> (commercial, private and educational usage), go to the Qualcomm® aptX™ >> homepage and contact Qualcomm customer service." > > Sorry, but I have not found any such quotes in README file. > >> So APTX support MUST only be provided for researching purposes, and so it >> should remain an external patch, out of the main PA tree. >> >> All the best, >> >> The source code itself is licensed under the terms of the MIT license. >> However, compression algorithms are patented and licensed under the terms of >> a proprietary license. Hence, compilation and redistribution in a binary >> format is forbidden! > > Library is fully licensed under LGPLv2.1+, not under MIT. And there are > no proprietary parts. Maybe you are referring to different library? > >> 06.10.2019, 19:59, "Pali Rohár" : >> > This patch provides support for aptX and aptX HD codecs in bluetooth A2DP >> > profile. It uses open source LGPLv2.1+ licensed libopenaptx library which >> > can be found at https://github.com/pali/libopenaptx. >> > >> > aptX for s24 stereo samples provides fixed 6:1 compression ratio and >> > bitrate 352.8 kbit/s, aptX HD provides fixed 4:1 compression ratio and >> > bitrate 529.2 kbit/s. >> > >> > According to soundexpert research, aptX codec used in bluetooth A2DP is no >> > better than SBC High Quality settings. And you cannot hear difference >> > between aptX and SBC High Quality, aptX is just a copper-less overpriced >> > audio cable. >> > >> > aptX HD is high-bitrate version of aptX. It has clearly noticeable >> increase >> > in sound quality (not dramatic though taking into account the increase in >> > bitrate). >> > >> > http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx >> > --- >> > configure.ac | 36 +++ >> > src/Makefile.am | 6 + >> > src/modules/bluetooth/a2dp-codec-aptx.c | 479 >> >> > src/modules/bluetooth/a2dp-codec-util.c | 8 + >> > 4 files changed, 529 insertions(+) >> > create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c >> > >> > diff --git a/configure.ac b/configure.ac >> > index 8278353d4..26c625a59 100644 >> > --- a/configure.ac >> > +++ b/configure.ac >> > @@ -1118,6 +1118,40 @@ AC_SUBST(HAVE_BLUEZ_5_NATIVE_HEADSET) >> > AM_CONDITIONAL([HAVE_BLUEZ_5_NATIVE_HEADSET], [test >> "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = x1]) >> > AS_IF([test "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = "x1"], >> AC_DEFINE([HAVE_BLUEZ_5_NATIVE_HEADSET], 1, [Bluez 5 native headset backend >> enabled])) >> > >> > + Bluetooth A2DP aptX codec (optional) ### >> > + >> > +AC_ARG_ENABLE([aptx], >> > + AS_HELP_STRING([--disable-aptx],[Disable optional bluetooth A2DP aptX >> and aptX HD codecs support (via libopenaptx)])) >> > +AC_ARG_VAR([OPENAPTX_CPPFLAGS], [C preprocessor flags for openaptx]) >> > +AC_ARG_VAR([OPENAPTX_LDFLAGS], [linker flags for openaptx]) >> > + >> > +CPPFLAGS_SAVE="$CPPFLAGS" >> > +LDFLAGS_SAVE="$LDFLAGS" >> > +LIBS_SAVE="$LIBS" >> > + >> > +CPPFLAGS="$CPPFLAGS $OPENAPTX_CPPFLAGS" >> > +LDFLAGS="$LDFLAGS $OPENAPTX_LDFLAGS" >> > + >> > +AS_IF([test "x$HAVE_BLUEZ_5" = "x1" && test "x$enable_aptx" != "xno"], >> > + [AC_CHECK_HEADER([openaptx.h], >> > + [AC_SEARCH_LIBS([aptx_init], [openaptx], >> > + [HAVE_OPENAPTX=1; AS_IF([test "x$ac_cv_search_aptx_init" != "xnone >> required"], [OPENAPTX_LDFLAGS="$OPENAPTX_LDFLAGS $ac_cv_search_aptx_init"])], >> > + [HAVE_OPENAPTX=0])], >> > + [HAVE_OPENAPTX=0])]) >> > + >> > +CPPFLAGS="$CPPFLAGS_SAVE" >> > +LDFLAGS="$LDFLAGS_SAVE" >> > +LIBS="$LIBS_SAVE" >> > + >> > +AS_IF([test "x$HAVE_BLUEZ_5" = &
Re: [pulseaudio-discuss] [PATCH v13 07/10] bluetooth: Add more variants of SBC codec
Hi Pali,
I believe that the average user SHOULD be provided a high quality sound by
default. And legacy low quality bitrates SHOULD be a workaround.
IMHO, an "AUTOMATIC mode with max XQ bitrates and DUAL CHANNEL mode prefered"
(aka : max negociated bitpool = 38 per channel) : SHOULD be the default mode of
operations, because it will provide a high quality sound for 99% of the
devices.
Rare remaining devices that have a broken A2DP implementation, OR rare very old
devices designed before BT version 2.0 : SHOULD be handled by an "automatic
mode with the legacy MQ bitrates" (aka max negociated bitpool = 53).
Other SBC modes with FORCED bitpool are usefull for sound researchers /
advanced sound specialists, but not relevant for the average user.
Please tell me what you think about it.
All the best
JP
06.10.2019, 19:59, "Pali Rohár" :
> Specify configuration for Low, Middle, High and eXtreme Quality of SBC
> codec. SBC codec in eXtreme Quality has higher quality than aptX.
>
> Automatic Quality mode matches configuration of SBC codec which was used
> before this change. Which means that it accept configuration between Low
> and High quality.
>
> Current SBC code was extended to allow definitions of arbitrary
> configuration variants of SBC codec parameters.
>
> SBC XQ testing is in following article:
> http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> ---
> src/modules/bluetooth/a2dp-codec-sbc.c | 737 ++--
> src/modules/bluetooth/a2dp-codec-util.c | 20 +-
> 2 files changed, 618 insertions(+), 139 deletions(-)
>
> diff --git a/src/modules/bluetooth/a2dp-codec-sbc.c
> b/src/modules/bluetooth/a2dp-codec-sbc.c
> index 733c1a9ab..8db3416b9 100644
> --- a/src/modules/bluetooth/a2dp-codec-sbc.c
> +++ b/src/modules/bluetooth/a2dp-codec-sbc.c
> @@ -36,8 +36,71 @@
> #include "a2dp-codec-api.h"
> #include "rtp.h"
>
> -#define SBC_BITPOOL_DEC_LIMIT 32
> -#define SBC_BITPOOL_DEC_STEP 5
> +/* Below are capabilities tables for different qualities. Order of
> capabilities in tables are from the most preferred to the least preferred. */
> +
> +#define FIXED_SBC_CAPS(mode, freq, bitpool) { .channel_mode = (mode),
> .frequency = (freq), .min_bitpool = (bitpool), .max_bitpool = (bitpool),
> .allocation_method = SBC_ALLOCATION_LOUDNESS, .subbands = SBC_SUBBANDS_8,
> .block_length = SBC_BLOCK_LENGTH_16 }
> +
> +/* SBC Low Quality, Joint Stereo is same as FastStream's SBC codec
> configuration, Mono was calculated to match Joint Stereo */
> +static const a2dp_sbc_t sbc_lq_caps_table[] = {
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_44100, 29),
> /* 195.7 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_48000, 29),
> /* 213 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_44100, 15), /*
> 104.7 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_48000, 15), /* 114
> kbps */
> +};
> +
> +/* SBC Middle Quality, based on A2DP spec: Recommended sets of SBC
> parameters */
> +static const a2dp_sbc_t sbc_mq_caps_table[] = {
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_44100,
> SBC_BITPOOL_MQ_JOINT_STEREO_44100), /* bitpool = 35, 228.8 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_48000,
> SBC_BITPOOL_MQ_JOINT_STEREO_48000), /* bitpool = 33, 237 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_44100,
> SBC_BITPOOL_MQ_MONO_44100), /* bitpool = 19, 126.8 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_48000,
> SBC_BITPOOL_MQ_MONO_48000), /* bitpool = 18, 132 kbps */
> +};
> +
> +/* SBC High Quality, based on A2DP spec: Recommended sets of SBC parameters
> */
> +static const a2dp_sbc_t sbc_hq_caps_table[] = {
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_44100,
> SBC_BITPOOL_HQ_JOINT_STEREO_44100), /* bitpool = 53, 328 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_48000,
> SBC_BITPOOL_HQ_JOINT_STEREO_48000), /* bitpool = 51, 345 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_44100,
> SBC_BITPOOL_HQ_MONO_44100), /* bitpool = 31, 192.9 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_48000,
> SBC_BITPOOL_HQ_MONO_48000), /* bitpool = 29, 210 kbps */
> +};
> +
> +/* SBC eXtreme Quality, calculated to minimize wasted bytes and to be below
> max possible 512 kbps */
> +static const a2dp_sbc_t sbc_xq1_caps_table[] = {
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_44100, 76),
> /* 454.8 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_JOINT_STEREO, SBC_SAMPLING_FREQ_48000, 76),
> /* 495 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_STEREO, SBC_SAMPLING_FREQ_44100, 76), /*
> 452 kbps */
> + FIXED_SBC_CAPS(SBC_CHANNEL_MODE_STEREO, SBC_SAMPLING_FREQ_48000, 76), /*
> 492 kbps */
> +};
> +static const a2dp_sbc_t sbc_xq2_caps_table[] = {
> +
Re: [pulseaudio-discuss] [PATCH v13 05/10] bluetooth: Add A2DP aptX and aptX HD codecs support
Quotig OpenAPTX Github README :
"This project is for research purposes only. Without a proper license private
and commercial usage might be a case of a patent infringement. If you are
looking for a library, which can be installed and used legally (commercial,
private and educational usage), go to the Qualcomm® aptX™ homepage and contact
Qualcomm customer service."
So APTX support MUST only be provided for researching purposes, and so it
should remain an external patch, out of the main PA tree.
All the best,
The source code itself is licensed under the terms of the MIT license. However,
compression algorithms are patented and licensed under the terms of a
proprietary license. Hence, compilation and redistribution in a binary format
is forbidden!
06.10.2019, 19:59, "Pali Rohár" :
> This patch provides support for aptX and aptX HD codecs in bluetooth A2DP
> profile. It uses open source LGPLv2.1+ licensed libopenaptx library which
> can be found at https://github.com/pali/libopenaptx.
>
> aptX for s24 stereo samples provides fixed 6:1 compression ratio and
> bitrate 352.8 kbit/s, aptX HD provides fixed 4:1 compression ratio and
> bitrate 529.2 kbit/s.
>
> According to soundexpert research, aptX codec used in bluetooth A2DP is no
> better than SBC High Quality settings. And you cannot hear difference
> between aptX and SBC High Quality, aptX is just a copper-less overpriced
> audio cable.
>
> aptX HD is high-bitrate version of aptX. It has clearly noticeable increase
> in sound quality (not dramatic though taking into account the increase in
> bitrate).
>
> http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
> ---
> configure.ac | 36 +++
> src/Makefile.am | 6 +
> src/modules/bluetooth/a2dp-codec-aptx.c | 479
>
> src/modules/bluetooth/a2dp-codec-util.c | 8 +
> 4 files changed, 529 insertions(+)
> create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c
>
> diff --git a/configure.ac b/configure.ac
> index 8278353d4..26c625a59 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1118,6 +1118,40 @@ AC_SUBST(HAVE_BLUEZ_5_NATIVE_HEADSET)
> AM_CONDITIONAL([HAVE_BLUEZ_5_NATIVE_HEADSET], [test
> "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = x1])
> AS_IF([test "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = "x1"],
> AC_DEFINE([HAVE_BLUEZ_5_NATIVE_HEADSET], 1, [Bluez 5 native headset backend
> enabled]))
>
> + Bluetooth A2DP aptX codec (optional) ###
> +
> +AC_ARG_ENABLE([aptx],
> + AS_HELP_STRING([--disable-aptx],[Disable optional bluetooth A2DP aptX and
> aptX HD codecs support (via libopenaptx)]))
> +AC_ARG_VAR([OPENAPTX_CPPFLAGS], [C preprocessor flags for openaptx])
> +AC_ARG_VAR([OPENAPTX_LDFLAGS], [linker flags for openaptx])
> +
> +CPPFLAGS_SAVE="$CPPFLAGS"
> +LDFLAGS_SAVE="$LDFLAGS"
> +LIBS_SAVE="$LIBS"
> +
> +CPPFLAGS="$CPPFLAGS $OPENAPTX_CPPFLAGS"
> +LDFLAGS="$LDFLAGS $OPENAPTX_LDFLAGS"
> +
> +AS_IF([test "x$HAVE_BLUEZ_5" = "x1" && test "x$enable_aptx" != "xno"],
> + [AC_CHECK_HEADER([openaptx.h],
> + [AC_SEARCH_LIBS([aptx_init], [openaptx],
> + [HAVE_OPENAPTX=1; AS_IF([test "x$ac_cv_search_aptx_init" != "xnone
> required"], [OPENAPTX_LDFLAGS="$OPENAPTX_LDFLAGS $ac_cv_search_aptx_init"])],
> + [HAVE_OPENAPTX=0])],
> + [HAVE_OPENAPTX=0])])
> +
> +CPPFLAGS="$CPPFLAGS_SAVE"
> +LDFLAGS="$LDFLAGS_SAVE"
> +LIBS="$LIBS_SAVE"
> +
> +AS_IF([test "x$HAVE_BLUEZ_5" = "x1" && test "x$enable_aptx" = "xyes" && test
> "x$HAVE_OPENAPTX" = "x0"],
> + [AC_MSG_ERROR([*** libopenaptx from https://github.com/pali/libopenaptx not
> found])])
> +
> +AC_SUBST(OPENAPTX_CPPFLAGS)
> +AC_SUBST(OPENAPTX_LDFLAGS)
> +AC_SUBST(HAVE_OPENAPTX)
> +AM_CONDITIONAL([HAVE_OPENAPTX], [test "x$HAVE_OPENAPTX" = "x1"])
> +AS_IF([test "x$HAVE_OPENAPTX" = "x1"], AC_DEFINE([HAVE_OPENAPTX], 1, [Have
> openaptx codec library]))
> +
> UDEV support (optional)
>
> AC_ARG_ENABLE([udev],
> @@ -1603,6 +1637,7 @@ AS_IF([test "x$HAVE_SYSTEMD_JOURNAL" = "x1"],
> ENABLE_SYSTEMD_JOURNAL=yes, ENABLE
> AS_IF([test "x$HAVE_BLUEZ_5" = "x1"], ENABLE_BLUEZ_5=yes, ENABLE_BLUEZ_5=no)
> AS_IF([test "x$HAVE_BLUEZ_5_OFONO_HEADSET" = "x1"],
> ENABLE_BLUEZ_5_OFONO_HEADSET=yes, ENABLE_BLUEZ_5_OFONO_HEADSET=no)
> AS_IF([test "x$HAVE_BLUEZ_5_NATIVE_HEADSET" = "x1"],
> ENABLE_BLUEZ_5_NATIVE_HEADSET=yes, ENABLE_BLUEZ_5_NATIVE_HEADSET=no)
> +AS_IF([test "x$HAVE_OPENAPTX" = "x1"], ENABLE_APTX=yes, ENABLE_APTX=no)
> AS_IF([test "x$HAVE_HAL_COMPAT" = "x1"], ENABLE_HAL_COMPAT=yes,
> ENABLE_HAL_COMPAT=no)
> AS_IF([test "x$HAVE_TCPWRAP" = "x1"], ENABLE_TCPWRAP=yes, ENABLE_TCPWRAP=no)
> AS_IF([test "x$HAVE_LIBSAMPLERATE" = "x1"], ENABLE_LIBSAMPLERATE="yes
> (DEPRECATED)", ENABLE_LIBSAMPLERATE=no)
> @@ -1661,6 +1696,7 @@ echo "
> Enable BlueZ 5: ${ENABLE_BLUEZ_5}
> Enable ofono headsets: ${ENABLE_BLUEZ_5_OFONO_HEADSET}
> Enable native headsets: ${ENABLE_BLUEZ_5_NATIVE_HEADSET}
> + Enable aptX+aptXHD codecs: ${ENABLE_APTX}
> Enable udev: ${ENABLE_UDEV}
> Enable HAL->udev
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
HI,
I have reworked my mod so that it can safely achieve bitpool 94 in both dual
channel and joint stereo, as long as the device supports it (only my high end
Harman Kardon support 94 in joint stereo).
Devices supporting only bitpool 53 are kept safe (bitpool is always negociated,
never forced : this doesn't use fixed caps).
Anyway most devices support at least bitpool 47 in dual channel mode, and BT
(version 3 and up) bandwidth is much higher : so this patch deprecates both
APTX and LDAC.
The Git is up to date : https://github.com/JPGuillemin/pulseaudio
This patch is likely safe to be applied on the official master cause it doesn't
need Bluez multi-codec API, and doesn't introduce any patent issue (mainly from
CSR, openaptx being underground reverse ingeniering).
All the best
JP
19.09.2019, 13:07, "Hyperion" :
> The Git branch with my mods :
> https://github.com/JPGuillemin/pulseaudio/tree/SBC-XQ
>
> I'm sure it needs improvement, but I need testers ;) for now it works as
> expected on all my devices...
>
> JP
>
> 19.09.2019, 11:21, "Hyperion" :
>> Yes, thanks, you're right, I'm going to do it as soon as I get enough
>> testing feedback.
>>
>> Talking about tests : I'm going to switch back to Pali's default values for
>> announced bitpool capabilities, cause some (rare) devices produces a few
>> distorsion with dual channel 47 bitpool.
>>
>> So back to dual 38 / 76 , which should be ok on any device.
>>
>> New patch :
>> http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V3.patch
>>
>> Thanks for testing :)
>>
>> jp
>>
>> 19.09.2019, 10:27, "Andrey Semashev" :
>>> I'm not the maintainer, but it might be better to create a merge request
>>> in GitLab project:
>>>
>>> https://gitlab.freedesktop.org/pulseaudio/pulseaudio
>>>
>>> and post any additional information there so it doesn't get lost.
>>>
>>> On 2019-09-18 14:02, Hyperion wrote:
>>>> Patch V2 with added DUAL_CHANNEL as preferred mode.
>>>>
>>>> Works without any issue on more than 10 stereo and mono devices that I
>>>> have here.
>>>>
>>>>
>>>> http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V2.patch
>>>>
>>>> /***
>>>> This file is part of PulseAudio.
>>>>
>>>> Copyright 2018-2019 Pali Rohár
>>>>
>>>> PulseAudio is free software; you can redistribute it and/or modify
>>>> it under the terms of the GNU Lesser General Public License as
>>>> published by the Free Software Foundation; either version 2.1 of the
>>>> License, or (at your option) any later version.
>>>>
>>>> PulseAudio is distributed in the hope that it will be useful, but
>>>> WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>>> General Public License for more details.
>>>>
>>>> You should have received a copy of the GNU Lesser General Public
>>>> License along with PulseAudio; if not, see
>>>> <http://www.gnu.org/licenses/>.
>>>> ***/
>>>>
>>>> #ifdef HAVE_CONFIG_H
>>>> #include
>>>> #endif
>>>>
>>>> #include
>>>> #include
>>>> #include
>>>> #include
>>>> #include
>>>> #include
>>>>
>>>> #include
>>>>
>>>> #include
>>>>
>>>> #include "a2dp-codecs.h"
>>>> #include "a2dp-codec-api.h"
>>>> #include "rtp.h"
>>>>
>>>> #define SBC_BITPOOL_DEC_LIMIT 32
>>>> #define SBC_BITPOOL_DEC_STEP 5
>>>>
>>>> struct sbc_info {
>>>> sbc_t sbc; /* Codec data */
>>>> size_t codesize, frame_length; /* SBC Codesize, frame_length. We
>>>> simply cache those values here */
>>>> uint16_t seq_num; /* Cumulative packet sequence */
>>>> uint8_t frequency;
>>>> uint8_t blocks;
>>>> uint8_t subbands;
>>>> uint8_t mode;
>>>> uint8_t allocation;
>>>> uint8_t initial_bitpool;
>>>> uint8_t min_bitpool;
>>>> uint8_t
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
The Git branch with my mods :
https://github.com/JPGuillemin/pulseaudio/tree/SBC-XQ
I'm sure it needs improvement, but I need testers ;) for now it works as
expected on all my devices...
JP
19.09.2019, 11:21, "Hyperion" :
> Yes, thanks, you're right, I'm going to do it as soon as I get enough testing
> feedback.
>
> Talking about tests : I'm going to switch back to Pali's default values for
> announced bitpool capabilities, cause some (rare) devices produces a few
> distorsion with dual channel 47 bitpool.
>
> So back to dual 38 / 76 , which should be ok on any device.
>
> New patch :
> http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V3.patch
>
> Thanks for testing :)
>
> jp
>
> 19.09.2019, 10:27, "Andrey Semashev" :
>> I'm not the maintainer, but it might be better to create a merge request
>> in GitLab project:
>>
>> https://gitlab.freedesktop.org/pulseaudio/pulseaudio
>>
>> and post any additional information there so it doesn't get lost.
>>
>> On 2019-09-18 14:02, Hyperion wrote:
>>> Patch V2 with added DUAL_CHANNEL as preferred mode.
>>>
>>> Works without any issue on more than 10 stereo and mono devices that I
>>> have here.
>>>
>>> http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V2.patch
>>>
>>> /***
>>> This file is part of PulseAudio.
>>>
>>> Copyright 2018-2019 Pali Rohár
>>>
>>> PulseAudio is free software; you can redistribute it and/or modify
>>> it under the terms of the GNU Lesser General Public License as
>>> published by the Free Software Foundation; either version 2.1 of the
>>> License, or (at your option) any later version.
>>>
>>> PulseAudio is distributed in the hope that it will be useful, but
>>> WITHOUT ANY WARRANTY; without even the implied warranty of
>>> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> General Public License for more details.
>>>
>>> You should have received a copy of the GNU Lesser General Public
>>> License along with PulseAudio; if not, see
>>> <http://www.gnu.org/licenses/>.
>>> ***/
>>>
>>> #ifdef HAVE_CONFIG_H
>>> #include
>>> #endif
>>>
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>>
>>> #include
>>>
>>> #include
>>>
>>> #include "a2dp-codecs.h"
>>> #include "a2dp-codec-api.h"
>>> #include "rtp.h"
>>>
>>> #define SBC_BITPOOL_DEC_LIMIT 32
>>> #define SBC_BITPOOL_DEC_STEP 5
>>>
>>> struct sbc_info {
>>> sbc_t sbc; /* Codec data */
>>> size_t codesize, frame_length; /* SBC Codesize, frame_length. We
>>> simply cache those values here */
>>> uint16_t seq_num; /* Cumulative packet sequence */
>>> uint8_t frequency;
>>> uint8_t blocks;
>>> uint8_t subbands;
>>> uint8_t mode;
>>> uint8_t allocation;
>>> uint8_t initial_bitpool;
>>> uint8_t min_bitpool;
>>> uint8_t max_bitpool;
>>> };
>>>
>>> static bool can_accept_capabilities(const uint8_t *capabilities_buffer,
>>> uint8_t capabilities_size, bool for_encoding) {
>>> const a2dp_sbc_t *capabilities = (const a2dp_sbc_t *)
>>> capabilities_buffer;
>>>
>>> if (capabilities_size != sizeof(*capabilities))
>>> return false;
>>>
>>> if (!(capabilities->frequency & (SBC_SAMPLING_FREQ_16000 |
>>> SBC_SAMPLING_FREQ_32000 | SBC_SAMPLING_FREQ_44100 |
>>> SBC_SAMPLING_FREQ_48000)))
>>> return false;
>>>
>>> if (!(capabilities->channel_mode & (SBC_CHANNEL_MODE_MONO |
>>> SBC_CHANNEL_MODE_DUAL_CHANNEL | SBC_CHANNEL_MODE_STEREO |
>>> SBC_CHANNEL_MODE_JOINT_STEREO)))
>>> return false;
>>>
>>> if (!(capabilities->allocation_method & (SBC_ALLOCATION_SNR |
>>> SBC_ALLOCATION_LOUDNESS)))
>>> return false;
>>>
>>> if (!(capabilities->subbands & (SBC_SUBBANDS_4 | SBC_SUBBANDS_8)))
>>> return false;
>>>
>>> if (!(capabilities->block_length &
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
Yes, thanks, you're right, I'm going to do it as soon as I get enough testing
feedback.
Talking about tests : I'm going to switch back to Pali's default values for
announced bitpool capabilities, cause some (rare) devices produces a few
distorsion with dual channel 47 bitpool.
So back to dual 38 / 76 , which should be ok on any device.
New patch :
http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V3.patch
Thanks for testing :)
jp
19.09.2019, 10:27, "Andrey Semashev" :
> I'm not the maintainer, but it might be better to create a merge request
> in GitLab project:
>
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio
>
> and post any additional information there so it doesn't get lost.
>
> On 2019-09-18 14:02, Hyperion wrote:
>> Patch V2 with added DUAL_CHANNEL as preferred mode.
>>
>> Works without any issue on more than 10 stereo and mono devices that I have
>> here.
>>
>> http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V2.patch
>>
>> /***
>> This file is part of PulseAudio.
>>
>> Copyright 2018-2019 Pali Rohár
>>
>> PulseAudio is free software; you can redistribute it and/or modify
>> it under the terms of the GNU Lesser General Public License as
>> published by the Free Software Foundation; either version 2.1 of the
>> License, or (at your option) any later version.
>>
>> PulseAudio is distributed in the hope that it will be useful, but
>> WITHOUT ANY WARRANTY; without even the implied warranty of
>> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> General Public License for more details.
>>
>> You should have received a copy of the GNU Lesser General Public
>> License along with PulseAudio; if not, see
>> <http://www.gnu.org/licenses/>.
>> ***/
>>
>> #ifdef HAVE_CONFIG_H
>> #include
>> #endif
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> #include
>>
>> #include
>>
>> #include "a2dp-codecs.h"
>> #include "a2dp-codec-api.h"
>> #include "rtp.h"
>>
>> #define SBC_BITPOOL_DEC_LIMIT 32
>> #define SBC_BITPOOL_DEC_STEP 5
>>
>> struct sbc_info {
>> sbc_t sbc; /* Codec data */
>> size_t codesize, frame_length; /* SBC Codesize, frame_length. We
>> simply cache those values here */
>> uint16_t seq_num; /* Cumulative packet sequence */
>> uint8_t frequency;
>> uint8_t blocks;
>> uint8_t subbands;
>> uint8_t mode;
>> uint8_t allocation;
>> uint8_t initial_bitpool;
>> uint8_t min_bitpool;
>> uint8_t max_bitpool;
>> };
>>
>> static bool can_accept_capabilities(const uint8_t *capabilities_buffer,
>> uint8_t capabilities_size, bool for_encoding) {
>> const a2dp_sbc_t *capabilities = (const a2dp_sbc_t *)
>> capabilities_buffer;
>>
>> if (capabilities_size != sizeof(*capabilities))
>> return false;
>>
>> if (!(capabilities->frequency & (SBC_SAMPLING_FREQ_16000 |
>> SBC_SAMPLING_FREQ_32000 | SBC_SAMPLING_FREQ_44100 |
>> SBC_SAMPLING_FREQ_48000)))
>> return false;
>>
>> if (!(capabilities->channel_mode & (SBC_CHANNEL_MODE_MONO |
>> SBC_CHANNEL_MODE_DUAL_CHANNEL | SBC_CHANNEL_MODE_STEREO |
>> SBC_CHANNEL_MODE_JOINT_STEREO)))
>> return false;
>>
>> if (!(capabilities->allocation_method & (SBC_ALLOCATION_SNR |
>> SBC_ALLOCATION_LOUDNESS)))
>> return false;
>>
>> if (!(capabilities->subbands & (SBC_SUBBANDS_4 | SBC_SUBBANDS_8)))
>> return false;
>>
>> if (!(capabilities->block_length & (SBC_BLOCK_LENGTH_4 |
>> SBC_BLOCK_LENGTH_8 | SBC_BLOCK_LENGTH_12 | SBC_BLOCK_LENGTH_16)))
>> return false;
>>
>> return true;
>> }
>>
>> static const char *choose_remote_endpoint(const pa_hashmap
>> *capabilities_hashmap, const pa_sample_spec *default_sample_spec, bool
>> for_encoding) {
>> const pa_a2dp_codec_capabilities *a2dp_capabilities;
>> const char *key;
>> void *state;
>>
>> /* There is no preference, just choose random valid entry */
>> PA_HASHMAP_FOREACH_KV(key, a2dp_capabilities, capabilities_hashmap,
>> state) {
>> if (can_accept_capabilities(a2dp_capabilities->buffer,
&
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
Negociation wth JBL E55BT headset, resulting in Dual Channel 2x40kb bitpool : hcidump avdtp HCI sniffer - Bluetooth packet analyzer ver 5.50 device: hci0 snap_len: 1500 filter: 0x400 < AVDTP(s): Discover cmd: transaction 0 nsp 0x00 > AVDTP(s): Discover rsp: transaction 0 nsp 0x00 ACP SEID 1 - Audio Sink ACP SEID 2 - Audio Sink < AVDTP(s): Capabilities cmd: transaction 1 nsp 0x00 ACP SEID 1 > AVDTP(s): Capabilities rsp: transaction 1 nsp 0x00 Media Transport Media Codec - SBC 16kHz 32kHz 44.1kHz 48kHz Mono DualChannel Stereo JointStereo 4 8 12 16 Blocks 4 8 Subbands SNR Loudness Bitpool Range 2-40 Content Protection 02 00 < AVDTP(s): Capabilities cmd: transaction 2 nsp 0x00 ACP SEID 2 > AVDTP(s): Capabilities rsp: transaction 2 nsp 0x00 Media Transport Media Codec - SBC 16kHz 32kHz 44.1kHz 48kHz Mono DualChannel Stereo JointStereo 4 8 12 16 Blocks 4 8 Subbands SNR Loudness Bitpool Range 2-40 Content Protection 02 00 < AVDTP(s): Set config cmd: transaction 3 nsp 0x00 ACP SEID 1 - INT SEID 2 Media Transport Media Codec - SBC 44.1kHz DualChannel 16 Blocks 8 Subbands Loudness Bitpool Range 2-40 19.09.2019, 10:15, "Hyperion" : > Negociation wth Divacore Addict headset, resulting in Dual Channel 2x47kb > bitpool : > > HCI sniffer - Bluetooth packet analyzer ver 5.50 > device: hci0 snap_len: 1500 filter: 0x400 > < AVDTP(s): Discover cmd: transaction 7 nsp 0x00 >> AVDTP(s): Discover rsp: transaction 7 nsp 0x00 > > ACP SEID 1 - Audio Sink > ACP SEID 5 - Audio Sink > ACP SEID 3 - Audio Sink > ACP SEID 2 - Audio Sink > < AVDTP(s): Capabilities cmd: transaction 8 nsp 0x00 > ACP SEID 1 >> AVDTP(s): Capabilities rsp: transaction 8 nsp 0x00 > > Media Transport > Media Codec - SBC > 16kHz 32kHz 44.1kHz 48kHz > Mono DualChannel Stereo JointStereo > 4 8 12 16 Blocks > 4 8 Subbands > SNR Loudness > Bitpool Range 2-53 > Content Protection > 02 00 > < AVDTP(s): Capabilities cmd: transaction 9 nsp 0x00 > ACP SEID 5 >> AVDTP(s): Capabilities rsp: transaction 9 nsp 0x00 > > Media Transport > Media Codec - non-A2DP (aptX) > 16kHz 32kHz 44.1kHz 48kHz > Stereo > < AVDTP(s): Capabilities cmd: transaction 10 nsp 0x00 > ACP SEID 3 >> AVDTP(s): Capabilities rsp: transaction 10 nsp 0x00 > > Media Transport > Media Codec - MPEG-2,4 AAC > MPEG-2 AAC LC MPEG-4 AAC LC > 8kHz 11.025kHz 12kHz 16kHz 22.05kHz 24kHz 32kHz 44.1kHz 48kHz > 1 2 Channels > 32bps VBR > Content Protection > 02 00 > < AVDTP(s): Capabilities cmd: transaction 11 nsp 0x00 > ACP SEID 2 >> AVDTP(s): Capabilities rsp: transaction 11 nsp 0x00 > > Media Transport > Media Codec - MPEG-1,2 Audio > Layers: 3 > CRC Protection: Yes > Mono DualChannel Stereo JointStereo > Media Payload Format: RFC-2250 > 16kHz 22.05kHz 24kHz 32kHz 44.1kHz 48kHz > VBR: Yes > Bit Rate Indexes: n/a > Content Protection > 02 00 > < AVDTP(s): Set config cmd: transaction 12 nsp 0x00 > ACP SEID 1 - INT SEID 2 > Media Transport > Media Codec - SBC > 44.1kHz > DualChannel > 16 Blocks > 8 Subbands > Loudness > Bitpool Range 2-47 > > 19.09.2019, 10:13, "Hyperion" : >> Negociation wth Harman Kardon Onyx, resulting in Dual Channel 2x47kb >> bitpool : >> >> device: hci0 snap_len: 1500 filter: 0x400 >> < AVDTP(s): Discover cmd: transaction 15 nsp 0x00 >>> AVDTP(s): Discover rsp: transaction 15 nsp 0x00 >> >> ACP SEID 1 - Audio Sink >> ACP SEID 2 - Audio Sink >> ACP SEID 3 - Audio Sink >> < AVDTP(s): All Capabilities cmd: transaction 0 nsp 0x00 >> ACP SEID 1 >>> AVDTP(s): All Capabilities rsp: transaction 0 nsp 0x00 >> >> Media Transport >> Reporting >> Media Codec - SBC >> 16kHz 32kHz 44.1kHz 48kHz >> Mono DualChannel Stereo JointStereo >> 4 8 12 16 Blocks >> 4 8 Subbands >> SNR Loudness >> Bitpool Range 2-89 >> Content Protection >> 02 00 >> Delay Reporting >> < AVDTP(s): All Capabilities cmd: transaction 1 nsp 0x00 >> ACP SEID 2 >>> AVDTP(s): All Capabilities rsp: transaction 1 nsp 0x00 >> >> Media Transport >> Reporting >> Media C
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
Negociation wth Divacore Addict headset, resulting in Dual Channel 2x47kb bitpool : HCI sniffer - Bluetooth packet analyzer ver 5.50 device: hci0 snap_len: 1500 filter: 0x400 < AVDTP(s): Discover cmd: transaction 7 nsp 0x00 > AVDTP(s): Discover rsp: transaction 7 nsp 0x00 ACP SEID 1 - Audio Sink ACP SEID 5 - Audio Sink ACP SEID 3 - Audio Sink ACP SEID 2 - Audio Sink < AVDTP(s): Capabilities cmd: transaction 8 nsp 0x00 ACP SEID 1 > AVDTP(s): Capabilities rsp: transaction 8 nsp 0x00 Media Transport Media Codec - SBC 16kHz 32kHz 44.1kHz 48kHz Mono DualChannel Stereo JointStereo 4 8 12 16 Blocks 4 8 Subbands SNR Loudness Bitpool Range 2-53 Content Protection 02 00 < AVDTP(s): Capabilities cmd: transaction 9 nsp 0x00 ACP SEID 5 > AVDTP(s): Capabilities rsp: transaction 9 nsp 0x00 Media Transport Media Codec - non-A2DP (aptX) 16kHz 32kHz 44.1kHz 48kHz Stereo < AVDTP(s): Capabilities cmd: transaction 10 nsp 0x00 ACP SEID 3 > AVDTP(s): Capabilities rsp: transaction 10 nsp 0x00 Media Transport Media Codec - MPEG-2,4 AAC MPEG-2 AAC LC MPEG-4 AAC LC 8kHz 11.025kHz 12kHz 16kHz 22.05kHz 24kHz 32kHz 44.1kHz 48kHz 1 2 Channels 32bps VBR Content Protection 02 00 < AVDTP(s): Capabilities cmd: transaction 11 nsp 0x00 ACP SEID 2 > AVDTP(s): Capabilities rsp: transaction 11 nsp 0x00 Media Transport Media Codec - MPEG-1,2 Audio Layers: 3 CRC Protection: Yes Mono DualChannel Stereo JointStereo Media Payload Format: RFC-2250 16kHz 22.05kHz 24kHz 32kHz 44.1kHz 48kHz VBR: Yes Bit Rate Indexes: n/a Content Protection 02 00 < AVDTP(s): Set config cmd: transaction 12 nsp 0x00 ACP SEID 1 - INT SEID 2 Media Transport Media Codec - SBC 44.1kHz DualChannel 16 Blocks 8 Subbands Loudness Bitpool Range 2-47 19.09.2019, 10:13, "Hyperion" : > Negociation wth Harman Kardon Onyx, resulting in Dual Channel 2x47kb bitpool : > > device: hci0 snap_len: 1500 filter: 0x400 > < AVDTP(s): Discover cmd: transaction 15 nsp 0x00 >> AVDTP(s): Discover rsp: transaction 15 nsp 0x00 > > ACP SEID 1 - Audio Sink > ACP SEID 2 - Audio Sink > ACP SEID 3 - Audio Sink > < AVDTP(s): All Capabilities cmd: transaction 0 nsp 0x00 > ACP SEID 1 >> AVDTP(s): All Capabilities rsp: transaction 0 nsp 0x00 > > Media Transport > Reporting > Media Codec - SBC > 16kHz 32kHz 44.1kHz 48kHz > Mono DualChannel Stereo JointStereo > 4 8 12 16 Blocks > 4 8 Subbands > SNR Loudness > Bitpool Range 2-89 > Content Protection > 02 00 > Delay Reporting > < AVDTP(s): All Capabilities cmd: transaction 1 nsp 0x00 > ACP SEID 2 >> AVDTP(s): All Capabilities rsp: transaction 1 nsp 0x00 > > Media Transport > Reporting > Media Codec - SBC > 16kHz 32kHz 44.1kHz 48kHz > Mono DualChannel Stereo JointStereo > 4 8 12 16 Blocks > 4 8 Subbands > SNR Loudness > Bitpool Range 2-89 > Content Protection > 02 00 > Delay Reporting > < AVDTP(s): All Capabilities cmd: transaction 2 nsp 0x00 > ACP SEID 3 >> AVDTP(s): All Capabilities rsp: transaction 2 nsp 0x00 > > Media Transport > Reporting > Media Codec - SBC > 16kHz 32kHz 44.1kHz 48kHz > Mono DualChannel Stereo JointStereo > 4 8 12 16 Blocks > 4 8 Subbands > SNR Loudness > Bitpool Range 2-89 > Content Protection > 02 00 > Delay Reporting > < AVDTP(s): Set config cmd: transaction 3 nsp 0x00 > ACP SEID 1 - INT SEID 2 > Media Transport > Media Codec - SBC > 44.1kHz > DualChannel > 16 Blocks > 8 Subbands > Loudness > Bitpool Range 2-47 > > 18.09.2019, 13:02, "Hyperion" : >> Patch V2 with added DUAL_CHANNEL as preferred mode. >> >> Works without any issue on more than 10 stereo and mono devices that I have >> here. >> >> http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V2.patch >> >> /*** >> This file is part of PulseAudio. >> >> Copyright 2018-2019 Pali Rohár >> >> PulseAudio is free software; you can redistribute it and/or modify >> it under the terms of the GNU Lesser General Public License as >> published by the Free Software Foundation; either version 2.1 of the >> License, or (at your option) any later version. >> >> PulseAudio is distributed in the hope that it will be useful, but >
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
Negociation wth Harman Kardon Onyx, resulting in Dual Channel 2x47kb bitpool :
device: hci0 snap_len: 1500 filter: 0x400
< AVDTP(s): Discover cmd: transaction 15 nsp 0x00
> AVDTP(s): Discover rsp: transaction 15 nsp 0x00
ACP SEID 1 - Audio Sink
ACP SEID 2 - Audio Sink
ACP SEID 3 - Audio Sink
< AVDTP(s): All Capabilities cmd: transaction 0 nsp 0x00
ACP SEID 1
> AVDTP(s): All Capabilities rsp: transaction 0 nsp 0x00
Media Transport
Reporting
Media Codec - SBC
16kHz 32kHz 44.1kHz 48kHz
Mono DualChannel Stereo JointStereo
4 8 12 16 Blocks
4 8 Subbands
SNR Loudness
Bitpool Range 2-89
Content Protection
02 00
Delay Reporting
< AVDTP(s): All Capabilities cmd: transaction 1 nsp 0x00
ACP SEID 2
> AVDTP(s): All Capabilities rsp: transaction 1 nsp 0x00
Media Transport
Reporting
Media Codec - SBC
16kHz 32kHz 44.1kHz 48kHz
Mono DualChannel Stereo JointStereo
4 8 12 16 Blocks
4 8 Subbands
SNR Loudness
Bitpool Range 2-89
Content Protection
02 00
Delay Reporting
< AVDTP(s): All Capabilities cmd: transaction 2 nsp 0x00
ACP SEID 3
> AVDTP(s): All Capabilities rsp: transaction 2 nsp 0x00
Media Transport
Reporting
Media Codec - SBC
16kHz 32kHz 44.1kHz 48kHz
Mono DualChannel Stereo JointStereo
4 8 12 16 Blocks
4 8 Subbands
SNR Loudness
Bitpool Range 2-89
Content Protection
02 00
Delay Reporting
< AVDTP(s): Set config cmd: transaction 3 nsp 0x00
ACP SEID 1 - INT SEID 2
Media Transport
Media Codec - SBC
44.1kHz
DualChannel
16 Blocks
8 Subbands
Loudness
Bitpool Range 2-47
18.09.2019, 13:02, "Hyperion" :
> Patch V2 with added DUAL_CHANNEL as preferred mode.
>
> Works without any issue on more than 10 stereo and mono devices that I have
> here.
>
> http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V2.patch
>
> /***
> This file is part of PulseAudio.
>
> Copyright 2018-2019 Pali Rohár
>
> PulseAudio is free software; you can redistribute it and/or modify
> it under the terms of the GNU Lesser General Public License as
> published by the Free Software Foundation; either version 2.1 of the
> License, or (at your option) any later version.
>
> PulseAudio is distributed in the hope that it will be useful, but
> WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> General Public License for more details.
>
> You should have received a copy of the GNU Lesser General Public
> License along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.
> ***/
>
> #ifdef HAVE_CONFIG_H
> #include
> #endif
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include
>
> #include
>
> #include "a2dp-codecs.h"
> #include "a2dp-codec-api.h"
> #include "rtp.h"
>
> #define SBC_BITPOOL_DEC_LIMIT 32
> #define SBC_BITPOOL_DEC_STEP 5
>
> struct sbc_info {
> sbc_t sbc; /* Codec data */
> size_t codesize, frame_length; /* SBC Codesize, frame_length. We simply
> cache those values here */
> uint16_t seq_num; /* Cumulative packet sequence */
> uint8_t frequency;
> uint8_t blocks;
> uint8_t subbands;
> uint8_t mode;
> uint8_t allocation;
> uint8_t initial_bitpool;
> uint8_t min_bitpool;
> uint8_t max_bitpool;
> };
>
> static bool can_accept_capabilities(const uint8_t *capabilities_buffer,
> uint8_t capabilities_size, bool for_encoding) {
> const a2dp_sbc_t *capabilities = (const a2dp_sbc_t *) capabilities_buffer;
>
> if (capabilities_size != sizeof(*capabilities))
> return false;
>
> if (!(capabilities->frequency & (SBC_SAMPLING_FREQ_16000 |
> SBC_SAMPLING_FREQ_32000 | SBC_SAMPLING_FREQ_44100 | SBC_SAMPLING_FREQ_48000)))
> return false;
>
> if (!(capabilities->channel_mode & (SBC_CHANNEL_MODE_MONO |
> SBC_CHANNEL_MODE_DUAL_CHANNEL | SBC_CHANNEL_MODE_STEREO |
> SBC_CHANNEL_MODE_JOINT_STEREO)))
> return false;
>
> if (!(capabilities->allocation_method & (SBC_ALLOCATION_SNR |
> SBC_ALLOCATION_LOUDNESS)))
> return false;
>
> if (!(capabilities->subbands & (SBC_SUBBANDS_4 | SBC_SUBBANDS_8)))
> return false;
>
> if (!(capabilities->block_length & (SBC_BLOCK_LENGTH_4 |
> SBC_BLOCK_LENGTH_8 | SBC_BLOCK_LENGTH_12 | SBC_BLOCK_LENGTH_16)))
> return false;
>
> return true;
> }
>
> static const char *choose_remote_endpoint(const pa_hash
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
ad*) (output_buffer + sizeof(*header));
frame_count = 0;
p = input_buffer;
to_encode = input_size;
d = output_buffer + sizeof(*header) + sizeof(*payload);
to_write = output_size - sizeof(*header) - sizeof(*payload);
/* frame_count is only 4 bit number */
while (PA_LIKELY(to_encode > 0 && to_write > 0 && frame_count < 15)) {
ssize_t written;
ssize_t encoded;
encoded = sbc_encode(_info->sbc,
p, to_encode,
d, to_write,
);
if (PA_UNLIKELY(encoded <= 0)) {
pa_log_error("SBC encoding error (%li)", (long) encoded);
break;
}
if (PA_UNLIKELY(written < 0)) {
pa_log_error("SBC encoding error (%li)", (long) written);
break;
}
pa_assert_fp((size_t) encoded <= to_encode);
pa_assert_fp((size_t) encoded == sbc_info->codesize);
pa_assert_fp((size_t) written <= to_write);
pa_assert_fp((size_t) written == sbc_info->frame_length);
p += encoded;
to_encode -= encoded;
d += written;
to_write -= written;
frame_count++;
}
PA_ONCE_BEGIN {
pa_log_debug("Using SBC codec implementation: %s",
pa_strnull(sbc_get_implementation_info(_info->sbc)));
} PA_ONCE_END;
if (PA_UNLIKELY(frame_count == 0)) {
*processed = 0;
return 0;
}
/* write it to the fifo */
pa_memzero(output_buffer, sizeof(*header) + sizeof(*payload));
header->v = 2;
/* A2DP spec: "A payload type in the RTP dynamic range shall be chosen".
* RFC3551 defines the dynamic range to span from 96 to 127, and 96 appears
* to be the most common choice in A2DP implementations. */
header->pt = 96;
header->sequence_number = htons(sbc_info->seq_num++);
header->timestamp = htonl(timestamp);
header->ssrc = htonl(1);
payload->frame_count = frame_count;
*processed = p - input_buffer;
return d - output_buffer;
}
static size_t decode_buffer(void *codec_info, const uint8_t *input_buffer,
size_t input_size, uint8_t *output_buffer, size_t output_size, size_t
*processed) {
struct sbc_info *sbc_info = (struct sbc_info *) codec_info;
struct rtp_header *header;
struct rtp_sbc_payload *payload;
const uint8_t *p;
uint8_t *d;
size_t to_write, to_decode;
uint8_t frame_count;
header = (struct rtp_header *) input_buffer;
payload = (struct rtp_sbc_payload*) (input_buffer + sizeof(*header));
frame_count = payload->frame_count;
/* TODO: Add support for decoding fragmented SBC frames */
if (payload->is_fragmented) {
pa_log_error("Unsupported fragmented SBC frame");
*processed = 0;
return 0;
}
p = input_buffer + sizeof(*header) + sizeof(*payload);
to_decode = input_size - sizeof(*header) - sizeof(*payload);
d = output_buffer;
to_write = output_size;
while (PA_LIKELY(to_decode > 0 && to_write > 0 && frame_count > 0)) {
size_t written;
ssize_t decoded;
decoded = sbc_decode(_info->sbc,
p, to_decode,
d, to_write,
);
if (PA_UNLIKELY(decoded <= 0)) {
pa_log_error("SBC decoding error (%li)", (long) decoded);
break;
}
/* Reset frame length, it can be changed due to bitpool change */
sbc_info->frame_length = sbc_get_frame_length(_info->sbc);
pa_assert_fp((size_t) decoded <= to_decode);
pa_assert_fp((size_t) decoded == sbc_info->frame_length);
pa_assert_fp((size_t) written <= to_write);
pa_assert_fp((size_t) written == sbc_info->codesize);
p += decoded;
to_decode -= decoded;
d += written;
to_write -= written;
frame_count--;
}
*processed = p - input_buffer;
return d - output_buffer;
}
const pa_a2dp_codec pa_a2dp_codec_sbc = {
.name = "sbc",
.description = "SBC",
.id = { A2DP_CODEC_SBC, 0, 0 },
.support_backchannel = false,
.can_accept_capabilities = can_accept_capabilities,
.choose_remote_endpoint = choose_remote_endpoint,
.fill_capabilities = fill_capabilities,
.is_configuration_valid = is_configuration_valid,
.fill_preferred_configuration = fill_preferred_configuration,
.init = init,
.deinit = deinit,
.reset = reset,
.get_read_block_size = get_block_size,
.get_write_block_size = get_block_size,
.reduce_encoder_bitrate = reduce_encoder_bitrate,
.encode_buffer = encode_buffer,
.decode_buffer = decode_buffer,
};
17.09.2019, 09:34, "Hyperion" :
> btw here's the updated V12-12 patch i
Re: [pulseaudio-discuss] SBC XQ for PA 13.0
btw here's the updated V12-12 patch in Pali's latest rel95 patchset that
applies to PA 13.0.
http://download.zenwalk.org/x86_64/testing/v12-12-13-zen-bluetooth-Implement-A2DP-codec-switching-and-backchannel-support-.patch
JP
16.09.2019, 09:32, "Hyperion" :
> Hi,
>
> Following what has already be done in some Android derivatives, here's a
> simple patch that extend SBP bitpool negociation to XQ quality.
>
> According to :
> -->
> http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> --> https://lineageos.org/engineering/Bluetooth-SBC-XQ/ ,
> --> and confirmed by my own experimentation on more than 10 different devices,
>
> here are the features of the (very simple and non intrusive) patch :
> - allow to use bitpool 76 on devices that support it, aka SBC XQ
> - harmless for devices limited to bitpool 53
> - deprecates the need for APTX & APTX HD support, which are not better than
> SBC XQ, are not Open Source, and less supported by devices
>
> This patch will be superseded by multi-profiles Pali Rohar A2DP stack
> implementation, when it's ready for production. Thanks to Pali for the help
> testing many codec parameters.
>
> Let me know if I have to clone the git to push my patch, or if a regular PA
> dev could do it.
>
> All the best
> JP
>
> diff -rNaud pulseaudio-13.0/src/modules/bluetooth/a2dp-codec-sbc.c
> pulseaudio-13.0-new/src/modules/bluetooth/a2dp-codec-sbc.c
> --- pulseaudio-13.0/src/modules/bluetooth/a2dp-codec-sbc.c 2019-09-13
> 15:20:03.0 +0200
> +++ pulseaudio-13.0-new/src/modules/bluetooth/a2dp-codec-sbc.c 2019-09-16
> 08:57:50.363122019 +0200
> @@ -290,10 +290,10 @@
> return 0;
> }
>
> - if (capabilities->allocation_method & SBC_ALLOCATION_LOUDNESS)
> - config->allocation_method = SBC_ALLOCATION_LOUDNESS;
> - else if (capabilities->allocation_method & SBC_ALLOCATION_SNR)
> + if (capabilities->allocation_method & SBC_ALLOCATION_SNR)
> config->allocation_method = SBC_ALLOCATION_SNR;
> + else if (capabilities->allocation_method & SBC_ALLOCATION_LOUDNESS)
> + config->allocation_method = SBC_ALLOCATION_LOUDNESS;
> else {
> pa_log_error("No supported allocation method");
> return 0;
> diff -rNaud pulseaudio-13.0/src/modules/bluetooth/a2dp-codecs.h
> pulseaudio-13.0-new/src/modules/bluetooth/a2dp-codecs.h
> --- pulseaudio-13.0/src/modules/bluetooth/a2dp-codecs.h 2019-09-13
> 15:20:03.0 +0200
> +++ pulseaudio-13.0-new/src/modules/bluetooth/a2dp-codecs.h 2019-09-16
> 08:44:20.382086305 +0200
> @@ -61,14 +61,11 @@
> * Allocation method = Loudness
> * Subbands = 8
> */
> -#define SBC_BITPOOL_MQ_MONO_44100 19
> -#define SBC_BITPOOL_MQ_MONO_48000 18
> -#define SBC_BITPOOL_MQ_JOINT_STEREO_44100 35
> -#define SBC_BITPOOL_MQ_JOINT_STEREO_48000 33
> -#define SBC_BITPOOL_HQ_MONO_44100 31
> -#define SBC_BITPOOL_HQ_MONO_48000 29
> -#define SBC_BITPOOL_HQ_JOINT_STEREO_44100 53
> -#define SBC_BITPOOL_HQ_JOINT_STEREO_48000 51
> +
> +#define SBC_BITPOOL_HQ_MONO_44100 38
> +#define SBC_BITPOOL_HQ_MONO_48000 38
> +#define SBC_BITPOOL_HQ_JOINT_STEREO_44100 76
> +#define SBC_BITPOOL_HQ_JOINT_STEREO_48000 76
>
> #define MPEG_CHANNEL_MODE_MONO (1 << 3)
> #define MPEG_CHANNEL_MODE_DUAL_CHANNEL (1 << 2)
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] SBC XQ for PA 13.0
Hi,
Following what has already be done in some Android derivatives, here's a simple
patch that extend SBP bitpool negociation to XQ quality.
According to :
-->
http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
--> https://lineageos.org/engineering/Bluetooth-SBC-XQ/ ,
--> and confirmed by my own experimentation on more than 10 different devices,
here are the features of the (very simple and non intrusive) patch :
- allow to use bitpool 76 on devices that support it, aka SBC XQ
- harmless for devices limited to bitpool 53
- deprecates the need for APTX & APTX HD support, which are not better than SBC
XQ, are not Open Source, and less supported by devices
This patch will be superseded by multi-profiles Pali Rohar A2DP stack
implementation, when it's ready for production. Thanks to Pali for the help
testing many codec parameters.
Let me know if I have to clone the git to push my patch, or if a regular PA dev
could do it.
All the best
JP
diff -rNaud pulseaudio-13.0/src/modules/bluetooth/a2dp-codec-sbc.c
pulseaudio-13.0-new/src/modules/bluetooth/a2dp-codec-sbc.c
--- pulseaudio-13.0/src/modules/bluetooth/a2dp-codec-sbc.c 2019-09-13
15:20:03.0 +0200
+++ pulseaudio-13.0-new/src/modules/bluetooth/a2dp-codec-sbc.c 2019-09-16
08:57:50.363122019 +0200
@@ -290,10 +290,10 @@
return 0;
}
-if (capabilities->allocation_method & SBC_ALLOCATION_LOUDNESS)
-config->allocation_method = SBC_ALLOCATION_LOUDNESS;
-else if (capabilities->allocation_method & SBC_ALLOCATION_SNR)
+if (capabilities->allocation_method & SBC_ALLOCATION_SNR)
config->allocation_method = SBC_ALLOCATION_SNR;
+else if (capabilities->allocation_method & SBC_ALLOCATION_LOUDNESS)
+config->allocation_method = SBC_ALLOCATION_LOUDNESS;
else {
pa_log_error("No supported allocation method");
return 0;
diff -rNaud pulseaudio-13.0/src/modules/bluetooth/a2dp-codecs.h
pulseaudio-13.0-new/src/modules/bluetooth/a2dp-codecs.h
--- pulseaudio-13.0/src/modules/bluetooth/a2dp-codecs.h 2019-09-13
15:20:03.0 +0200
+++ pulseaudio-13.0-new/src/modules/bluetooth/a2dp-codecs.h 2019-09-16
08:44:20.382086305 +0200
@@ -61,14 +61,11 @@
* Allocation method = Loudness
* Subbands = 8
*/
-#define SBC_BITPOOL_MQ_MONO_44100 19
-#define SBC_BITPOOL_MQ_MONO_48000 18
-#define SBC_BITPOOL_MQ_JOINT_STEREO_44100 35
-#define SBC_BITPOOL_MQ_JOINT_STEREO_48000 33
-#define SBC_BITPOOL_HQ_MONO_44100 31
-#define SBC_BITPOOL_HQ_MONO_48000 29
-#define SBC_BITPOOL_HQ_JOINT_STEREO_44100 53
-#define SBC_BITPOOL_HQ_JOINT_STEREO_48000 51
+
+#define SBC_BITPOOL_HQ_MONO_44100 38
+#define SBC_BITPOOL_HQ_MONO_48000 38
+#define SBC_BITPOOL_HQ_JOINT_STEREO_44100 76
+#define SBC_BITPOOL_HQ_JOINT_STEREO_48000 76
#define MPEG_CHANNEL_MODE_MONO (1 << 3)
#define MPEG_CHANNEL_MODE_DUAL_CHANNEL (1 << 2)
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
