Re: [pulseaudio-discuss] [PATCH v11 08/11] bluetooth: Add more variants of SBC codec

2019-06-11 Thread ValdikSS 
On 10.06.2019 23:20, Pali Rohár wrote:
> On Monday 10 June 2019 20:37:43 ValdikSS wrote:
>> On 10.06.2019 17:53, Pali Rohár wrote:
>>> On Wednesday 05 June 2019 22:42:49 ValdikSS wrote:
>>>> On 02.06.2019 18:25, Pali Rohár wrote:
>>>>> Specify configuration for Low, Middle, High and Ultra High Quality of SBC
>>>>> codec. SBC codec in Ultra High 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 Ultra High Quality, calculated to minimize wasted bytes and to be 
>>>>> below max possible 512 kbps */
>>>>> +static const a2dp_sbc_t sbc_uhq1_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_uhq2_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 */
>>>>> +FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, 
>>>>> SBC_SAMPLING_FREQ_44100, 37), /* 226   kbps */
>>>>> +FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, 
>>>>> SBC_SAMPLING_FREQ_48000, 37), /* 246   kbps */
>>>>> +};
>>>> ...
>>>>
>>>> While working on Android SBC HD patch, allowing bitpools higher than 53 
>>>> unfortunately introduced problems with some headphones. All major OS have 
>>>> maximum bitpool locked to 53, and it seems there's a reason for that: 
>>>> compatibility with broken devices. I had to revert bitpool increasing 
>>>> patch in the final release and implement only Dual Channel patch.
>>> It is a problem if pulseaudio/bluez exports one SEP with fixed SBC
>>> bitpool 76 (min = max = 76) and another SEP with dynamic SBC bitpool
>>> range 2-53?
>> Probably not a problem, I'm not sure.
> Do you have test devices which have those "compatibility" problems?


Unfortunately not, but it breaks at least Denon AVR-X2100W receiver

https://review.lineageos.org/c/LineageOS/android_packages_apps_Bluetooth/+/229310#message-32480b69e039db9dd0fffdc68216ac1bdb70704e


>
>>>> Some notes regarding UHQ profiles:
>>>> 1. It would be great to use bitpool 38 for Dual Channel 2-DH5 (EDR 2 
>>>> mbit/s) and bitpool 47 for Dual Channel 3-DH5 (edr 3 mbit/s), 
>>>> automatically detecting link speed. It pushes bitrate even further for 
>>>> 3-DH5 compatible devices (551 kbit/s for 44.1 kHz, 5 audio frames) and 
>>>> makes SBC on par with aptX HD. That's what I did for Android patch.
>>> How can be detect link speed? Is there some kernel API for it? Or deduce
>>> it from socket send buffer size?
>> Android exports EDR speed into media encoder, I don't know of Linux BlueZ 
>> stack much. Can you determine link MTU from inside the PulseAudio?
> Yes, in pulseaudio we have access to socket and MTU can be determined...
> Pulseaudio A2DP codecs already use it for configuring send buffer size.
>
>> If you can, you can use that: if MTU is more than 679, than it's most 
>> probably 3-DH5 mode (EDR 3mbit/s with 5 slots).
>>>> 2. It's possible to introduce another "extreme quality" profile for 2-DH5 
>>>> (EDR 2 mbit/s) Dual Channel, with 648 kbps @ 48 khz, 595.4 kbps @ 44.1 khz 
>>>> (Up to 3 frames for 2DH5).
>>>>
>>>> By the way, SBC HD patch has been merged into LineageOS 15.1 (Android 8) 
>>>> and LineageOS 16.0 (Android 9). If you use LineageOS, you can now enable 
>>>> Dual Channel in Bluetooth device settings (it's called HD Audio: SBC HD).
>>>>
>>>> Besides my old SBC HD bitrate calculator 
>>>> (https://btcodecs.valdikss.org.ru/sbc-bitrate-calculator/), I made 
>>>> in-browser realtime SBC and aptX/HD encoder, with frequency spectrum 
>>>> analyzer. You can now easily experiment with Bluetooth codecs quality:
>>>> https://btcodecs.valdikss.org.ru/sbc-encoder/
>>>>



signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v11 08/11] bluetooth: Add more variants of SBC codec

2019-06-10 Thread ValdikSS 
On 10.06.2019 17:53, Pali Rohár wrote:
> On Wednesday 05 June 2019 22:42:49 ValdikSS wrote:
>> On 02.06.2019 18:25, Pali Rohár wrote:
>>> Specify configuration for Low, Middle, High and Ultra High Quality of SBC
>>> codec. SBC codec in Ultra High 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 Ultra High Quality, calculated to minimize wasted bytes and to be 
>>> below max possible 512 kbps */
>>> +static const a2dp_sbc_t sbc_uhq1_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_uhq2_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 */
>>> +FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_44100, 
>>> 37), /* 226   kbps */
>>> +FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_48000, 
>>> 37), /* 246   kbps */
>>> +};
>> ...
>>
>> While working on Android SBC HD patch, allowing bitpools higher than 53 
>> unfortunately introduced problems with some headphones. All major OS have 
>> maximum bitpool locked to 53, and it seems there's a reason for that: 
>> compatibility with broken devices. I had to revert bitpool increasing patch 
>> in the final release and implement only Dual Channel patch.
> It is a problem if pulseaudio/bluez exports one SEP with fixed SBC
> bitpool 76 (min = max = 76) and another SEP with dynamic SBC bitpool
> range 2-53?
Probably not a problem, I'm not sure.
>
>> Some notes regarding UHQ profiles:
>> 1. It would be great to use bitpool 38 for Dual Channel 2-DH5 (EDR 2 mbit/s) 
>> and bitpool 47 for Dual Channel 3-DH5 (edr 3 mbit/s), automatically 
>> detecting link speed. It pushes bitrate even further for 3-DH5 compatible 
>> devices (551 kbit/s for 44.1 kHz, 5 audio frames) and makes SBC on par with 
>> aptX HD. That's what I did for Android patch.
> How can be detect link speed? Is there some kernel API for it? Or deduce
> it from socket send buffer size?
Android exports EDR speed into media encoder, I don't know of Linux BlueZ stack 
much. Can you determine link MTU from inside the PulseAudio? If you can, you 
can use that: if MTU is more than 679, than it's most probably 3-DH5 mode (EDR 
3mbit/s with 5 slots).
>
>> 2. It's possible to introduce another "extreme quality" profile for 2-DH5 
>> (EDR 2 mbit/s) Dual Channel, with 648 kbps @ 48 khz, 595.4 kbps @ 44.1 khz 
>> (Up to 3 frames for 2DH5).
>>
>> By the way, SBC HD patch has been merged into LineageOS 15.1 (Android 8) and 
>> LineageOS 16.0 (Android 9). If you use LineageOS, you can now enable Dual 
>> Channel in Bluetooth device settings (it's called HD Audio: SBC HD).
>>
>> Besides my old SBC HD bitrate calculator 
>> (https://btcodecs.valdikss.org.ru/sbc-bitrate-calculator/), I made 
>> in-browser realtime SBC and aptX/HD encoder, with frequency spectrum 
>> analyzer. You can now easily experiment with Bluetooth codecs quality:
>> https://btcodecs.valdikss.org.ru/sbc-encoder/
>>



signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v11 08/11] bluetooth: Add more variants of SBC codec

2019-06-05 Thread ValdikSS 
On 02.06.2019 18:25, Pali Rohár wrote:
> Specify configuration for Low, Middle, High and Ultra High Quality of SBC
> codec. SBC codec in Ultra High 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 Ultra High Quality, calculated to minimize wasted bytes and to be 
> below max possible 512 kbps */
> +static const a2dp_sbc_t sbc_uhq1_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_uhq2_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 */
> +FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_44100, 
> 37), /* 226   kbps */
> +FIXED_SBC_CAPS(SBC_CHANNEL_MODE_MONO, SBC_SAMPLING_FREQ_48000, 
> 37), /* 246   kbps */
> +};
...

While working on Android SBC HD patch, allowing bitpools higher than 53 
unfortunately introduced problems with some headphones. All major OS have 
maximum bitpool locked to 53, and it seems there's a reason for that: 
compatibility with broken devices. I had to revert bitpool increasing patch in 
the final release and implement only Dual Channel patch.

Some notes regarding UHQ profiles:
1. It would be great to use bitpool 38 for Dual Channel 2-DH5 (EDR 2 mbit/s) 
and bitpool 47 for Dual Channel 3-DH5 (edr 3 mbit/s), automatically detecting 
link speed. It pushes bitrate even further for 3-DH5 compatible devices (551 
kbit/s for 44.1 kHz, 5 audio frames) and makes SBC on par with aptX HD. That's 
what I did for Android patch.
2. It's possible to introduce another "extreme quality" profile for 2-DH5 (EDR 
2 mbit/s) Dual Channel, with 648 kbps @ 48 khz, 595.4 kbps @ 44.1 khz (Up to 3 
frames for 2DH5).

By the way, SBC HD patch has been merged into LineageOS 15.1 (Android 8) and 
LineageOS 16.0 (Android 9). If you use LineageOS, you can now enable Dual 
Channel in Bluetooth device settings (it's called HD Audio: SBC HD).

Besides my old SBC HD bitrate calculator 
(https://btcodecs.valdikss.org.ru/sbc-bitrate-calculator/), I made in-browser 
realtime SBC and aptX/HD encoder, with frequency spectrum analyzer. You can now 
easily experiment with Bluetooth codecs quality:
https://btcodecs.valdikss.org.ru/sbc-encoder/



signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth aptX codec

2018-12-24 Thread ValdikSS 
I can't find any information regarding CSR True Wireless Stereo v3. What's 
that? Can you share documentation where you got information about these IDs?

On 19.12.2018 20:59, Pali Rohár wrote:
> On Thursday 09 August 2018 16:39:09 ValdikSS wrote:
>> 0xFF 0x000A 0x0103 — Unknown codec found on Bose QuietComfort QC35 II
> "The CSR True Wireless Stereo v3 Codec ID for SBC."
>
>> Value hex dump: 07 06 00 00 ff ff 02 35
> From information which I have, info payload is just embedded AVDTP media
> capability buffer.
>
> 07 - AVDTP_SERVICE_MEDIA_CODEC
> 06 - length
>
> 00 - AVDTP_MEDIA_TYPE_AUDIO
>
> 00 - A2DP_CODEC_SBC
> ff - SBC_CHANNEL_MODE_JOINT_STEREO | SBC_CHANNEL_MODE_STEREO |
>  SBC_CHANNEL_MODE_DUAL_CHANNEL | SBC_CHANNEL_MODE_MONO |
>  SBC_SAMPLING_FREQ_48000 | SBC_SAMPLING_FREQ_44100 |
>  SBC_SAMPLING_FREQ_32000 | SBC_SAMPLING_FREQ_16000
> ff - SBC_BLOCK_LENGTH_4 | SBC_BLOCK_LENGTH_8 |
>  SBC_BLOCK_LENGTH_12 | SBC_BLOCK_LENGTH_16 |
>  SBC_SUBBANDS_4 | SBC_SUBBANDS_8
>  SBC_ALLOCATION_SNR | SBC_ALLOCATION_LOUDNESS
> 02 - min bitpool
> 35 - max bitpool
>
> So it matches SBC definition buffer as expected.
>
>> 0xFF 0x000A 0x0104 — Unknown codec found on Bose QuietComfort QC35 II
> "The CSR True Wireless Stereo v3 Codec ID for AAC."
>
>> Value hex dump: 07 08 00 02 c0 ff 8c 84 e2 00
> Again, it should be embedded AVDTP media capability buffer.
>
> 07 - AVDTP_SERVICE_MEDIA_CODEC
> 08 - length
>
> 00 - AVDTP_MEDIA_TYPE_AUDIO
>
> 02 - A2DP_CODEC_MPEG24
> c0 - AAC_OBJECT_TYPE_MPEG2_AAC_LC | AAC_OBJECT_TYPE_MPEG4_AAC_LTP |
>  AAC_OBJECT_TYPE_MPEG4_AAC_SCA
> ff 8c - frequences: all; channels: all
> 84 e2 00 - VBR; bitrate: 32
>
> So also MPEG2/4 AAC buffer is correct.
>
>
> Moreover there also exist these codecs:
>
> 0xFF 0x000A 0x0105 - The CSR True Wireless Stereo v3 Codec ID for MP3.
> 0xFF 0x000A 0x0106 - The CSR True Wireless Stereo v3 Codec ID for AptX.
>
> And again capability buffer should contain embedded AVDTP media
> capability buffer for MPEG1 (with Layyer 3) and for aptX.
>



signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Pulseaudio bluez sink

2018-11-29 Thread ValdikSS 
Are you sure the problem is in Pulseaudio or Bluez? From my tests, some 
Bluetooth devices (especially receivers) have audio post-processing pipeline 
and mute the output if audio signal is too low.
Try to play a very quiet sound (set PA volume to the minimum and use softvolume 
in your audio player). If you can't hear it, or the audio is interrupting, than 
the problem is in speaker internals.

On 29.11.2018 11:42, Harish Gaddameedi wrote:
> Hi all,
> 
> Pulseaudio is not playing the Audio at the 1st second of file, when the 
> device is connected and audio is playing from External Bluetooth speaker from 
> A2DP profile. If sink is already running then audio is playing properly. 
> 
> I have tried by commenting *module-suspend-on-idle* in *default.pa 
> * and *system.pa  *mentioned in 
> *https://unix.stackexchange.com/questions/184684/audio-play-not-starting-at-beginning
>  *but no results found.
> 
> Any help will be very thankful.
> 
> -- 
> Regards,
> Harish Gaddameedi
> 
> 
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> 





signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth aptX codec

2018-10-31 Thread ValdikSS 
On 10.08.2018 20:35, ValdikSS wrote:
>
> On 10.08.2018 13:31, ValdikSS wrote:
>> On 10.08.2018 10:57, Pali Rohár wrote:
>>> On Thursday 09 August 2018 16:39:09 ValdikSS wrote:
>>>> On 06.07.2018 13:25, Pali Rohár wrote:
>>>>> I did some investigation and basically this is the list of all known
>>>>> codecs used in A2DP:
>>>>>
>>>>> Mandatory:
>>>>> 0x00 - SBC
>>>>>
>>>>> Optional:
>>>>> 0x01 - MPEG-1,2 (aka MP3)
>>>>> 0x02 - MPEG-2,4 (aka AAC)
>>>>> 0x04 - ATRAC
>>>>>
>>>>> Vendor specific:
>>>>> 0xFF 0x004F 0x01 - aptX
>>>>> 0xFF 0x000A 0x01 - FastStream
>>>>> 0xFF 0x000A 0x02 - aptX Low Latency
>>>>> 0xFF 0x00D7 0x24 - aptX HD
>>>>> 0xFF 0x012D 0xAA - LDAC
>>>>>
>>>>> And also I found some references that some sort of raw 16bit PCM samples
>>>>> via codec id 0x05 are used... But I have never seen such product.
>>>>>
>>>> Could it be Samsung UHQ-BT?
>>>> https://www.samsung.com/uk/mobile-accessories/level-on-pro-wireless-headset-pn920/EO-PN920CFEGWW/
>>>>
>>>> There are also:
>>>> 0xFF 0x0075 0x0102 — Samsung HD (found on Samsung LEVEL Link)
>>>> Value hex dump: 7a
>>>>
>>>> 0xFF 0x000A 0x0103 — Unknown codec found on Bose QuietComfort QC35 II
>>>> Value hex dump: 07 06 00 00 ff ff 02 35
>>>>
>>>> 0xFF 0x000A 0x0104 — Unknown codec found on Bose QuietComfort QC35 II
>>>> Value hex dump: 07 08 00 02 c0 ff 8c 84 e2 00
>>>>
>>>>
>>>> Samsung LEVEL on/on pro also have support for what Samsung call "Scalable 
>>>> Codec".
>>> Interesting... I have not found any information about these A2DP codecs.
>>> I guess that "0xFF 0x0075 0x0102" would be that Samsung Scalable Codec.
>>> But others two allocated in QTIL vendor ID seems like some Qualcomm
>>> specific codec, or some variant of low latency codec or variant of aptX
>>> codec.
>>>
>> "0xFF 0x0075 0x0102" is a Samsung HD codec. Scalable codec and UHQ-BT are 
>> two another codecs from Samsung. You can choose between Samsung HD and 
>> Scalable Codec A2DP codecs on Samsung Android devices.
>> https://img.gadgethacks.com/img/32/08/63656409124633/0/improve-bluetooth-audio-your-galaxy-s9-with-custom-codecs.w1456.jpg
>>
>> Bose headset where unknown CSR codecs have been found has no license for 
>> aptX. It supports only SBC, AAC and these two unknown codecs.
>>
>> Scalable codec should be supported in Samsung U Flex and Samsung Gear IconX 
>> 2018. UHQ-BT could be found in Samsung LEVEL on pro.
>> I'll try to make a dump of Samsung U Flex or Samsung Gear IconX 2018, but 
>> Samsung LEVEL on pro are rather rare nowadays.
>>
> 0xFF 0x0075 0x0103 — Samsung Scalable Codec
> Raw value: 7a
>
> Connection established (SetConfiguration) with raw value 28.
> Dumped from Samsung Galaxy S7 edge - Samsung U Flex
>
>

0xFF 0x053A 0x484C — Savitech LHDC

https://www.hwa-lhdc.org/how-it-works




signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] Absolute volume control for A2DP transport

2018-10-20 Thread ValdikSS 
There are Bluetooth devices which support absolute volume but does not handle 
it correctly. For example, some Bluetooth headsets are unacceptable loud on the 
lowest volume, that's why it's better to completely disable absolute volume 
control for such devices.
Google created a database for broken devices for Android, which I have linked. 
Please add these exceptions if possible.

On 14.10.2018 21:54, ValdikSS wrote:
> Can you please integrate exceptions from the Android database?
> https://android.googlesource.com/platform/system/bt/+/master/device/include/interop_database.h
> Ones with INTEROP_DISABLE_ABSOLUTE_VOLUME
> 
> 
> On 03/10/2018 16:12, EHfive wrote:
>> On 10/3/18 8:37 PM, EHfive wrote:
>>> Require bluez-tools/mpris-proxy running. (No hurt if dosen't)
>>>
>>> If you need play/pause/next... controls , add configurations below to 
>>> /etc/dbus-1/system.d/
>>>
>>>  mpris.conf
>>>
>>> >> 1.0//EN"
>>>  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;>
>>> 
>>>   
>>>     
>>>   
>>> 
>>>
>>> 
>>>
>> An alternative
>>
>> https://gist.github.com/EHfive/e2a28d0279a6247fab4bac93d73b8571
>>
>> A python script which implement org.mpris.MediaPlayer2.Player and register 
>> mpris player object by calling org.bluez.Media1.RegisterPlayer.
>>
>>> ===
>>>
>>> diff --git a/src/modules/bluetooth/bluez5-util.c 
>>> b/src/modules/bluetooth/bluez5-util.c
>>> index 2d83373..72cd05a 100644
>>> --- a/src/modules/bluetooth/bluez5-util.c
>>> +++ b/src/modules/bluetooth/bluez5-util.c
>>> @@ -348,6 +348,50 @@ void 
>>> pa_bluetooth_transport_free(pa_bluetooth_transport *t) {
>>>  pa_xfree(t);
>>>  }
>>>
>>> +static int bluez5_transport_set_property(pa_bluetooth_transport *t, const 
>>> char *prop_name, int prop_type, void *prop_value){
>>> +    DBusMessage *m, *r;
>>> +    DBusError err;
>>> +    DBusMessageIter i;
>>> +    const char * interface = BLUEZ_MEDIA_TRANSPORT_INTERFACE;
>>> +
>>> +    pa_log_debug("Setting property, Owner: %s; Path: %s; Property: 
>>> %s",t->owner, t->path, prop_name);
>>> +
>>> +    pa_assert(t);
>>> +    pa_assert(t->device);
>>> +    pa_assert(t->device->discovery);
>>> +
>>> +    dbus_error_init();
>>> +
>>> +    pa_assert_se(m = dbus_message_new_method_call(t->owner, t->path, 
>>> "org.freedesktop.DBus.Properties", "Set"));
>>> +
>>> +    dbus_message_iter_init_append(m, );
>>> +
>>> +    pa_assert_se(dbus_message_iter_append_basic(, DBUS_TYPE_STRING, 
>>> ));
>>> +    pa_assert_se(dbus_message_iter_append_basic(, DBUS_TYPE_STRING, 
>>> _name));
>>> +    pa_dbus_append_basic_variant(, prop_type, prop_value);
>>> +
>>> +    r = 
>>> dbus_connection_send_with_reply_and_block(pa_dbus_connection_get(t->device->discovery->connection),
>>>  m, -1, );
>>> +    dbus_message_unref(m);
>>> +    m = NULL;
>>> +    if(r) {
>>> +    dbus_message_unref(r);
>>> +    r = NULL;
>>> +    }
>>> +
>>> +    if(dbus_error_is_set()) {
>>> +    pa_log_debug("Failed to set property \"%s.%s\"", interface, 
>>> prop_name);
>>> +    return -1;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int bluez5_transport_set_volume(pa_bluetooth_transport *t, uint16_t 
>>> volume){
>>> +    if(t->a2dp_gain == volume)
>>> +    return 0;
>>> +    return bluez5_transport_set_property(t, "Volume", DBUS_TYPE_UINT16, 
>>> );
>>> +}
>>> +
>>>  static int bluez5_transport_acquire_cb(pa_bluetooth_transport *t, bool 
>>> optional, size_t *imtu, size_t *omtu) {
>>>  DBusMessage *m, *r;
>>>  DBusError err;
>>> @@ -441,6 +485,14 @@ bool pa_bluetooth_device_any_transport_connected(const 
>>> pa_bluetooth_device *d) {
>>>  return false;
>>>  }
>>>
>>> +void pa_transport_set_a2dp_gain(pa_bluetooth_transport *t, uint16_t 
>>> a2dp_gain){
>>> +    if(t->a2dp_gain == a2dp_gain)
>>> +    return;
>>> +    t->a2dp_gain = a2dp_gain;
>>> + pa_hook_fire(pa_bluetooth_discovery_h

Re: [pulseaudio-discuss] [PATCH] Absolute volume control for A2DP transport

2018-10-14 Thread ValdikSS 
Can you please integrate exceptions from the Android database?
https://android.googlesource.com/platform/system/bt/+/master/device/include/interop_database.h
Ones with INTEROP_DISABLE_ABSOLUTE_VOLUME


On 03/10/2018 16:12, EHfive wrote:
> On 10/3/18 8:37 PM, EHfive wrote:
>> Require bluez-tools/mpris-proxy running. (No hurt if dosen't)
>>
>> If you need play/pause/next... controls , add configurations below to 
>> /etc/dbus-1/system.d/
>>
>>  mpris.conf
>>
>> > 1.0//EN"
>>  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;>
>> 
>>   
>>     
>>   
>> 
>>
>> 
>>
> An alternative
> 
> https://gist.github.com/EHfive/e2a28d0279a6247fab4bac93d73b8571
> 
> A python script which implement org.mpris.MediaPlayer2.Player and register 
> mpris player object by calling org.bluez.Media1.RegisterPlayer.
> 
>> ===
>>
>> diff --git a/src/modules/bluetooth/bluez5-util.c 
>> b/src/modules/bluetooth/bluez5-util.c
>> index 2d83373..72cd05a 100644
>> --- a/src/modules/bluetooth/bluez5-util.c
>> +++ b/src/modules/bluetooth/bluez5-util.c
>> @@ -348,6 +348,50 @@ void pa_bluetooth_transport_free(pa_bluetooth_transport 
>> *t) {
>>  pa_xfree(t);
>>  }
>>
>> +static int bluez5_transport_set_property(pa_bluetooth_transport *t, const 
>> char *prop_name, int prop_type, void *prop_value){
>> +    DBusMessage *m, *r;
>> +    DBusError err;
>> +    DBusMessageIter i;
>> +    const char * interface = BLUEZ_MEDIA_TRANSPORT_INTERFACE;
>> +
>> +    pa_log_debug("Setting property, Owner: %s; Path: %s; Property: 
>> %s",t->owner, t->path, prop_name);
>> +
>> +    pa_assert(t);
>> +    pa_assert(t->device);
>> +    pa_assert(t->device->discovery);
>> +
>> +    dbus_error_init();
>> +
>> +    pa_assert_se(m = dbus_message_new_method_call(t->owner, t->path, 
>> "org.freedesktop.DBus.Properties", "Set"));
>> +
>> +    dbus_message_iter_init_append(m, );
>> +
>> +    pa_assert_se(dbus_message_iter_append_basic(, DBUS_TYPE_STRING, 
>> ));
>> +    pa_assert_se(dbus_message_iter_append_basic(, DBUS_TYPE_STRING, 
>> _name));
>> +    pa_dbus_append_basic_variant(, prop_type, prop_value);
>> +
>> +    r = 
>> dbus_connection_send_with_reply_and_block(pa_dbus_connection_get(t->device->discovery->connection),
>>  m, -1, );
>> +    dbus_message_unref(m);
>> +    m = NULL;
>> +    if(r) {
>> +    dbus_message_unref(r);
>> +    r = NULL;
>> +    }
>> +
>> +    if(dbus_error_is_set()) {
>> +    pa_log_debug("Failed to set property \"%s.%s\"", interface, 
>> prop_name);
>> +    return -1;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +static int bluez5_transport_set_volume(pa_bluetooth_transport *t, uint16_t 
>> volume){
>> +    if(t->a2dp_gain == volume)
>> +    return 0;
>> +    return bluez5_transport_set_property(t, "Volume", DBUS_TYPE_UINT16, 
>> );
>> +}
>> +
>>  static int bluez5_transport_acquire_cb(pa_bluetooth_transport *t, bool 
>> optional, size_t *imtu, size_t *omtu) {
>>  DBusMessage *m, *r;
>>  DBusError err;
>> @@ -441,6 +485,14 @@ bool pa_bluetooth_device_any_transport_connected(const 
>> pa_bluetooth_device *d) {
>>  return false;
>>  }
>>
>> +void pa_transport_set_a2dp_gain(pa_bluetooth_transport *t, uint16_t 
>> a2dp_gain){
>> +    if(t->a2dp_gain == a2dp_gain)
>> +    return;
>> +    t->a2dp_gain = a2dp_gain;
>> + pa_hook_fire(pa_bluetooth_discovery_hook(t->device->discovery, 
>> PA_BLUETOOTH_HOOK_TRANSPORT_A2DP_GAIN_CHANGED), t);
>> +}
>> +
>> +
>>  static int transport_state_from_string(const char* value, 
>> pa_bluetooth_transport_state_t *state) {
>>  pa_assert(value);
>>  pa_assert(state);
>> @@ -483,6 +535,18 @@ static void 
>> parse_transport_property(pa_bluetooth_transport *t, DBusMessageIter
>>  pa_bluetooth_transport_set_state(t, state);
>>  }
>>
>> +    break;
>> +    }
>> +    case DBUS_TYPE_UINT16: {
>> +
>> +    uint16_t value;
>> +    dbus_message_iter_get_basic(_i, );
>> +
>> +    if (pa_streq(key, "Volume")) {
>> +    pa_log_debug("Transport Volume Changed to %u ", value);
>> +    pa_transport_set_a2dp_gain(t, value);
>> +    }
>> +
>>  break;
>>  }
>>  }
>> @@ -1468,6 +1532,7 @@ static DBusMessage 
>> *endpoint_set_configuration(DBusConnection *conn, DBusMessage
>>  t = pa_bluetooth_transport_new(d, sender, path, p, config, size);
>>  t->acquire = bluez5_transport_acquire_cb;
>>  t->release = bluez5_transport_release_cb;
>> +    t->set_volume = bluez5_transport_set_volume;
>>  pa_bluetooth_transport_put(t);
>>
>>  pa_log_debug("Transport %s available for profile %s", t->path, 
>> pa_bluetooth_profile_to_string(t->profile));
>> diff --git a/src/modules/bluetooth/bluez5-util.h 
>> b/src/modules/bluetooth/bluez5-util.h
>> index ad30708..5b8149d 100644
>> --- a/src/modules/bluetooth/bluez5-util.h
>> +++ b/src/modules/bluetooth/bluez5-util.h
>> @@ -47,6 +47,7 @@

Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality

2018-09-14 Thread ValdikSS 
On 14/09/2018 16:42, Luiz Augusto von Dentz wrote:
>> I propose to use 76 bitpool as a default maximum (454.8 kbps for Joint 
>> Stereo, 44.1 kHz, 8 subbands, 16 blocks). This bitpool is optimal for both 
>> EDR 2 mbit/s and EDR 3 mbit/s modes, since it packs audio frames with least 
>> wasted bytes possible.
>> EDR 2 mbit/s: up to 4 audio frames, 11.7 ms, 2 wasted bytes
>> EDR 3 mbit/s: up to 6 audio frames, 17.5 ms, 14 wasted bytes.
> That is a bit too hight I would say, and not sure if there would be
> any headset to make use of it.

This bitrate utilizes 2-DH5 and 3-DH5 packet types (the most common ones for 
audio streaming) as optimally as possible.

2-DH5 maximum payload size is 679 bytes. With bitpool 64, you can fill the 
packet with 4 audio frames (11.7 ms), which will take 564 bytes, and 98 bytes 
are wasted (679 - 12 L2CAP header - 4 RTP header - 1 SBC header). With bitpool 
76, you can fill the packet with the same 4 audio frames and 11.7 ms audio, but 
it will take 660 bytes, and only 2 bytes are wasted.

Bluetooth uses TDMA and transfers DH5 packets in 3.75 ms. You won't get higher 
packet rate or higher reliability if you send packets with less data than the 
packet can possible contain.

There are some headsets with higher or unlimited bitpool value:

Beats Solo³: bitpool 2..250
AirPods: bitpool 2..250
JBL Everest Elite 750NC: bitpool 10..80

>
>> Note that Pulseaudio/bluez (not sure which) does not manage L2CAP MTU 
>> correctly. For EDR 2 mbit/s, MTU should be set to 679 (ignoring higher 
>> values upon negotiation), and EDR 3 mbit/s should use 1021 (right now 
>> something like 800 is used).
> We could do that if we know the packet type used by the link but that
> is not how it is currently done in BlueZ, we always use L2CAP default
> in case the socket don't set it:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/include/net/bluetooth/l2cap.h#n34
>
> Where did you get these values from btw?

These are max payload sizes for 2-DH5 and 3-DH5
http://www.osted.dk/bluetooth/bt_transfer_rate.html
It's reasonable to use these values as an MTU to prevent packet fragmentation 
on a lower levels.
Android does that.





signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality

2018-09-14 Thread ValdikSS 
On 13/09/2018 11:23, Tanu Kaskinen wrote:
> 
> How is the bitrate calculated? I'd like to write a section on the
> Bluetooth wiki page[1] that explains the SBC codec with a table showing
> how the different parameters affect the bitrate.
> 
> [1] 
> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/
> 

Bitrate formula could be found in A2DP specification:
https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=303201
Page 70.

Here's a convenient calculator:
https://btcodecs.valdikss.org.ru/sbc-bitrate-calculator/



signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality

2018-09-14 Thread ValdikSS 
On 12/09/2018 19:03, Luiz Augusto von Dentz wrote:
>> 2) Should we rather look at increasing quality of SBC codec in
>> pulseaudio? And if yes, how should be quality of SBC configured? Via
>> profiles? Or to invent some new protocol options? Can we increase
>> default SBC bitpool allocation?
> 
> I recall setting it to 64 before, but perhaps we are using 53 given
> that most headset set that as maximum influenced by the spec suggested
> values, I wouldn't go above 512kbit/s since then leave very little
> room for any other traffic.

I propose to use 76 bitpool as a default maximum (454.8 kbps for Joint Stereo, 
44.1 kHz, 8 subbands, 16 blocks). This bitpool is optimal for both EDR 2 mbit/s 
and EDR 3 mbit/s modes, since it packs audio frames with least wasted bytes 
possible.
EDR 2 mbit/s: up to 4 audio frames, 11.7 ms, 2 wasted bytes
EDR 3 mbit/s: up to 6 audio frames, 17.5 ms, 14 wasted bytes.

Note that Pulseaudio/bluez (not sure which) does not manage L2CAP MTU 
correctly. For EDR 2 mbit/s, MTU should be set to 679 (ignoring higher values 
upon negotiation), and EDR 3 mbit/s should use 1021 (right now something like 
800 is used).

> 
>> 3) If aptX is decided as useless, what about aptX HD codec? aptX HD
>> codec is supported by less products (currently I do not own any), but
>> this one may provide better quality as SBC according to that research.
> 
> That is probably useful as something that provides a quality
> improvement compared to SBC.
> 
>> PS: That aptX research is the first and the only one about which I know.
>> All other information about quality or other details which I found on
>> internet are just marking informations.
> 
> I had some suspicion before given that no manufacturer provided any
> evidence aptX would beat SBC at the same bitrate, it is probably
> better just because we are stuck at 53 bitpool with SBC while aptX can
> probably have much higher bitrate. Anyway thanks to the researcher for
> putting the time to evaluate the codecs we now have a good reference
> for the quality each codec provides.
> 
> 
>> --
>> Pali Rohár
>> pali.ro...@gmail.com
>> ___
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality

2018-09-14 Thread ValdikSS 
On 12/09/2018 13:42, Pali Rohár wrote:
> Hello!
> 
> I would like to let you know that Serge from soundexpert.org did in last
> month some research on aptX and its quality. Detailed article is on the
> following website, specially see parts added around "August 2018":
> 
> http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
> 
> 
> Conclusions:
> 
> aptX codec used in BT applications is no better than SBC@328. Despite
> slightly lower algorithmic delay of aptX both SBC and aptX codecs
> provide the same 100-150ms latency in real-life BT applications.
> 
> If you hear the difference between SBC and aptX in some BT product,
> there can be only two explanations - placebo effect or using SBC in
> Middle or Low Quality modes.

This is not exactly true. I believe Sergey's tests are not suited well for 
ADPCM codecs, since almost all modern phycho acoustic lossy codecs are trying 
to hide unhearable details while ADPCM works differently.
So I'm not sure if ADPCM (aptX) and SBC codecs should be compared with the 
waveforms, as SBC will introduce less distortion in most cases but aptX may be 
better for the ears, especially for the people who complain for the lack of 
high frequencies using SBC. For me, it's almost the same, but 2 of my friends 
differs aptX from SBC (Joint Stereo, 328 kbit/s) 100% of the time on certain 
due to lack of high frequencies. I personally can't hear more than 16.5 kHz, so 
I pitch-shift encoded audio down to hearable frequency to hear what my friends 
can hear.
SBC can provide better results than aptX. On average, compared to SBC 328k, 
aptX makes less distortion in music with a wide frequency range, but on music 
with a narrow frequency range and a wide dynamic range SBC 328k sometimes wins.

Here's Sergey's reply:

> Yes, in general case assessment of sound quality by comparing waveforms is a 
> bad practice. In my research I contend that this could be done only in some 
> special cases. When sound signatures (which are, in fact, artifact 
> signatures) are close. Analysis of the codecs similarity showed that in this 
> case sound quality can be judged by the level of the initial waveform 
> distortion (provided that sufficient amount of music material is used). The 
> criteria of similarity was taken from my earlier research which is still in 
> progress. I don't know, whether there is some fundamental flaw in my approach 
> or it is just a natural accuracy of the method (1.5dB is relatively small 
> value of difference). Anyway, that are the results as they are, you may 
> consider them with a grain of salt.


Here are my simple tests:
https://forum.xda-developers.com/showpost.php?p=77408975=4
While they are also not great, I thought it's sane to compare encoding results 
with spectrograms of ADPCM/APCM codecs.
I tried to use EAQUAL software to compare SBC and aptX. Some results are very 
relevant (Noise-To-Mask-Ratio, Relative Disturbed Frames, various differences) 
but some are controversial (Objective Difference Grade).

Please also read other information in this link. I made a patch for Android 
LineageOS for Dual Channel support, and thinking on adding this functionality 
to Pulseaudio.
https://review.lineageos.org/#/c/LineageOS/android_system_bt/+/228548/


> 
> AptX is just a copper-less overpriced audio cable.

aptX and aptX HD have a strictly defined profiles which could not be changed 
without encoder and decoder modifications. Neither headphone manufacturer nor 
Bluetooth stack manufacturer can change them. This is a strong side of the 
codec, you always know what audio quality you will get with them, no buts.
With SBC you don't know what audio quality you will get before trying. SBC can 
produce very low quality audio to very high quality audio (on par or better 
than aptX HD), but you'll almost never get very high quality audio without 
disabling or circumventing artificial limitations.

> 
> 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)
> 
> 
> And it just confirms my own testing. Whatever I did I was not able to
> either hear or see difference between aptX and SBC encoded-->decoded
> audio.
> 
> I had discussion with Serge and there are some ideas which Linux
> Bluetooth A2DP software could supports:
> 
> 1) Allow user to specify SBC codec quality. In most cases, including
> pulseaudio, SBC quality is chosen either to middle or low, not to
> maximum bitpool. In some cases SBC at high quality can provide better
> quality as aptX and more important -- SBC is supported by all headsets.
> 
> 2) Show user current SBC codec quality. So user would know what was
> chosen and what should expect. I was told that Windows's Toshiba
> bluetooth stack has support for this indication.
> 
> 3) In some cases SBC SNR bit allocation method can provide better
> quality as SBC loudness method.

I don't know why SNR method shows

Re: [pulseaudio-discuss] Bluetooth aptX codec

2018-08-27 Thread ValdikSS 
On 09.08.2018 16:39, ValdikSS wrote:
> On 06.07.2018 13:25, Pali Rohár wrote:
>> I did some investigation and basically this is the list of all known
>> codecs used in A2DP:
>>
>> Mandatory:
>> 0x00 - SBC
>>
>> Optional:
>> 0x01 - MPEG-1,2 (aka MP3)
>> 0x02 - MPEG-2,4 (aka AAC)
>> 0x04 - ATRAC
>>
>> Vendor specific:
>> 0xFF 0x004F 0x01 - aptX
>> 0xFF 0x000A 0x01 - FastStream
>> 0xFF 0x000A 0x02 - aptX Low Latency

aptX Low Latency is also 0xFF 0x00D7 0x02.

>> 0xFF 0x00D7 0x24 - aptX HD
>> 0xFF 0x012D 0xAA - LDAC
>>
>> And also I found some references that some sort of raw 16bit PCM samples
>> via codec id 0x05 are used... But I have never seen such product.
>>
>




signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth aptX codec

2018-08-16 Thread ValdikSS 
On 09.08.2018 16:39, ValdikSS wrote:
> On 06.07.2018 13:25, Pali Rohár wrote:
>> I did some investigation and basically this is the list of all known
>> codecs used in A2DP:
>>
>> Mandatory:
>> 0x00 - SBC
>>
>> Optional:
>> 0x01 - MPEG-1,2 (aka MP3)
>> 0x02 - MPEG-2,4 (aka AAC)
>> 0x04 - ATRAC
>>
>> Vendor specific:
>> 0xFF 0x004F 0x01 - aptX
>> 0xFF 0x000A 0x01 - FastStream
>> 0xFF 0x000A 0x02 - aptX Low Latency
>> 0xFF 0x00D7 0x24 - aptX HD
>> 0xFF 0x012D 0xAA - LDAC
>>
>> And also I found some references that some sort of raw 16bit PCM samples
>> via codec id 0x05 are used... But I have never seen such product.
>>
> Could it be Samsung UHQ-BT?
> https://www.samsung.com/uk/mobile-accessories/level-on-pro-wireless-headset-pn920/EO-PN920CFEGWW/
>
> There are also:
> 0xFF 0x0075 0x0102 — Samsung HD (found on Samsung LEVEL Link)
> Value hex dump: 7a
>
> 0xFF 0x000A 0x0103 — Unknown codec found on Bose QuietComfort QC35 II
> Value hex dump: 07 06 00 00 ff ff 02 35
>
> 0xFF 0x000A 0x0104 — Unknown codec found on Bose QuietComfort QC35 II
> Value hex dump: 07 08 00 02 c0 ff 8c 84 e2 00
>
>
> Samsung LEVEL on/on pro also have support for what Samsung call "Scalable 
> Codec".

0xFF 0x000A 0x0106 — Unknown codec found on LEVN SK-BTI-031 bluetooth receiver
Value hex dump: 07 09 00 ff 4f 00 00 00 01 00 32

This receiver also supports unknown codecs 0x0103 and 0x0104 with the same 
values as shown in previous message.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth aptX codec

2018-08-10 Thread ValdikSS 


On 10.08.2018 13:31, ValdikSS wrote:
> On 10.08.2018 10:57, Pali Rohár wrote:
>> On Thursday 09 August 2018 16:39:09 ValdikSS wrote:
>>> On 06.07.2018 13:25, Pali Rohár wrote:
>>>> I did some investigation and basically this is the list of all known
>>>> codecs used in A2DP:
>>>>
>>>> Mandatory:
>>>> 0x00 - SBC
>>>>
>>>> Optional:
>>>> 0x01 - MPEG-1,2 (aka MP3)
>>>> 0x02 - MPEG-2,4 (aka AAC)
>>>> 0x04 - ATRAC
>>>>
>>>> Vendor specific:
>>>> 0xFF 0x004F 0x01 - aptX
>>>> 0xFF 0x000A 0x01 - FastStream
>>>> 0xFF 0x000A 0x02 - aptX Low Latency
>>>> 0xFF 0x00D7 0x24 - aptX HD
>>>> 0xFF 0x012D 0xAA - LDAC
>>>>
>>>> And also I found some references that some sort of raw 16bit PCM samples
>>>> via codec id 0x05 are used... But I have never seen such product.
>>>>
>>> Could it be Samsung UHQ-BT?
>>> https://www.samsung.com/uk/mobile-accessories/level-on-pro-wireless-headset-pn920/EO-PN920CFEGWW/
>>>
>>> There are also:
>>> 0xFF 0x0075 0x0102 — Samsung HD (found on Samsung LEVEL Link)
>>> Value hex dump: 7a
>>>
>>> 0xFF 0x000A 0x0103 — Unknown codec found on Bose QuietComfort QC35 II
>>> Value hex dump: 07 06 00 00 ff ff 02 35
>>>
>>> 0xFF 0x000A 0x0104 — Unknown codec found on Bose QuietComfort QC35 II
>>> Value hex dump: 07 08 00 02 c0 ff 8c 84 e2 00
>>>
>>>
>>> Samsung LEVEL on/on pro also have support for what Samsung call "Scalable 
>>> Codec".
>> Interesting... I have not found any information about these A2DP codecs.
>> I guess that "0xFF 0x0075 0x0102" would be that Samsung Scalable Codec.
>> But others two allocated in QTIL vendor ID seems like some Qualcomm
>> specific codec, or some variant of low latency codec or variant of aptX
>> codec.
>>
> "0xFF 0x0075 0x0102" is a Samsung HD codec. Scalable codec and UHQ-BT are two 
> another codecs from Samsung. You can choose between Samsung HD and Scalable 
> Codec A2DP codecs on Samsung Android devices.
> https://img.gadgethacks.com/img/32/08/63656409124633/0/improve-bluetooth-audio-your-galaxy-s9-with-custom-codecs.w1456.jpg
>
> Bose headset where unknown CSR codecs have been found has no license for 
> aptX. It supports only SBC, AAC and these two unknown codecs.
>
> Scalable codec should be supported in Samsung U Flex and Samsung Gear IconX 
> 2018. UHQ-BT could be found in Samsung LEVEL on pro.
> I'll try to make a dump of Samsung U Flex or Samsung Gear IconX 2018, but 
> Samsung LEVEL on pro are rather rare nowadays.
>

0xFF 0x0075 0x0103 — Samsung Scalable Codec
Raw value: 7a

Connection established (SetConfiguration) with raw value 28.
Dumped from Samsung Galaxy S7 edge - Samsung U Flex


___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth aptX codec

2018-08-10 Thread ValdikSS 
On 10.08.2018 10:57, Pali Rohár wrote:
> On Thursday 09 August 2018 16:39:09 ValdikSS wrote:
>> On 06.07.2018 13:25, Pali Rohár wrote:
>>> I did some investigation and basically this is the list of all known
>>> codecs used in A2DP:
>>>
>>> Mandatory:
>>> 0x00 - SBC
>>>
>>> Optional:
>>> 0x01 - MPEG-1,2 (aka MP3)
>>> 0x02 - MPEG-2,4 (aka AAC)
>>> 0x04 - ATRAC
>>>
>>> Vendor specific:
>>> 0xFF 0x004F 0x01 - aptX
>>> 0xFF 0x000A 0x01 - FastStream
>>> 0xFF 0x000A 0x02 - aptX Low Latency
>>> 0xFF 0x00D7 0x24 - aptX HD
>>> 0xFF 0x012D 0xAA - LDAC
>>>
>>> And also I found some references that some sort of raw 16bit PCM samples
>>> via codec id 0x05 are used... But I have never seen such product.
>>>
>> Could it be Samsung UHQ-BT?
>> https://www.samsung.com/uk/mobile-accessories/level-on-pro-wireless-headset-pn920/EO-PN920CFEGWW/
>>
>> There are also:
>> 0xFF 0x0075 0x0102 — Samsung HD (found on Samsung LEVEL Link)
>> Value hex dump: 7a
>>
>> 0xFF 0x000A 0x0103 — Unknown codec found on Bose QuietComfort QC35 II
>> Value hex dump: 07 06 00 00 ff ff 02 35
>>
>> 0xFF 0x000A 0x0104 — Unknown codec found on Bose QuietComfort QC35 II
>> Value hex dump: 07 08 00 02 c0 ff 8c 84 e2 00
>>
>>
>> Samsung LEVEL on/on pro also have support for what Samsung call "Scalable 
>> Codec".
> Interesting... I have not found any information about these A2DP codecs.
> I guess that "0xFF 0x0075 0x0102" would be that Samsung Scalable Codec.
> But others two allocated in QTIL vendor ID seems like some Qualcomm
> specific codec, or some variant of low latency codec or variant of aptX
> codec.
>
"0xFF 0x0075 0x0102" is a Samsung HD codec. Scalable codec and UHQ-BT are two 
another codecs from Samsung. You can choose between Samsung HD and Scalable 
Codec A2DP codecs on Samsung Android devices.
https://img.gadgethacks.com/img/32/08/63656409124633/0/improve-bluetooth-audio-your-galaxy-s9-with-custom-codecs.w1456.jpg

Bose headset where unknown CSR codecs have been found has no license for aptX. 
It supports only SBC, AAC and these two unknown codecs.

Scalable codec should be supported in Samsung U Flex and Samsung Gear IconX 
2018. UHQ-BT could be found in Samsung LEVEL on pro.
I'll try to make a dump of Samsung U Flex or Samsung Gear IconX 2018, but 
Samsung LEVEL on pro are rather rare nowadays.



signature.asc
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Bluetooth aptX codec

2018-08-09 Thread ValdikSS 
On 06.07.2018 13:25, Pali Rohár wrote:
> I did some investigation and basically this is the list of all known
> codecs used in A2DP:
> 
> Mandatory:
> 0x00 - SBC
> 
> Optional:
> 0x01 - MPEG-1,2 (aka MP3)
> 0x02 - MPEG-2,4 (aka AAC)
> 0x04 - ATRAC
> 
> Vendor specific:
> 0xFF 0x004F 0x01 - aptX
> 0xFF 0x000A 0x01 - FastStream
> 0xFF 0x000A 0x02 - aptX Low Latency
> 0xFF 0x00D7 0x24 - aptX HD
> 0xFF 0x012D 0xAA - LDAC
> 
> And also I found some references that some sort of raw 16bit PCM samples
> via codec id 0x05 are used... But I have never seen such product.
> 

Could it be Samsung UHQ-BT?
https://www.samsung.com/uk/mobile-accessories/level-on-pro-wireless-headset-pn920/EO-PN920CFEGWW/

There are also:
0xFF 0x0075 0x0102 — Samsung HD (found on Samsung LEVEL Link)
Value hex dump: 7a

0xFF 0x000A 0x0103 — Unknown codec found on Bose QuietComfort QC35 II
Value hex dump: 07 06 00 00 ff ff 02 35

0xFF 0x000A 0x0104 — Unknown codec found on Bose QuietComfort QC35 II
Value hex dump: 07 08 00 02 c0 ff 8c 84 e2 00


Samsung LEVEL on/on pro also have support for what Samsung call "Scalable 
Codec".
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module

2018-08-05 Thread ValdikSS 
On 30.07.2018 10:30, Pali Rohár wrote:
> On Monday 30 July 2018 10:24:10 ValdikSS wrote:
>>> ACL Data RX: Handle 256 flags 0x02 dlen 20   #109 [hci0] 
>>> 5.421906
>>   Channel: 66 len 16 [PSM 25 mode 0] {chan 2}
>>   AVDTP: Get Capabilities (0x02) Response Accept (0x02) type 0x00 label 
>> 0 nosp 0
>>     Service Category: Media Transport (0x01)
>>     Service Category: Media Codec (0x07)
>>   Media Type: Audio (0x00)
>>   Media Codec: Non-A2DP (0xff)
>>     Vendor ID: Cambridge Silicon Radio (0x000a)
>>     Vendor Specific Codec ID: Unknown (0x0001)
>>     03 23    .#
>>
>>
>> Am I misunderstanding the latest item? Is it not a FastStream?
> 
> Yes, 0x000a/0x0001 is FastStream. "03" means that it supports both
> sink and source, "2" means that it supports microphone source sampling
> frequency 16kHz and "3" means that that is supports music sink sampling
> frequency 48kHz and 41.1kHz.
> 

How did you understand that? Do you have a documentation?
I'm writing Wireshark protocol dissector and want to include FastStream too.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support

2018-08-03 Thread ValdikSS 
On 03.08.2018 16:32, Pali Rohár wrote:
> On Friday 03 August 2018 16:22:05 ValdikSS wrote:
>> Doesn't work for me with Intel 7260 Bluetooth 4.0 and RealForce OverDrive D1.
>>
>> When I connect headphones and change Pulseaudio profile from "Off" to "High 
>> Fidelity SBC playback (a2dp sink)", everything works as expected with SBC.
>> Profile does not switch if I choose "High Fidelity aptX playback (a2dp 
>> sink)" when SBC profile is already active, log message:
>>
>> W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to 
>> a2dp_aptx_sink: Not connected
> Profile switching does not work -- bluez does not provide API for it.
>
> Codec is chosen by bluez and headset when doing handshake. Try to
> initialize A2DP connection from computer, not from headset. Then bluez
> should choose aptX codec in case your headset supports it.

Works now:
  AVDTP: Set Configuration (0x03) Command (0x00) type 0x00 label 10 nosp 0
    ACP SEID: 5
    INT SEID: 1
    Service Category: Media Transport (0x01)
    Service Category: Media Codec (0x07)
  Media Type: Audio (0x00)
  Media Codec: Non-A2DP (0xff)
    Vendor ID: APT Licensing Ltd. (0x004f)
    Vendor Specific Codec ID: aptX (0x0001)
  Frequency: 44100 (0x20)
  Channel Mode: Stereo (0x02)

>
>> When I try to switch to aptX profile from "off" profile, pulseaudio crashes:
>>
>> E: [pulseaudio] module-bluez5-device.c: Assertion '!u->thread' failed at 
>> modules/bluetooth/module-bluez5-device.c:1491, function start_thread(). 
>> Aborting.
> Try:
>
> $ pactl unload-module module-bluetooth-policy
>
> Seems that policy module needs to be fixed for new aptx profiles.

That works, thanks.

>
>> Thread 1 "pulseaudio" received signal SIGABRT, Aborted.
>> 0x744edfeb in raise () from /lib64/libc.so.6
>> (gdb) bt
>> #0  0x744edfeb in raise () from /lib64/libc.so.6
>> #1  0x744d85c1 in abort () from /lib64/libc.so.6
>> #2  0x7fff7f3dab45 in start_thread (u=u@entry=0x5593d640) at 
>> modules/bluetooth/module-bluez5-device.c:1491
>> #3  0x7fff7f3dd263 in set_profile_cb (c=, 
>> new_profile=0x559251a0) at modules/bluetooth/module-bluez5-device.c:1859
>> #4  0x77b5148e in pa_card_set_profile (c=c@entry=0x558e4c20, 
>> profile=profile@entry=0x559251a0, save=save@entry=true) at 
>> pulsecore/card.c:318
>> #5  0x7fffe0a0362d in command_set_card_profile (pd=, 
>> command=, tag=127, t=, userdata=> out>) at pulsecore/protocol-native.c:4728
>> #6  0x76d83813 in pa_pdispatch_run (pd=0x55a2e4b0, 
>> packet=packet@entry=0x558a3020, 
>> ancil_data=ancil_data@entry=0x55975bf8, 
>> userdata=userdata@entry=0x558bebf0) at pulsecore/pdispatch.c:346
>> #7  0x7fffe0a0bee9 in pstream_packet_callback (p=0x55975960, 
>> packet=0x558a3020, ancil_data=0x55975bf8, userdata=0x558bebf0) 
>> at pulsecore/protocol-native.c:4951
>> #8  0x76d8629d in do_read (p=p@entry=0x55975960, 
>> re=re@entry=0x55975b28) at pulsecore/pstream.c:1012
>> #9  0x76d890eb in do_pstream_read_write (p=0x55975960) at 
>> pulsecore/pstream.c:248
>> #10 0x76d8949d in srb_callback (srb=0x558b0660, 
>> userdata=0x55975960) at pulsecore/pstream.c:287
>> #11 0x76d89d2a in srbchannel_rwloop (sr=0x558b0660) at 
>> pulsecore/srbchannel.c:190
>> #12 0x778fc8a8 in dispatch_pollfds (m=0x5576f120) at 
>> pulse/mainloop.c:140
>> #13 pa_mainloop_dispatch (m=m@entry=0x5576f120) at pulse/mainloop.c:898
>> #14 0x778fcb80 in pa_mainloop_iterate (m=0x5576f120, 
>> block=, retval=0x7fffdc18) at pulse/mainloop.c:929
>> #15 0x778fcc20 in pa_mainloop_run (m=0x5576f120, 
>> retval=0x7fffdc18) at pulse/mainloop.c:945
>> #16 0xb0c9 in main (argc=, argv=) 
>> at daemon/main.c:1144
>>
>>
>> I haven't installed any patches for bluez itself. Should I? If yes, which 
>> exactly?
> There are no bluez patches.
>
>> I moved libopenaptx to autotools and made Fedora .spec file for openaptx, 
>> are you interested in autotools support for libopenaptx, should I create a 
>> pull request to your repository?
> Nope, I'm not interested to use autohell, simple Makefile for simple
> library is enough :-) Basically I see no reason for conversion to tool
> which then just generate Makefile back.

I don't like autotools either, but it make packaging much easier since all 
distros support autotools packaging almost a

Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support

2018-08-03 Thread ValdikSS 
I applied the patch to stable Pulseaudio 12.2. The patch successfully applies 
with some fuzzing. Should it be compatible with 12.2 or should I check it with 
master?


On 03.08.2018 16:22, ValdikSS wrote:
> Doesn't work for me with Intel 7260 Bluetooth 4.0 and RealForce OverDrive D1.
>
> When I connect headphones and change Pulseaudio profile from "Off" to "High 
> Fidelity SBC playback (a2dp sink)", everything works as expected with SBC.
> Profile does not switch if I choose "High Fidelity aptX playback (a2dp sink)" 
> when SBC profile is already active, log message:
>
> W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to 
> a2dp_aptx_sink: Not connected
>
> When I try to switch to aptX profile from "off" profile, pulseaudio crashes:
>
> E: [pulseaudio] module-bluez5-device.c: Assertion '!u->thread' failed at 
> modules/bluetooth/module-bluez5-device.c:1491, function start_thread(). 
> Aborting.
>
> Thread 1 "pulseaudio" received signal SIGABRT, Aborted.
> 0x744edfeb in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x744edfeb in raise () from /lib64/libc.so.6
> #1  0x744d85c1 in abort () from /lib64/libc.so.6
> #2  0x7fff7f3dab45 in start_thread (u=u@entry=0x5593d640) at 
> modules/bluetooth/module-bluez5-device.c:1491
> #3  0x7fff7f3dd263 in set_profile_cb (c=, 
> new_profile=0x559251a0) at modules/bluetooth/module-bluez5-device.c:1859
> #4  0x77b5148e in pa_card_set_profile (c=c@entry=0x558e4c20, 
> profile=profile@entry=0x559251a0, save=save@entry=true) at 
> pulsecore/card.c:318
> #5  0x7fffe0a0362d in command_set_card_profile (pd=, 
> command=, tag=127, t=, userdata= out>) at pulsecore/protocol-native.c:4728
> #6  0x76d83813 in pa_pdispatch_run (pd=0x55a2e4b0, 
> packet=packet@entry=0x558a3020, 
> ancil_data=ancil_data@entry=0x55975bf8, 
> userdata=userdata@entry=0x558bebf0) at pulsecore/pdispatch.c:346
> #7  0x7fffe0a0bee9 in pstream_packet_callback (p=0x55975960, 
> packet=0x558a3020, ancil_data=0x55975bf8, userdata=0x558bebf0) at 
> pulsecore/protocol-native.c:4951
> #8  0x76d8629d in do_read (p=p@entry=0x55975960, 
> re=re@entry=0x55975b28) at pulsecore/pstream.c:1012
> #9  0x76d890eb in do_pstream_read_write (p=0x55975960) at 
> pulsecore/pstream.c:248
> #10 0x76d8949d in srb_callback (srb=0x558b0660, 
> userdata=0x55975960) at pulsecore/pstream.c:287
> #11 0x76d89d2a in srbchannel_rwloop (sr=0x558b0660) at 
> pulsecore/srbchannel.c:190
> #12 0x778fc8a8 in dispatch_pollfds (m=0x5576f120) at 
> pulse/mainloop.c:140
> #13 pa_mainloop_dispatch (m=m@entry=0x5576f120) at pulse/mainloop.c:898
> #14 0x778fcb80 in pa_mainloop_iterate (m=0x5576f120, 
> block=, retval=0x7fffdc18) at pulse/mainloop.c:929
> #15 0x778fcc20 in pa_mainloop_run (m=0x5576f120, 
> retval=0x7fffdc18) at pulse/mainloop.c:945
> #16 0xb0c9 in main (argc=, argv=) 
> at daemon/main.c:1144
>
>
> I haven't installed any patches for bluez itself. Should I? If yes, which 
> exactly?
> I moved libopenaptx to autotools and made Fedora .spec file for openaptx, are 
> you interested in autotools support for libopenaptx, should I create a pull 
> request to your repository?
>
>
> On 28.07.2018 18:34, Pali Rohár wrote:
>> This patch series moves A2DP codec code into new modules and add
>> support for Bluetooth A2DP aptX codec.
>>
>> Pali Rohár (2):
>>   Modular API for Bluetooth A2DP codec
>>   Bluetooth A2DP aptX codec support
>>
>>  configure.ac |  19 +
>>  src/Makefile.am  |  14 +-
>>  src/modules/bluetooth/a2dp-codecs.h  | 123 +-
>>  src/modules/bluetooth/bluez5-util.c  | 377 +++--
>>  src/modules/bluetooth/bluez5-util.h  |  12 +-
>>  src/modules/bluetooth/module-bluez5-device.c | 542 -
>>  src/modules/bluetooth/pa-a2dp-codec-aptx.c   | 297 ++
>>  src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579 
>> +++
>>  src/modules/bluetooth/pa-a2dp-codec.h|  41 ++
>>  9 files changed, 1393 insertions(+), 611 deletions(-)
>>  create mode 100644 src/modules/bluetooth/pa-a2dp-codec-aptx.c
>>  create mode 100644 src/modules/bluetooth/pa-a2dp-codec-sbc.c
>>  create mode 100644 src/modules/bluetooth/pa-a2dp-codec.h
>>

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support

2018-08-03 Thread ValdikSS 
Doesn't work for me with Intel 7260 Bluetooth 4.0 and RealForce OverDrive D1.

When I connect headphones and change Pulseaudio profile from "Off" to "High 
Fidelity SBC playback (a2dp sink)", everything works as expected with SBC.
Profile does not switch if I choose "High Fidelity aptX playback (a2dp sink)" 
when SBC profile is already active, log message:

W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to 
a2dp_aptx_sink: Not connected

When I try to switch to aptX profile from "off" profile, pulseaudio crashes:

E: [pulseaudio] module-bluez5-device.c: Assertion '!u->thread' failed at 
modules/bluetooth/module-bluez5-device.c:1491, function start_thread(). 
Aborting.

Thread 1 "pulseaudio" received signal SIGABRT, Aborted.
0x744edfeb in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x744edfeb in raise () from /lib64/libc.so.6
#1  0x744d85c1 in abort () from /lib64/libc.so.6
#2  0x7fff7f3dab45 in start_thread (u=u@entry=0x5593d640) at 
modules/bluetooth/module-bluez5-device.c:1491
#3  0x7fff7f3dd263 in set_profile_cb (c=, 
new_profile=0x559251a0) at modules/bluetooth/module-bluez5-device.c:1859
#4  0x77b5148e in pa_card_set_profile (c=c@entry=0x558e4c20, 
profile=profile@entry=0x559251a0, save=save@entry=true) at 
pulsecore/card.c:318
#5  0x7fffe0a0362d in command_set_card_profile (pd=, 
command=, tag=127, t=, userdata=) 
at pulsecore/protocol-native.c:4728
#6  0x76d83813 in pa_pdispatch_run (pd=0x55a2e4b0, 
packet=packet@entry=0x558a3020, ancil_data=ancil_data@entry=0x55975bf8, 
userdata=userdata@entry=0x558bebf0) at pulsecore/pdispatch.c:346
#7  0x7fffe0a0bee9 in pstream_packet_callback (p=0x55975960, 
packet=0x558a3020, ancil_data=0x55975bf8, userdata=0x558bebf0) at 
pulsecore/protocol-native.c:4951
#8  0x76d8629d in do_read (p=p@entry=0x55975960, 
re=re@entry=0x55975b28) at pulsecore/pstream.c:1012
#9  0x76d890eb in do_pstream_read_write (p=0x55975960) at 
pulsecore/pstream.c:248
#10 0x76d8949d in srb_callback (srb=0x558b0660, 
userdata=0x55975960) at pulsecore/pstream.c:287
#11 0x76d89d2a in srbchannel_rwloop (sr=0x558b0660) at 
pulsecore/srbchannel.c:190
#12 0x778fc8a8 in dispatch_pollfds (m=0x5576f120) at 
pulse/mainloop.c:140
#13 pa_mainloop_dispatch (m=m@entry=0x5576f120) at pulse/mainloop.c:898
#14 0x778fcb80 in pa_mainloop_iterate (m=0x5576f120, 
block=, retval=0x7fffdc18) at pulse/mainloop.c:929
#15 0x778fcc20 in pa_mainloop_run (m=0x5576f120, 
retval=0x7fffdc18) at pulse/mainloop.c:945
#16 0xb0c9 in main (argc=, argv=) at 
daemon/main.c:1144


I haven't installed any patches for bluez itself. Should I? If yes, which 
exactly?
I moved libopenaptx to autotools and made Fedora .spec file for openaptx, are 
you interested in autotools support for libopenaptx, should I create a pull 
request to your repository?


On 28.07.2018 18:34, Pali Rohár wrote:
> This patch series moves A2DP codec code into new modules and add
> support for Bluetooth A2DP aptX codec.
> 
> Pali Rohár (2):
>   Modular API for Bluetooth A2DP codec
>   Bluetooth A2DP aptX codec support
> 
>  configure.ac |  19 +
>  src/Makefile.am  |  14 +-
>  src/modules/bluetooth/a2dp-codecs.h  | 123 +-
>  src/modules/bluetooth/bluez5-util.c  | 377 +++--
>  src/modules/bluetooth/bluez5-util.h  |  12 +-
>  src/modules/bluetooth/module-bluez5-device.c | 542 -
>  src/modules/bluetooth/pa-a2dp-codec-aptx.c   | 297 ++
>  src/modules/bluetooth/pa-a2dp-codec-sbc.c| 579 
> +++
>  src/modules/bluetooth/pa-a2dp-codec.h|  41 ++
>  9 files changed, 1393 insertions(+), 611 deletions(-)
>  create mode 100644 src/modules/bluetooth/pa-a2dp-codec-aptx.c
>  create mode 100644 src/modules/bluetooth/pa-a2dp-codec-sbc.c
>  create mode 100644 src/modules/bluetooth/pa-a2dp-codec.h
> 

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Extra A2DP codecs support in bluetooth module

2018-07-30 Thread ValdikSS 
On 30.07.2018 10:17, Pali Rohár wrote:
> On Monday 30 July 2018 06:30:14 valdikss wrote:
>> On 22.07.2018 14:37, Pali Rohár wrote:
>>
>>> Information which I have about FastStream: It is just SBC codec with
>>> following parameters: frequency rate 44.1 kHz or 48.0 kHz, Blocks 16,
>>> Sub-bands 8, Joint Stereo, Loudness and Bitpool = 29. So data rate = 212
>>> kbps, packet size = 72*3+4 = 220 = DM5 and that DSP decoders round 71
>>> bytes frames to 72 bytes. So I'm not sure how "low latency" it is.
>>> Normal SBC codec allows you to specify all those parameters. But
>>> FastStream has one additional feature: it supports backchannel for
>>> voice, so you do not have to switch between HFP/HSP and A2DP once you
>>> have incoming voice call. You can always use just A2DP with FastStream.
>>>
>>> Pulseaudio for SBC codec choose those parameters: Joint Stereo, Block
>>> 16, Sub-bands 8, Loudness. Frequency and bitpool depends on pulseaudio
>>> source. If bluetooth device does not support those parameters,
>>> pulseaudio lower values. So for me it looks like that FastStream matches
>>> default SBC pulseaudio configuration.
>>>
>>> Backchannel in FastStream for microphone voice again uses SBC codec with
>>> parameters: 16 KHz frequency rate, Blocks 16, Sub-bands 8, Loudness,
>>> Bitpool 32. So data rate = 72 kbps, packet size = 3*72 + 4 = 220 <= DM5.
>>> Which should be much better then CVSD codec at 8 kHz used in HFP/HSP.
>>> But is there really difference for voice data which comes from
>>> (probably poor) microphone integrated in headsets?
>>>
>>>> handful of Creative headsets that don't seem to support any other codecs. I
>>>> would put it between SBC and AAC. If someone prefers SBC over it, they know
>>>> enough about Bluetooth operation to qualify as a power user capable of 
>>>> using
>>>> the config file to disable FastStream.
>>> Based on above details I would say it must be similar (or same?) as SBC
>>> for streaming. But who knows how is receiver implemented? I would not be
>>> surprised if some bluetooth headset have degraded SBC A2DP codec just
>>> for marketing purposed to show that other vendor codec is "better".
>>>
>>> As I said, I need to play with FastStream and see what my headset would
>>> do with it. For me interesting part is that backchannel support to avoid
>>> all problems with switching between A2DP and HSP/HFP profiles (to
>>> activate HSP/HFP only in case I have incoming call and after hangup
>>> switch back to AD2P...).
>> It would be great if FastStream support could be implemented. I have a 
>> headset with CSR (now Qualcomm) chip which supports SBC, AptX, AAC and 
>> FastStream. The headset is rather unknown and not expensive (but 
>> surprisingly good), so I assume FastStream support is not that rare.
>> If high-quality duplex audio is possible with Bluetooth, that would be very 
>> handy for conferences.
> Now I have working sink support (sending audio from host to headset) for
> FastStream codec in pulseaudio. Voice backchannel support would be
> rather challenge as I do not know if bluez provides API for such thing.
>
> Anyway good news is that at least my Creative headset automatically
> starts sending voice data after FastStream codec is negotiated and via
> "btmon" I was able to capture voice data and via "sbcdec" decode them to
> check that it is correct and usable.
>
> May I ask which headset it is? I was told that FastStream is supported
> only by Creative headsets.
>
It's RealForce OverDrive D1.
Here's what could be seen in btmon upon connection:

> ACL Data RX: Handle 256 flags 0x02 dlen 20   #100 [hci0] 5.331899
  Channel: 66 len 16 [PSM 25 mode 0] {chan 2}
  AVDTP: Get Capabilities (0x02) Response Accept (0x02) type 0x00 label 13 
nosp 0
    Service Category: Media Transport (0x01)
    Service Category: Media Codec (0x07)
  Media Type: Audio (0x00)
  Media Codec: SBC (0x00)
    Frequency: 0xf0
  16000
  32000
  44100
  48000
    Channel Mode: 0x0f
  Mono
  Dual Channel
  Stereo
  Joint Stereo
    Block Length: 0xf0
  4
  8
  12
  16
    Subbands: 0x0c
  4
  8
    Allocation Method: 0x03
  SNR
  Loudness
    Minimum Bitpool: 2
    Maximum Bitpool: 53
    Service Category: Content Protection (0x04)
 

[pulseaudio-discuss] Extra A2DP codecs support in bluetooth module

2018-07-29 Thread ValdikSS 
On 22.07.2018 14:37, Pali Rohár wrote:

> 
> Information which I have about FastStream: It is just SBC codec with
> following parameters: frequency rate 44.1 kHz or 48.0 kHz, Blocks 16,
> Sub-bands 8, Joint Stereo, Loudness and Bitpool = 29. So data rate = 212
> kbps, packet size = 72*3+4 = 220 = DM5 and that DSP decoders round 71
> bytes frames to 72 bytes. So I'm not sure how "low latency" it is.
> Normal SBC codec allows you to specify all those parameters. But
> FastStream has one additional feature: it supports backchannel for
> voice, so you do not have to switch between HFP/HSP and A2DP once you
> have incoming voice call. You can always use just A2DP with FastStream.
> 
> Pulseaudio for SBC codec choose those parameters: Joint Stereo, Block
> 16, Sub-bands 8, Loudness. Frequency and bitpool depends on pulseaudio
> source. If bluetooth device does not support those parameters,
> pulseaudio lower values. So for me it looks like that FastStream matches
> default SBC pulseaudio configuration.
> 
> Backchannel in FastStream for microphone voice again uses SBC codec with
> parameters: 16 KHz frequency rate, Blocks 16, Sub-bands 8, Loudness,
> Bitpool 32. So data rate = 72 kbps, packet size = 3*72 + 4 = 220 <= DM5.
> Which should be much better then CVSD codec at 8 kHz used in HFP/HSP.
> But is there really difference for voice data which comes from
> (probably poor) microphone integrated in headsets?
> 
>> handful of Creative headsets that don't seem to support any other codecs. I
>> would put it between SBC and AAC. If someone prefers SBC over it, they know
>> enough about Bluetooth operation to qualify as a power user capable of using
>> the config file to disable FastStream.
> 
> Based on above details I would say it must be similar (or same?) as SBC
> for streaming. But who knows how is receiver implemented? I would not be
> surprised if some bluetooth headset have degraded SBC A2DP codec just
> for marketing purposed to show that other vendor codec is "better".
> 
> As I said, I need to play with FastStream and see what my headset would
> do with it. For me interesting part is that backchannel support to avoid
> all problems with switching between A2DP and HSP/HFP profiles (to
> activate HSP/HFP only in case I have incoming call and after hangup
> switch back to AD2P...).

It would be great if FastStream support could be implemented. I have a headset 
with CSR (now Qualcomm) chip which supports SBC, AptX, AAC and FastStream. The 
headset is rather unknown and not expensive (but surprisingly good), so I 
assume FastStream support is not that rare.
If high-quality duplex audio is possible with Bluetooth, that would be very 
handy for conferences.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss