Re: [pulseaudio-discuss] Bluetooth aptX codec
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] Bluetooth aptX codec
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. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
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] Bluetooth aptX codec
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
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
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
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
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. -- 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] Bluetooth aptX codec
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] Bluetooth aptX codec
On Mon, 30 Jul 2018, at 5:14 PM, Pali Rohár wrote: > On Monday 30 July 2018 17:04:55 Arun Raghavan wrote: > > On Mon, 30 Jul 2018, at 12:42 PM, Pali Rohár wrote: > > [...] > > > I looked and there is absolutely nothing about A2DP codec parameter > > > selections. So really does not help. > > > > Okay, I feel like this conversation has been us talking past each other, so > > let me try to summarise what I'm saying more clearly: > > > > 1. The BlueZ modules will, possibly based on modargs, expose a set of > > supported codecs. Yes, that includes codec parameters, the knowledge of > > which the endpoint needs to have. If you have ideas for making this > > modular, I'm open to suggestions. > > > > 2. For the specific process of RTP payload/depayload and selection of a > > codec implementation for encode/decode, I believe we should construct and > > use a GStreamer bin, so as to not have to offload that choice to the system > > integrator rather than having to make that choice in PulseAudio. I feel > > strongly enough about not linking to specific codec implementations that > > any approach that does that is a NACK from me. I realise we already have > > this for SBC, but I do not want to add any more. > > Look at my last (v2) patch series for aptX. Here I created some > modularisation of codecs and addition of another codecs would be easier. Will do. Note that I'm not just talk about modularity w.r.t. codecs, but also codec implementations. > I have not used Gstreamer as it does not help me -- it does not provide > module for A2DP codec negotiation (it is not static list of parameters > as you imagine, but negotiation function) nor it does not support aptX > codec. That's still not problematic from a GStreamer perspective. It is possible to set up parameters via caps if needed after the negotiation stage. And wrapping your library in a GStreamer plugin would be a trivial effort. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Monday 30 July 2018 17:04:55 Arun Raghavan wrote: > On Mon, 30 Jul 2018, at 12:42 PM, Pali Rohár wrote: > [...] > > I looked and there is absolutely nothing about A2DP codec parameter > > selections. So really does not help. > > Okay, I feel like this conversation has been us talking past each other, so > let me try to summarise what I'm saying more clearly: > > 1. The BlueZ modules will, possibly based on modargs, expose a set of > supported codecs. Yes, that includes codec parameters, the knowledge of which > the endpoint needs to have. If you have ideas for making this modular, I'm > open to suggestions. > > 2. For the specific process of RTP payload/depayload and selection of a codec > implementation for encode/decode, I believe we should construct and use a > GStreamer bin, so as to not have to offload that choice to the system > integrator rather than having to make that choice in PulseAudio. I feel > strongly enough about not linking to specific codec implementations that any > approach that does that is a NACK from me. I realise we already have this for > SBC, but I do not want to add any more. Look at my last (v2) patch series for aptX. Here I created some modularisation of codecs and addition of another codecs would be easier. I have not used Gstreamer as it does not help me -- it does not provide module for A2DP codec negotiation (it is not static list of parameters as you imagine, but negotiation function) nor it does not support aptX codec. -- 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] Bluetooth aptX codec
On Mon, 30 Jul 2018, at 12:42 PM, Pali Rohár wrote: [...] > I looked and there is absolutely nothing about A2DP codec parameter > selections. So really does not help. Okay, I feel like this conversation has been us talking past each other, so let me try to summarise what I'm saying more clearly: 1. The BlueZ modules will, possibly based on modargs, expose a set of supported codecs. Yes, that includes codec parameters, the knowledge of which the endpoint needs to have. If you have ideas for making this modular, I'm open to suggestions. 2. For the specific process of RTP payload/depayload and selection of a codec implementation for encode/decode, I believe we should construct and use a GStreamer bin, so as to not have to offload that choice to the system integrator rather than having to make that choice in PulseAudio. I feel strongly enough about not linking to specific codec implementations that any approach that does that is a NACK from me. I realise we already have this for SBC, but I do not want to add any more. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Monday 30 July 2018 08:15:22 Arun Raghavan wrote: > On Sat, 28 Jul 2018, at 9:01 PM, Pali Rohár wrote: > > On Monday 23 July 2018 18:42:52 Arun Raghavan wrote: > > > On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote: > > > > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote: > > > > > сб, 7 июл. 2018 г. в 19:08, Pali Rohár : > > > > > > > > > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > > > > > > Pre-installed doesn't mean much tbh. It is easy enough for > > > > > > > packages to depend on it. > > > > > > > > > > > > Can pulseaudio build process enforce it? > > > > > > Does not need to, that can be taken care of at packaging time, and > > > potentially at module load. > > > > Ok, I would ask differently: Can pulseaudio at packaging time enforce it? > > That depends on the packaging system, but broadly the answer is yes. Ack. > > > > > 2. GStreamer can, in theory, wrap the needed libraries, and does > > > > > support third-party plugins, but does not properly encapsulate the > > > > > "give me packets ready to send via bluez" part. > > > > > > > > And until this is supported by external library (ffmpeg, gstreamer, > > > > whatever), pulseaudio needs to implement it itself. > > > > > > > > And encapsulating encoded data for bluez is not enough. It is needed > > > > also to negotiate codec selection with bluez and codec parameters (which > > > > are codec specific). > > > > > > GStreamer has RTP payloading for sbc, mp3 and aac, so that can easily be > > > used (and again, less codec-specific stuff that needs to be in PA). > > > > But it does not solve above problem when it is needed to do A2DP codec > > selection and negotiation. > > I don't get what you mean here. That above RTP payloading does not solve obvious problem for A2DP codec selection and negotiation of A2DP codec parameters. > > > > In previous email I wrote about idea to move that codec stuff into bluez > > > > itself as bluez code already handles it for android. > > > > > > > > > > > > > > > > > > To have working bluetooth support in pulseadio, pulseaudio > > > > > > > > needs to use > > > > > > > > external library for encoding which *always* provides support > > > > > > > > for SBC. > > > > > > > > And not only if user manually installs some special plugin for > > > > > > > > 3rd party > > > > > > > > library. (And not only SBC, but also those other aptX, MPEG1/2, > > > > > > > > AAC and > > > > > > > > LDAC codecs) > > > > > > > > > > > > > > So I continue to disagree. Using a generic framework and letting > > > > > > > other parts of the system select the codec implementation is what > > > > > > > makes sense for the widest set of use-cases (this also allows > > > > > > > products to ship their own implementations of a codec without > > > > > > > changing the PulseAudio code). > > > > > > > > > > > > Still this is not enough for bluetooth codec. For specific codec you > > > > > > need to create bluez dbus endpoint with codec specific parameters. > > > > > > Plus > > > > > > implement select and set methods to decide on codec parameters > > > > > > between > > > > > > pulseaudio and bluetooth headset. And finally to send encoded data > > > > > > you > > > > > > need to know how to send them. To which endpoint, how header looks > > > > > > like > > > > > > etc... Some codecs needs to wrap data into RTP (e.g. SBC), some > > > > > > must not > > > > > > have RTP (e.g. aptX). And after that comes data from codec encoder > > > > > > function. > > > > > > > > > > > > So is there any library which all above support? I have not find > > > > > > anything. Nor ffmpeg nor gstreamer. > > > > > > > > > > > > Which means that pulseaudio cannot delegate codec selection, codec > > > > > > initialization and codec encoding to some external library (yet). > > > > > > At least for SBC and presumably AAC, this is all possible with GStreamer > > > > No, it is not possible -- or at least I have not found any way how. I > > spend more time with it and Gstreamer does not support it. If you still > > think that it is possible, post a gstreamer code or link how to do that. > > Look at the rtpsbcpay/rtpsbcdepay elements, for example. I looked and there is absolutely nothing about A2DP codec parameter selections. So really does not help. -- 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] Bluetooth aptX codec
On Sat, 28 Jul 2018, at 9:01 PM, Pali Rohár wrote: > On Monday 23 July 2018 18:42:52 Arun Raghavan wrote: > > On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote: > > > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote: > > > > сб, 7 июл. 2018 г. в 19:08, Pali Rohár : > > > > > > > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages > > > > > > to depend on it. > > > > > > > > > > Can pulseaudio build process enforce it? > > > > Does not need to, that can be taken care of at packaging time, and > > potentially at module load. > > Ok, I would ask differently: Can pulseaudio at packaging time enforce it? That depends on the packaging system, but broadly the answer is yes. > > > > 2. GStreamer can, in theory, wrap the needed libraries, and does > > > > support third-party plugins, but does not properly encapsulate the > > > > "give me packets ready to send via bluez" part. > > > > > > And until this is supported by external library (ffmpeg, gstreamer, > > > whatever), pulseaudio needs to implement it itself. > > > > > > And encapsulating encoded data for bluez is not enough. It is needed > > > also to negotiate codec selection with bluez and codec parameters (which > > > are codec specific). > > > > GStreamer has RTP payloading for sbc, mp3 and aac, so that can easily be > > used (and again, less codec-specific stuff that needs to be in PA). > > But it does not solve above problem when it is needed to do A2DP codec > selection and negotiation. I don't get what you mean here. > > > In previous email I wrote about idea to move that codec stuff into bluez > > > itself as bluez code already handles it for android. > > > > > > > > > > > > > > > To have working bluetooth support in pulseadio, pulseaudio needs > > > > > > > to use > > > > > > > external library for encoding which *always* provides support for > > > > > > > SBC. > > > > > > > And not only if user manually installs some special plugin for > > > > > > > 3rd party > > > > > > > library. (And not only SBC, but also those other aptX, MPEG1/2, > > > > > > > AAC and > > > > > > > LDAC codecs) > > > > > > > > > > > > So I continue to disagree. Using a generic framework and letting > > > > > > other parts of the system select the codec implementation is what > > > > > > makes sense for the widest set of use-cases (this also allows > > > > > > products to ship their own implementations of a codec without > > > > > > changing the PulseAudio code). > > > > > > > > > > Still this is not enough for bluetooth codec. For specific codec you > > > > > need to create bluez dbus endpoint with codec specific parameters. > > > > > Plus > > > > > implement select and set methods to decide on codec parameters between > > > > > pulseaudio and bluetooth headset. And finally to send encoded data you > > > > > need to know how to send them. To which endpoint, how header looks > > > > > like > > > > > etc... Some codecs needs to wrap data into RTP (e.g. SBC), some must > > > > > not > > > > > have RTP (e.g. aptX). And after that comes data from codec encoder > > > > > function. > > > > > > > > > > So is there any library which all above support? I have not find > > > > > anything. Nor ffmpeg nor gstreamer. > > > > > > > > > > Which means that pulseaudio cannot delegate codec selection, codec > > > > > initialization and codec encoding to some external library (yet). > > > > At least for SBC and presumably AAC, this is all possible with GStreamer > > No, it is not possible -- or at least I have not found any way how. I > spend more time with it and Gstreamer does not support it. If you still > think that it is possible, post a gstreamer code or link how to do that. Look at the rtpsbcpay/rtpsbcdepay elements, for example. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Sunday 22 July 2018 10:45:57 Pali Rohár wrote: > On Friday 20 July 2018 14:30:56 Luiz Augusto von Dentz wrote: > > Hi Pali, > > > > On Wed, Jul 11, 2018 at 11:07 AM, Pali Rohár wrote: > > > On Monday 09 July 2018 17:56:16 Pali Rohár wrote: > > >> On Monday 09 July 2018 18:48:10 Luiz Augusto von Dentz wrote: > > >> > > 2) How should codec switching from pulseaudio API and > > >> > > pactl/pavucontrol > > >> > > looks like? > > >> > > > >> > Usually we don't force reconfiguration but perhaps we should, note > > >> > though that we may end up with audio glitches since we have to > > >> > disconnect A2DP stream to be able to reconfigure it with another > > >> > codec. > > >> > > >> Glitches are already there if you switch from A2DP profile to HSP in > > >> pavucontrol. So I do not see any problem if glitches happen also when > > >> switching between A2DP (SBC) and A2DP (aptX). > > >> > > >> > We would probably have to expose each endpoint so you could > > >> > peek and choose what the codec to use. > > >> > > >> Yes. I think this is required when pulseaudio is going to support more > > >> then one codec. > > > > > > So when this will happen? As for now this is blocker for proper support > > > of multiple codecs in pulseaudio. > > > > > > We need some dbus method call which will tell bluez which endpoint > > > (registered by pulseaudio) should be used now for particular bluetooth > > > A2DP device. > > > > I can give you some pointers on how to expose the endpoints with > > MediaEndpoint interface. > > Ok. Until that, I sent a new version of aptX patch which let codec selection to bluez. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Monday 23 July 2018 18:42:52 Arun Raghavan wrote: > On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote: > > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote: > > > сб, 7 июл. 2018 г. в 19:08, Pali Rohár : > > > > > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages > > > > > to depend on it. > > > > > > > > Can pulseaudio build process enforce it? > > Does not need to, that can be taken care of at packaging time, and > potentially at module load. Ok, I would ask differently: Can pulseaudio at packaging time enforce it? > > > 2. GStreamer can, in theory, wrap the needed libraries, and does > > > support third-party plugins, but does not properly encapsulate the > > > "give me packets ready to send via bluez" part. > > > > And until this is supported by external library (ffmpeg, gstreamer, > > whatever), pulseaudio needs to implement it itself. > > > > And encapsulating encoded data for bluez is not enough. It is needed > > also to negotiate codec selection with bluez and codec parameters (which > > are codec specific). > > GStreamer has RTP payloading for sbc, mp3 and aac, so that can easily be used > (and again, less codec-specific stuff that needs to be in PA). But it does not solve above problem when it is needed to do A2DP codec selection and negotiation. > > In previous email I wrote about idea to move that codec stuff into bluez > > itself as bluez code already handles it for android. > > > > > > > > > > > > To have working bluetooth support in pulseadio, pulseaudio needs to > > > > > > use > > > > > > external library for encoding which *always* provides support for > > > > > > SBC. > > > > > > And not only if user manually installs some special plugin for 3rd > > > > > > party > > > > > > library. (And not only SBC, but also those other aptX, MPEG1/2, AAC > > > > > > and > > > > > > LDAC codecs) > > > > > > > > > > So I continue to disagree. Using a generic framework and letting > > > > > other parts of the system select the codec implementation is what > > > > > makes sense for the widest set of use-cases (this also allows > > > > > products to ship their own implementations of a codec without > > > > > changing the PulseAudio code). > > > > > > > > Still this is not enough for bluetooth codec. For specific codec you > > > > need to create bluez dbus endpoint with codec specific parameters. Plus > > > > implement select and set methods to decide on codec parameters between > > > > pulseaudio and bluetooth headset. And finally to send encoded data you > > > > need to know how to send them. To which endpoint, how header looks like > > > > etc... Some codecs needs to wrap data into RTP (e.g. SBC), some must not > > > > have RTP (e.g. aptX). And after that comes data from codec encoder > > > > function. > > > > > > > > So is there any library which all above support? I have not find > > > > anything. Nor ffmpeg nor gstreamer. > > > > > > > > Which means that pulseaudio cannot delegate codec selection, codec > > > > initialization and codec encoding to some external library (yet). > > At least for SBC and presumably AAC, this is all possible with GStreamer No, it is not possible -- or at least I have not found any way how. I spend more time with it and Gstreamer does not support it. If you still think that it is possible, post a gstreamer code or link how to do that. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote: > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote: > > сб, 7 июл. 2018 г. в 19:08, Pali Rohár : > > > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > > > > This is a good idea to let external service to do codec-specific > > > > > functions... I agree that it simplify pulseaudio code and other things > > > > > (like proving new codec by external library -- if properly > > > > > implemented), > > > > > but in bluetooth context we should look at questions: > > > > > > > > > > 1) Has gstreamer support for SBC codec? > > > > > > > > > > 2) Has gstreamer support for aptX codec? > > > > > > > > > > These are two major codecs supported by bluetooth headsets. > > > > > > > > > > Answer is: NO > > > > > (SBC is now provided in the "bad" set which is not pre-installed by > > > > > gstreamer) > > > > > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages to > > > > depend on it. > > > > > > Can pulseaudio build process enforce it? Does not need to, that can be taken care of at packaging time, and potentially at module load. > > > > > So gstreamer in current state is not very useful for pulseaudio. > > > > > > > > Writing a plugin around an existing decoder is pretty trivial. As is > > > > exposing libav/ffmpeg codecs. > > > > > > > > > Important are also MPEG1/2 (which are defined as optional by A2DP) > > > > > and also AAC and LDAC which Jan wrote. But gstreamer has again only > > > > > plugins in "bad" and "ugly" sets for them; nothing preinstalled by > > > > > default. > > > > > > > > Again, -bad doesn't mean much in the current day (historically it was a > > > > staging ground). -ugly is for codecs that are known to be > > > > patent-encumbered (and how that's made available is up to packagers). > > > > > > Still more distributions does not compile ffmpeg with all codecs due to > > > patents problems. > > > > > > So there is a high chance that we end up in situation that pulseaudio > > > would not be able to encode audio into codec X (even pulseaudio declare > > > that it support) and user would not be able to do nothing as his > > > distribution does not enabled codec X at compile time. It could be > > > really a legal problem or problem because packager forgot to enable it > > > or because he think that it could be a problem and rather disabled it. > > > > > > The only option to prevent such situation is compile time check. Like > > > now pulseaudio does not compile bluetooth support when sbc codec is not > > > available. And this check should be there even after moving to > > > ffmpeg/gstreamer/whatever. So is this check possible to write in > > > autoconf for that ffmpeg/gstreamer/whatever? > > > > I disagree here. Speaking here as an author of a patented codec (DTS) > > implementation that is well supported by PulseAudio ;) > > But this is something different. DTS is not mandatory and devices in > more cases can work without it (via PCM). But in bluetooth is SBC codec > mandatory and must be always supported. And there are no license > problems with SBC for A2DP bluetooth. This is a package problem, and can be addressed with either load-time arguments for what is supported, or by probing. [...] > > 1. It is unwise to use ffmpeg because it can be compiled improperly > > and is difficult to replace in this case. > > Yes, this is the main problem which I'm pointing. Also I do not know if > ffmpeg has support for (mandatory) SBC codec... > > Now you can either: 1) compile pulseaudio with bluetooth support and > bluetooth will work always (because it links to system sbc codec > library) or 2) compile pulseaudio without bluetooth support (and it > would not work). And for 1) dynamic linking ensure that needed codec > (sbc) is present/installed as primary dependency. > > > 2. GStreamer can, in theory, wrap the needed libraries, and does > > support third-party plugins, but does not properly encapsulate the > > "give me packets ready to send via bluez" part. > > And until this is supported by external library (ffmpeg, gstreamer, > whatever), pulseaudio needs to implement it itself. > > And encapsulating encoded data for bluez is not enough. It is needed > also to negotiate codec selection with bluez and codec parameters (which > are codec specific). GStreamer has RTP payloading for sbc, mp3 and aac, so that can easily be used (and again, less codec-specific stuff that needs to be in PA). > In previous email I wrote about idea to move that codec stuff into bluez > itself as bluez code already handles it for android. > > > > > > > > > To have working bluetooth support in pulseadio, pulseaudio needs to > > > > > use > > > > > external library for encoding which *always* provides support for SBC. > > > > > And not only if user manually installs some special plugin for 3rd > > > > > party > > > > > library. (And not only SBC, but also those other aptX, MPEG1/2, AAC > > > > > and > > > > > LDAC c
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Friday 20 July 2018 14:30:56 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Wed, Jul 11, 2018 at 11:07 AM, Pali Rohár wrote: > > On Monday 09 July 2018 17:56:16 Pali Rohár wrote: > >> On Monday 09 July 2018 18:48:10 Luiz Augusto von Dentz wrote: > >> > > 2) How should codec switching from pulseaudio API and pactl/pavucontrol > >> > > looks like? > >> > > >> > Usually we don't force reconfiguration but perhaps we should, note > >> > though that we may end up with audio glitches since we have to > >> > disconnect A2DP stream to be able to reconfigure it with another > >> > codec. > >> > >> Glitches are already there if you switch from A2DP profile to HSP in > >> pavucontrol. So I do not see any problem if glitches happen also when > >> switching between A2DP (SBC) and A2DP (aptX). > >> > >> > We would probably have to expose each endpoint so you could > >> > peek and choose what the codec to use. > >> > >> Yes. I think this is required when pulseaudio is going to support more > >> then one codec. > > > > So when this will happen? As for now this is blocker for proper support > > of multiple codecs in pulseaudio. > > > > We need some dbus method call which will tell bluez which endpoint > > (registered by pulseaudio) should be used now for particular bluetooth > > A2DP device. > > I can give you some pointers on how to expose the endpoints with > MediaEndpoint interface. Ok. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
Hi Pali, On Wed, Jul 11, 2018 at 11:07 AM, Pali Rohár wrote: > On Monday 09 July 2018 17:56:16 Pali Rohár wrote: >> On Monday 09 July 2018 18:48:10 Luiz Augusto von Dentz wrote: >> > > 2) How should codec switching from pulseaudio API and pactl/pavucontrol >> > > looks like? >> > >> > Usually we don't force reconfiguration but perhaps we should, note >> > though that we may end up with audio glitches since we have to >> > disconnect A2DP stream to be able to reconfigure it with another >> > codec. >> >> Glitches are already there if you switch from A2DP profile to HSP in >> pavucontrol. So I do not see any problem if glitches happen also when >> switching between A2DP (SBC) and A2DP (aptX). >> >> > We would probably have to expose each endpoint so you could >> > peek and choose what the codec to use. >> >> Yes. I think this is required when pulseaudio is going to support more >> then one codec. > > So when this will happen? As for now this is blocker for proper support > of multiple codecs in pulseaudio. > > We need some dbus method call which will tell bluez which endpoint > (registered by pulseaudio) should be used now for particular bluetooth > A2DP device. I can give you some pointers on how to expose the endpoints with MediaEndpoint interface. -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Monday 09 July 2018 17:56:16 Pali Rohár wrote: > On Monday 09 July 2018 18:48:10 Luiz Augusto von Dentz wrote: > > > 2) How should codec switching from pulseaudio API and pactl/pavucontrol > > > looks like? > > > > Usually we don't force reconfiguration but perhaps we should, note > > though that we may end up with audio glitches since we have to > > disconnect A2DP stream to be able to reconfigure it with another > > codec. > > Glitches are already there if you switch from A2DP profile to HSP in > pavucontrol. So I do not see any problem if glitches happen also when > switching between A2DP (SBC) and A2DP (aptX). > > > We would probably have to expose each endpoint so you could > > peek and choose what the codec to use. > > Yes. I think this is required when pulseaudio is going to support more > then one codec. So when this will happen? As for now this is blocker for proper support of multiple codecs in pulseaudio. We need some dbus method call which will tell bluez which endpoint (registered by pulseaudio) should be used now for particular bluetooth A2DP device. -- 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] Bluetooth aptX codec
On Monday 09 July 2018 18:48:10 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Sun, Jul 8, 2018 at 11:47 PM, Pali Rohár wrote: > > On Sunday 08 July 2018 22:51:38 Luiz Augusto von Dentz wrote: > >> > In previous email I wrote about idea to move that codec stuff into bluez > >> > itself as bluez code already handles it for android. > >> > >> We are not going to do a pulseaudio module in BlueZ, if it is even > >> possible to have off the tree modules, in android we did that because > >> it is the only option we had and Im quite sure it probably needs > >> updating since code must have change since then... Any architecture > >> that would involve copying data over would be bad for latency, though > >> android does that, and Im pretty sure doing encoding/decoding on > >> daemon would be rejected as well. > > > > Ok. > > > > But why is there already code for encoding/decoding directly in bluez > > (even it is for android) and not in some separate library/project? > > > > Then both android and pulseaudio can benefit from it. As basically now > > pulseaudio needs to implement exactly same code and logic which is > > already in bluez project, which is doing that audio encoding. > > > >> The D-Bus interface already accounts to the parameter negotiation, > >> obviously frameworks such as ffmeg or gstreamer would not do it for > >> use but the module could take up the action to register the endpoint > >> and respond to the method calls when necessary. Anyway, lets start > >> with modularization of the endpoints/codecs, that way we can add > >> native codec support or gstreamer/ffmpeg and each platform decides > >> with what they want to go. > > > > Ok. Prior I start splitting codec related code, I need to know: > > > > 1) Cannot we reuse above bluez code for codec encoding which is already > > used for android? If it needs some refactoring (like stop doing data > > copying etc...). > > android does not use PulseAudio, what we have there is a plugin for > the android audio server. > > > 2) How should codec switching from pulseaudio API and pactl/pavucontrol > > looks like? > > Usually we don't force reconfiguration but perhaps we should, note > though that we may end up with audio glitches since we have to > disconnect A2DP stream to be able to reconfigure it with another > codec. Glitches are already there if you switch from A2DP profile to HSP in pavucontrol. So I do not see any problem if glitches happen also when switching between A2DP (SBC) and A2DP (aptX). > We would probably have to expose each endpoint so you could > peek and choose what the codec to use. Yes. I think this is required when pulseaudio is going to support more then one codec. > > 3) How to handle possible pass-through? E.g. I have already encoded > > music in aptX format (or MP3 or AAC) and want to send it directly > > without double decoding-encoding process. And how to handle MP3 input > > when device supports both aptX and MP3, but currently is activated aptX? > > Afaik that usually requires the application to know that underline > codec so PA needs to expose these details so it can avoid decoding and > send it. Switching depending on the content will not work well so > perhaps the only bet is if the device support multiplexing, which is > something we don't support in BlueZ, otherwise it is better to use > either aptX or SBC since those are simpler than going with AAC and MP3 > and possible encode any other audio. > > >> Btw, I guess you were on irc looking for how we prioritize the > >> matching of endpoints, this is done in the order of endpoint > >> registration, > > > > Yes, but I have not got any answer so I sent incomplete/wIP patch to > > this mailing list. > > > > -- > > Pali Rohár > > pali.ro...@gmail.com > > > > ___ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > > -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
Hi Pali, On Sun, Jul 8, 2018 at 11:47 PM, Pali Rohár wrote: > On Sunday 08 July 2018 22:51:38 Luiz Augusto von Dentz wrote: >> > In previous email I wrote about idea to move that codec stuff into bluez >> > itself as bluez code already handles it for android. >> >> We are not going to do a pulseaudio module in BlueZ, if it is even >> possible to have off the tree modules, in android we did that because >> it is the only option we had and Im quite sure it probably needs >> updating since code must have change since then... Any architecture >> that would involve copying data over would be bad for latency, though >> android does that, and Im pretty sure doing encoding/decoding on >> daemon would be rejected as well. > > Ok. > > But why is there already code for encoding/decoding directly in bluez > (even it is for android) and not in some separate library/project? > > Then both android and pulseaudio can benefit from it. As basically now > pulseaudio needs to implement exactly same code and logic which is > already in bluez project, which is doing that audio encoding. > >> The D-Bus interface already accounts to the parameter negotiation, >> obviously frameworks such as ffmeg or gstreamer would not do it for >> use but the module could take up the action to register the endpoint >> and respond to the method calls when necessary. Anyway, lets start >> with modularization of the endpoints/codecs, that way we can add >> native codec support or gstreamer/ffmpeg and each platform decides >> with what they want to go. > > Ok. Prior I start splitting codec related code, I need to know: > > 1) Cannot we reuse above bluez code for codec encoding which is already > used for android? If it needs some refactoring (like stop doing data > copying etc...). android does not use PulseAudio, what we have there is a plugin for the android audio server. > 2) How should codec switching from pulseaudio API and pactl/pavucontrol > looks like? Usually we don't force reconfiguration but perhaps we should, note though that we may end up with audio glitches since we have to disconnect A2DP stream to be able to reconfigure it with another codec. We would probably have to expose each endpoint so you could peek and choose what the codec to use. > 3) How to handle possible pass-through? E.g. I have already encoded > music in aptX format (or MP3 or AAC) and want to send it directly > without double decoding-encoding process. And how to handle MP3 input > when device supports both aptX and MP3, but currently is activated aptX? Afaik that usually requires the application to know that underline codec so PA needs to expose these details so it can avoid decoding and send it. Switching depending on the content will not work well so perhaps the only bet is if the device support multiplexing, which is something we don't support in BlueZ, otherwise it is better to use either aptX or SBC since those are simpler than going with AAC and MP3 and possible encode any other audio. >> Btw, I guess you were on irc looking for how we prioritize the >> matching of endpoints, this is done in the order of endpoint >> registration, > > Yes, but I have not got any answer so I sent incomplete/wIP patch to > this mailing list. > > -- > Pali Rohár > pali.ro...@gmail.com > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Sunday 08 July 2018 22:51:38 Luiz Augusto von Dentz wrote: > > In previous email I wrote about idea to move that codec stuff into bluez > > itself as bluez code already handles it for android. > > We are not going to do a pulseaudio module in BlueZ, if it is even > possible to have off the tree modules, in android we did that because > it is the only option we had and Im quite sure it probably needs > updating since code must have change since then... Any architecture > that would involve copying data over would be bad for latency, though > android does that, and Im pretty sure doing encoding/decoding on > daemon would be rejected as well. Ok. But why is there already code for encoding/decoding directly in bluez (even it is for android) and not in some separate library/project? Then both android and pulseaudio can benefit from it. As basically now pulseaudio needs to implement exactly same code and logic which is already in bluez project, which is doing that audio encoding. > The D-Bus interface already accounts to the parameter negotiation, > obviously frameworks such as ffmeg or gstreamer would not do it for > use but the module could take up the action to register the endpoint > and respond to the method calls when necessary. Anyway, lets start > with modularization of the endpoints/codecs, that way we can add > native codec support or gstreamer/ffmpeg and each platform decides > with what they want to go. Ok. Prior I start splitting codec related code, I need to know: 1) Cannot we reuse above bluez code for codec encoding which is already used for android? If it needs some refactoring (like stop doing data copying etc...). 2) How should codec switching from pulseaudio API and pactl/pavucontrol looks like? 3) How to handle possible pass-through? E.g. I have already encoded music in aptX format (or MP3 or AAC) and want to send it directly without double decoding-encoding process. And how to handle MP3 input when device supports both aptX and MP3, but currently is activated aptX? > Btw, I guess you were on irc looking for how we prioritize the > matching of endpoints, this is done in the order of endpoint > registration, Yes, but I have not got any answer so I sent incomplete/wIP patch to this mailing list. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
Hi Pali, On Sat, Jul 7, 2018 at 9:44 PM, Pali Rohár wrote: > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote: >> сб, 7 июл. 2018 г. в 19:08, Pali Rohár : >> > >> > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: >> > > > This is a good idea to let external service to do codec-specific >> > > > functions... I agree that it simplify pulseaudio code and other things >> > > > (like proving new codec by external library -- if properly >> > > > implemented), >> > > > but in bluetooth context we should look at questions: >> > > > >> > > > 1) Has gstreamer support for SBC codec? >> > > > >> > > > 2) Has gstreamer support for aptX codec? >> > > > >> > > > These are two major codecs supported by bluetooth headsets. >> > > > >> > > > Answer is: NO >> > > > (SBC is now provided in the "bad" set which is not pre-installed by >> > > > gstreamer) >> > > >> > > Pre-installed doesn't mean much tbh. It is easy enough for packages to >> > > depend on it. >> > >> > Can pulseaudio build process enforce it? >> > >> > > > So gstreamer in current state is not very useful for pulseaudio. >> > > >> > > Writing a plugin around an existing decoder is pretty trivial. As is >> > > exposing libav/ffmpeg codecs. >> > > >> > > > Important are also MPEG1/2 (which are defined as optional by A2DP) >> > > > and also AAC and LDAC which Jan wrote. But gstreamer has again only >> > > > plugins in "bad" and "ugly" sets for them; nothing preinstalled by >> > > > default. >> > > >> > > Again, -bad doesn't mean much in the current day (historically it was a >> > > staging ground). -ugly is for codecs that are known to be >> > > patent-encumbered (and how that's made available is up to packagers). >> > >> > Still more distributions does not compile ffmpeg with all codecs due to >> > patents problems. >> > >> > So there is a high chance that we end up in situation that pulseaudio >> > would not be able to encode audio into codec X (even pulseaudio declare >> > that it support) and user would not be able to do nothing as his >> > distribution does not enabled codec X at compile time. It could be >> > really a legal problem or problem because packager forgot to enable it >> > or because he think that it could be a problem and rather disabled it. >> > >> > The only option to prevent such situation is compile time check. Like >> > now pulseaudio does not compile bluetooth support when sbc codec is not >> > available. And this check should be there even after moving to >> > ffmpeg/gstreamer/whatever. So is this check possible to write in >> > autoconf for that ffmpeg/gstreamer/whatever? >> >> I disagree here. Speaking here as an author of a patented codec (DTS) >> implementation that is well supported by PulseAudio ;) > > But this is something different. DTS is not mandatory and devices in > more cases can work without it (via PCM). But in bluetooth is SBC codec > mandatory and must be always supported. And there are no license > problems with SBC for A2DP bluetooth. > >> I was able to circumvent this kind of legal and technical issues by >> providing a DTS encoder library (https://gitlab.com/patrakov/dcaenc) >> and an ALSA plugin. The library implements stuff that is patented in >> USA and thus cannot be included in USA-patent-free distributions. >> However, the library is small and self-contained (not part of ffmpeg), >> and users who don't care about patents can compile it anytime, and >> they don't even have to replace any distribution-provided file by >> installing this library. PulseAudio includes some profiles that >> reference ALSA PCMs that are covered by the ALSA plugin that comes >> with the library. No compile-time check needed - all the probing of >> the form "can I open this PCM" is done at runtime in a generic way >> that is not patched out by USA-patent-free distributions. Even the use >> case when a product manufacturer has a DTS patent license which >> instructs them to use a specific DTS implementation other than mine is >> covered: that manufacturer can wrap that implementation in an ALSA >> plugin that provides the same PCM names as mine, and PulseAudio will >> still pick that up. >> >> All of that is possible because there is a not-so-horrible extension >> point in ALSA library that allows to write software that takes PCM >> data in and delivers it to strange devices (like a DTS receiver on an >> optical SPDIF link). What we need here is to find a proper equivalent >> of this extension point in the Bluetooth land (e.g. take PCM in, >> produce ready-to-send packets with all the needed metadata). If it >> doesn't exist, create it and use it. >> >> I fully understand the following technical difficulties: >> >> 1. It is unwise to use ffmpeg because it can be compiled improperly >> and is difficult to replace in this case. > > Yes, this is the main problem which I'm pointing. Also I do not know if > ffmpeg has support for (mandatory) SBC codec... > > Now you can either: 1) compile pulseaudio with bluetooth support
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote: > сб, 7 июл. 2018 г. в 19:08, Pali Rohár : > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > > > This is a good idea to let external service to do codec-specific > > > > functions... I agree that it simplify pulseaudio code and other things > > > > (like proving new codec by external library -- if properly implemented), > > > > but in bluetooth context we should look at questions: > > > > > > > > 1) Has gstreamer support for SBC codec? > > > > > > > > 2) Has gstreamer support for aptX codec? > > > > > > > > These are two major codecs supported by bluetooth headsets. > > > > > > > > Answer is: NO > > > > (SBC is now provided in the "bad" set which is not pre-installed by > > > > gstreamer) > > > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages to > > > depend on it. > > > > Can pulseaudio build process enforce it? > > > > > > So gstreamer in current state is not very useful for pulseaudio. > > > > > > Writing a plugin around an existing decoder is pretty trivial. As is > > > exposing libav/ffmpeg codecs. > > > > > > > Important are also MPEG1/2 (which are defined as optional by A2DP) > > > > and also AAC and LDAC which Jan wrote. But gstreamer has again only > > > > plugins in "bad" and "ugly" sets for them; nothing preinstalled by > > > > default. > > > > > > Again, -bad doesn't mean much in the current day (historically it was a > > > staging ground). -ugly is for codecs that are known to be > > > patent-encumbered (and how that's made available is up to packagers). > > > > Still more distributions does not compile ffmpeg with all codecs due to > > patents problems. > > > > So there is a high chance that we end up in situation that pulseaudio > > would not be able to encode audio into codec X (even pulseaudio declare > > that it support) and user would not be able to do nothing as his > > distribution does not enabled codec X at compile time. It could be > > really a legal problem or problem because packager forgot to enable it > > or because he think that it could be a problem and rather disabled it. > > > > The only option to prevent such situation is compile time check. Like > > now pulseaudio does not compile bluetooth support when sbc codec is not > > available. And this check should be there even after moving to > > ffmpeg/gstreamer/whatever. So is this check possible to write in > > autoconf for that ffmpeg/gstreamer/whatever? > > I disagree here. Speaking here as an author of a patented codec (DTS) > implementation that is well supported by PulseAudio ;) But this is something different. DTS is not mandatory and devices in more cases can work without it (via PCM). But in bluetooth is SBC codec mandatory and must be always supported. And there are no license problems with SBC for A2DP bluetooth. > I was able to circumvent this kind of legal and technical issues by > providing a DTS encoder library (https://gitlab.com/patrakov/dcaenc) > and an ALSA plugin. The library implements stuff that is patented in > USA and thus cannot be included in USA-patent-free distributions. > However, the library is small and self-contained (not part of ffmpeg), > and users who don't care about patents can compile it anytime, and > they don't even have to replace any distribution-provided file by > installing this library. PulseAudio includes some profiles that > reference ALSA PCMs that are covered by the ALSA plugin that comes > with the library. No compile-time check needed - all the probing of > the form "can I open this PCM" is done at runtime in a generic way > that is not patched out by USA-patent-free distributions. Even the use > case when a product manufacturer has a DTS patent license which > instructs them to use a specific DTS implementation other than mine is > covered: that manufacturer can wrap that implementation in an ALSA > plugin that provides the same PCM names as mine, and PulseAudio will > still pick that up. > > All of that is possible because there is a not-so-horrible extension > point in ALSA library that allows to write software that takes PCM > data in and delivers it to strange devices (like a DTS receiver on an > optical SPDIF link). What we need here is to find a proper equivalent > of this extension point in the Bluetooth land (e.g. take PCM in, > produce ready-to-send packets with all the needed metadata). If it > doesn't exist, create it and use it. > > I fully understand the following technical difficulties: > > 1. It is unwise to use ffmpeg because it can be compiled improperly > and is difficult to replace in this case. Yes, this is the main problem which I'm pointing. Also I do not know if ffmpeg has support for (mandatory) SBC codec... Now you can either: 1) compile pulseaudio with bluetooth support and bluetooth will work always (because it links to system sbc codec library) or 2) compile pulseaudio without bluetooth support (and it would not work). And for 1) dynami
Re: [pulseaudio-discuss] Bluetooth aptX codec
сб, 7 июл. 2018 г. в 19:08, Pali Rohár : > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > > This is a good idea to let external service to do codec-specific > > > functions... I agree that it simplify pulseaudio code and other things > > > (like proving new codec by external library -- if properly implemented), > > > but in bluetooth context we should look at questions: > > > > > > 1) Has gstreamer support for SBC codec? > > > > > > 2) Has gstreamer support for aptX codec? > > > > > > These are two major codecs supported by bluetooth headsets. > > > > > > Answer is: NO > > > (SBC is now provided in the "bad" set which is not pre-installed by > > > gstreamer) > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages to > > depend on it. > > Can pulseaudio build process enforce it? > > > > So gstreamer in current state is not very useful for pulseaudio. > > > > Writing a plugin around an existing decoder is pretty trivial. As is > > exposing libav/ffmpeg codecs. > > > > > Important are also MPEG1/2 (which are defined as optional by A2DP) > > > and also AAC and LDAC which Jan wrote. But gstreamer has again only > > > plugins in "bad" and "ugly" sets for them; nothing preinstalled by > > > default. > > > > Again, -bad doesn't mean much in the current day (historically it was a > > staging ground). -ugly is for codecs that are known to be patent-encumbered > > (and how that's made available is up to packagers). > > Still more distributions does not compile ffmpeg with all codecs due to > patents problems. > > So there is a high chance that we end up in situation that pulseaudio > would not be able to encode audio into codec X (even pulseaudio declare > that it support) and user would not be able to do nothing as his > distribution does not enabled codec X at compile time. It could be > really a legal problem or problem because packager forgot to enable it > or because he think that it could be a problem and rather disabled it. > > The only option to prevent such situation is compile time check. Like > now pulseaudio does not compile bluetooth support when sbc codec is not > available. And this check should be there even after moving to > ffmpeg/gstreamer/whatever. So is this check possible to write in > autoconf for that ffmpeg/gstreamer/whatever? I disagree here. Speaking here as an author of a patented codec (DTS) implementation that is well supported by PulseAudio ;) I was able to circumvent this kind of legal and technical issues by providing a DTS encoder library (https://gitlab.com/patrakov/dcaenc) and an ALSA plugin. The library implements stuff that is patented in USA and thus cannot be included in USA-patent-free distributions. However, the library is small and self-contained (not part of ffmpeg), and users who don't care about patents can compile it anytime, and they don't even have to replace any distribution-provided file by installing this library. PulseAudio includes some profiles that reference ALSA PCMs that are covered by the ALSA plugin that comes with the library. No compile-time check needed - all the probing of the form "can I open this PCM" is done at runtime in a generic way that is not patched out by USA-patent-free distributions. Even the use case when a product manufacturer has a DTS patent license which instructs them to use a specific DTS implementation other than mine is covered: that manufacturer can wrap that implementation in an ALSA plugin that provides the same PCM names as mine, and PulseAudio will still pick that up. All of that is possible because there is a not-so-horrible extension point in ALSA library that allows to write software that takes PCM data in and delivers it to strange devices (like a DTS receiver on an optical SPDIF link). What we need here is to find a proper equivalent of this extension point in the Bluetooth land (e.g. take PCM in, produce ready-to-send packets with all the needed metadata). If it doesn't exist, create it and use it. I fully understand the following technical difficulties: 1. It is unwise to use ffmpeg because it can be compiled improperly and is difficult to replace in this case. 2. GStreamer can, in theory, wrap the needed libraries, and does support third-party plugins, but does not properly encapsulate the "give me packets ready to send via bluez" part. > > > > To have working bluetooth support in pulseadio, pulseaudio needs to use > > > external library for encoding which *always* provides support for SBC. > > > And not only if user manually installs some special plugin for 3rd party > > > library. (And not only SBC, but also those other aptX, MPEG1/2, AAC and > > > LDAC codecs) > > > > So I continue to disagree. Using a generic framework and letting other > > parts of the system select the codec implementation is what makes sense for > > the widest set of use-cases (this also allows products to ship their own > > implementations of a codec without changing the PulseAudio code). > > Still t
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote: > > This is a good idea to let external service to do codec-specific > > functions... I agree that it simplify pulseaudio code and other things > > (like proving new codec by external library -- if properly implemented), > > but in bluetooth context we should look at questions: > > > > 1) Has gstreamer support for SBC codec? > > > > 2) Has gstreamer support for aptX codec? > > > > These are two major codecs supported by bluetooth headsets. > > > > Answer is: NO > > (SBC is now provided in the "bad" set which is not pre-installed by > > gstreamer) > > Pre-installed doesn't mean much tbh. It is easy enough for packages to depend > on it. Can pulseaudio build process enforce it? > > So gstreamer in current state is not very useful for pulseaudio. > > Writing a plugin around an existing decoder is pretty trivial. As is exposing > libav/ffmpeg codecs. > > > Important are also MPEG1/2 (which are defined as optional by A2DP) > > and also AAC and LDAC which Jan wrote. But gstreamer has again only > > plugins in "bad" and "ugly" sets for them; nothing preinstalled by > > default. > > Again, -bad doesn't mean much in the current day (historically it was a > staging ground). -ugly is for codecs that are known to be patent-encumbered > (and how that's made available is up to packagers). Still more distributions does not compile ffmpeg with all codecs due to patents problems. So there is a high chance that we end up in situation that pulseaudio would not be able to encode audio into codec X (even pulseaudio declare that it support) and user would not be able to do nothing as his distribution does not enabled codec X at compile time. It could be really a legal problem or problem because packager forgot to enable it or because he think that it could be a problem and rather disabled it. The only option to prevent such situation is compile time check. Like now pulseaudio does not compile bluetooth support when sbc codec is not available. And this check should be there even after moving to ffmpeg/gstreamer/whatever. So is this check possible to write in autoconf for that ffmpeg/gstreamer/whatever? > > To have working bluetooth support in pulseadio, pulseaudio needs to use > > external library for encoding which *always* provides support for SBC. > > And not only if user manually installs some special plugin for 3rd party > > library. (And not only SBC, but also those other aptX, MPEG1/2, AAC and > > LDAC codecs) > > So I continue to disagree. Using a generic framework and letting other parts > of the system select the codec implementation is what makes sense for the > widest set of use-cases (this also allows products to ship their own > implementations of a codec without changing the PulseAudio code). Still this is not enough for bluetooth codec. For specific codec you need to create bluez dbus endpoint with codec specific parameters. Plus implement select and set methods to decide on codec parameters between pulseaudio and bluetooth headset. And finally to send encoded data you need to know how to send them. To which endpoint, how header looks like etc... Some codecs needs to wrap data into RTP (e.g. SBC), some must not have RTP (e.g. aptX). And after that comes data from codec encoder function. So is there any library which all above support? I have not find anything. Nor ffmpeg nor gstreamer. Which means that pulseaudio cannot delegate codec selection, codec initialization and codec encoding to some external library (yet). Anyway, now in bluez source code is some kind of codec encoding support for android systems. Therefore should not be a wise idea to move all these codec A2DP mess into bluez source code? Because now part of A2DP is in bluez and another part in pulseaudio. And on android is everything in bluez now. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Thu, 21 Jun 2018, at 4:32 PM, Pali Rohár wrote: > On Thursday 21 June 2018 05:45:39 Arun Raghavan wrote: > > On Wed, 20 Jun 2018, at 9:05 PM, Jan Alexander Steffens wrote: > > > On Mon, Jun 18, 2018, 09:42 Pali Rohár wrote: > > > > > > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > > > > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > > > > > > Hi! As you may know lot of bluetooth headsets support not only SBC, > > > > > > but > > > > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > > > > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but > > > > > > ffmpeg has clean-room implementation based on expired patent. What > > > > about > > > > > > adding support for aptX via ffmpeg into pulseaudio? > > > > > > > > > > > > -- > > > > > > > > > > I'd actually like to delete the SBC code and replace it with a generic > > > > GStreamer bin. That would allow us to be codec agnostic, and support > > > > any of > > > > the codecs that are supported by GStreamer (which includes those that > > > > ffmpeg provides). > > > > > > > > This does not sound like a good idea. The only two relevant bluetooth > > > > codecs for most people are SBC and aptX. > > > > > > > > > > Don't forget AAC. I've seen this one a lot in devices meant for use with > > > iPhones, which apparently don't have aptX. GStreamer has a lot of encoders > > > for it so this shouldn't be a problem unless it's some strange AAC > > > variant. > > > > > > There's also LDAC but I haven't seen it on a device yet. > > > > Right, there are multiple codecs that we can support, and we should not tie > > ourselves to a specific implementation. For this reason, and more > > generally, I'd like to have PulseAudio not have to deal with any codec > > implementations at all (nor even RTP, if we can help it), hence my > > preference to use something generic in the form of GStreamer. > > This is a good idea to let external service to do codec-specific > functions... I agree that it simplify pulseaudio code and other things > (like proving new codec by external library -- if properly implemented), > but in bluetooth context we should look at questions: > > 1) Has gstreamer support for SBC codec? > > 2) Has gstreamer support for aptX codec? > > These are two major codecs supported by bluetooth headsets. > > Answer is: NO > (SBC is now provided in the "bad" set which is not pre-installed by > gstreamer) Pre-installed doesn't mean much tbh. It is easy enough for packages to depend on it. > So gstreamer in current state is not very useful for pulseaudio. Writing a plugin around an existing decoder is pretty trivial. As is exposing libav/ffmpeg codecs. > Important are also MPEG1/2 (which are defined as optional by A2DP) > and also AAC and LDAC which Jan wrote. But gstreamer has again only > plugins in "bad" and "ugly" sets for them; nothing preinstalled by > default. Again, -bad doesn't mean much in the current day (historically it was a staging ground). -ugly is for codecs that are known to be patent-encumbered (and how that's made available is up to packagers). > To have working bluetooth support in pulseadio, pulseaudio needs to use > external library for encoding which *always* provides support for SBC. > And not only if user manually installs some special plugin for 3rd party > library. (And not only SBC, but also those other aptX, MPEG1/2, AAC and > LDAC codecs) So I continue to disagree. Using a generic framework and letting other parts of the system select the codec implementation is what makes sense for the widest set of use-cases (this also allows products to ship their own implementations of a codec without changing the PulseAudio code). -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Wednesday 20 June 2018 17:35:42 Jan Alexander Steffens wrote: > On Mon, Jun 18, 2018, 09:42 Pali Rohár wrote: > > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > > > > Hi! As you may know lot of bluetooth headsets support not only SBC, but > > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but > > > > ffmpeg has clean-room implementation based on expired patent. What > > about > > > > adding support for aptX via ffmpeg into pulseaudio? > > > > > > > > -- > > > > > > I'd actually like to delete the SBC code and replace it with a generic > > GStreamer bin. That would allow us to be codec agnostic, and support any of > > the codecs that are supported by GStreamer (which includes those that > > ffmpeg provides). > > > > This does not sound like a good idea. The only two relevant bluetooth > > codecs for most people are SBC and aptX. > > > > Don't forget AAC. I've seen this one a lot in devices meant for use with > iPhones, which apparently don't have aptX. GStreamer has a lot of encoders > for it so this shouldn't be a problem unless it's some strange AAC variant. > > There's also LDAC but I haven't seen it on a device yet. 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. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Thursday 21 June 2018 05:45:39 Arun Raghavan wrote: > On Wed, 20 Jun 2018, at 9:05 PM, Jan Alexander Steffens wrote: > > On Mon, Jun 18, 2018, 09:42 Pali Rohár wrote: > > > > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > > > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > > > > > Hi! As you may know lot of bluetooth headsets support not only SBC, > > > > > but > > > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > > > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but > > > > > ffmpeg has clean-room implementation based on expired patent. What > > > about > > > > > adding support for aptX via ffmpeg into pulseaudio? > > > > > > > > > > -- > > > > > > > > I'd actually like to delete the SBC code and replace it with a generic > > > GStreamer bin. That would allow us to be codec agnostic, and support any > > > of > > > the codecs that are supported by GStreamer (which includes those that > > > ffmpeg provides). > > > > > > This does not sound like a good idea. The only two relevant bluetooth > > > codecs for most people are SBC and aptX. > > > > > > > Don't forget AAC. I've seen this one a lot in devices meant for use with > > iPhones, which apparently don't have aptX. GStreamer has a lot of encoders > > for it so this shouldn't be a problem unless it's some strange AAC variant. > > > > There's also LDAC but I haven't seen it on a device yet. > > Right, there are multiple codecs that we can support, and we should not tie > ourselves to a specific implementation. For this reason, and more generally, > I'd like to have PulseAudio not have to deal with any codec implementations > at all (nor even RTP, if we can help it), hence my preference to use > something generic in the form of GStreamer. This is a good idea to let external service to do codec-specific functions... I agree that it simplify pulseaudio code and other things (like proving new codec by external library -- if properly implemented), but in bluetooth context we should look at questions: 1) Has gstreamer support for SBC codec? 2) Has gstreamer support for aptX codec? These are two major codecs supported by bluetooth headsets. Answer is: NO (SBC is now provided in the "bad" set which is not pre-installed by gstreamer) So gstreamer in current state is not very useful for pulseaudio. Important are also MPEG1/2 (which are defined as optional by A2DP) and also AAC and LDAC which Jan wrote. But gstreamer has again only plugins in "bad" and "ugly" sets for them; nothing preinstalled by default. To have working bluetooth support in pulseadio, pulseaudio needs to use external library for encoding which *always* provides support for SBC. And not only if user manually installs some special plugin for 3rd party library. (And not only SBC, but also those other aptX, MPEG1/2, AAC and LDAC codecs) -- 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] Bluetooth aptX codec
On Wednesday 20 June 2018 17:40:09 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Mon, Jun 18, 2018 at 10:35 AM, Pali Rohár wrote: > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > >> On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > >> > Hi! As you may know lot of bluetooth headsets support not only SBC, but > >> > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > >> > aptX HD encoder and decoder. AptX codec itself is proprietary, but > >> > ffmpeg has clean-room implementation based on expired patent. What about > >> > adding support for aptX via ffmpeg into pulseaudio? > >> > > >> > -- > >> > >> I'd actually like to delete the SBC code and replace it with a generic > >> GStreamer bin. That would allow us to be codec agnostic, and support any > >> of the codecs that are supported by GStreamer (which includes those that > >> ffmpeg provides). > > > > This does not sound like a good idea. The only two relevant bluetooth > > codecs for most people are SBC and aptX. > > > > IIRC you cannot just choose arbitrary codec and use it in bluetooth, you > > need to know how to put it into A2DP. Therefore for each bluetooth codec > > you need to write some A2DP code or at least declarative definition. So > > it would not work just adding dependency on gstreamer and let gstreamer > > provide some encoded stream. > > I guess we could limit to only codecs we know how to expose the > capabilities, but note that it is possible to define vendor specific > codecs in A2DP so in theory one can use other codecs like OPUS > although it most likely won't have much use without the remote to also > support them, but I guess it is a start. Yes, it is possible to define vendor specific codes in A2DP, but then only that "vendor" implementation would support that codec. So if you define "pulseaudio" vendor codec, then only other instance of pulseaudio on other A2DP would be able to use it. Which is not so much useful. > > And also we cannot ensure or force at compile time that users would have > > installed both gstreamer and ffmpeg at runtime to have working bluetooth > > support. > > We anyway register endpoints at runtime and if we cannot detect SBC > for example we can still fallback to non-gstreamer/native mode. That means we still need to have native (libsbc?) implementation in pulseadio. Then somebody can ask question: why we need to have support for gstreamer's sbc, if pulseaudio has own native support? (no offense) > > For me it looks like a overkill to add dependency on gstreamer to > > pulseaudio, which would have some runtime dependency on ffmpeg to have > > working bluetooth support. And it would work only with the last ffmpeg > > version which is not widely available yet (and replacing system version > > is not always trivial). > > > > Anyway, I would try to write simple aptX library based on published > > details and ffmpeg source code. And try to play with pulseaudio if I > > would be able to start streaming aptX to bluetooth headset. This is at > > least good starting point to prove that aptX codec is usable or not in > > pulseaudio. > > Having native support won't be bad either but I think we need to have > some module support added in order to make easier to add new codecs > which should be useful if we ever come to integrate with gstreamer. Module support in pulseaudio could be useful. But for every codec you need to define how to use it in A2DP. And because gstreamer does not provide this information, the only thing which can be done is definition of every supported codec in pulseaudio with code which would call gstreamer function for encoding (or decoding). I think this is too much work without big benefit for users. > > -- > > Pali Rohár > > pali.ro...@gmail.com > > ___ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > -- 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] Bluetooth aptX codec
On Wed, 20 Jun 2018, at 9:05 PM, Jan Alexander Steffens wrote: > On Mon, Jun 18, 2018, 09:42 Pali Rohár wrote: > > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > > > > Hi! As you may know lot of bluetooth headsets support not only SBC, but > > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but > > > > ffmpeg has clean-room implementation based on expired patent. What > > about > > > > adding support for aptX via ffmpeg into pulseaudio? > > > > > > > > -- > > > > > > I'd actually like to delete the SBC code and replace it with a generic > > GStreamer bin. That would allow us to be codec agnostic, and support any of > > the codecs that are supported by GStreamer (which includes those that > > ffmpeg provides). > > > > This does not sound like a good idea. The only two relevant bluetooth > > codecs for most people are SBC and aptX. > > > > Don't forget AAC. I've seen this one a lot in devices meant for use with > iPhones, which apparently don't have aptX. GStreamer has a lot of encoders > for it so this shouldn't be a problem unless it's some strange AAC variant. > > There's also LDAC but I haven't seen it on a device yet. Right, there are multiple codecs that we can support, and we should not tie ourselves to a specific implementation. For this reason, and more generally, I'd like to have PulseAudio not have to deal with any codec implementations at all (nor even RTP, if we can help it), hence my preference to use something generic in the form of GStreamer. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Mon, Jun 18, 2018, 09:42 Pali Rohár wrote: > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > > > Hi! As you may know lot of bluetooth headsets support not only SBC, but > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but > > > ffmpeg has clean-room implementation based on expired patent. What > about > > > adding support for aptX via ffmpeg into pulseaudio? > > > > > > -- > > > > I'd actually like to delete the SBC code and replace it with a generic > GStreamer bin. That would allow us to be codec agnostic, and support any of > the codecs that are supported by GStreamer (which includes those that > ffmpeg provides). > > This does not sound like a good idea. The only two relevant bluetooth > codecs for most people are SBC and aptX. > Don't forget AAC. I've seen this one a lot in devices meant for use with iPhones, which apparently don't have aptX. GStreamer has a lot of encoders for it so this shouldn't be a problem unless it's some strange AAC variant. There's also LDAC but I haven't seen it on a device yet. > ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
Hi Pali, On Mon, Jun 18, 2018 at 10:35 AM, Pali Rohár wrote: > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: >> On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: >> > Hi! As you may know lot of bluetooth headsets support not only SBC, but >> > also aptX codec. And new version of ffmpeg (4.0) has native aptX and >> > aptX HD encoder and decoder. AptX codec itself is proprietary, but >> > ffmpeg has clean-room implementation based on expired patent. What about >> > adding support for aptX via ffmpeg into pulseaudio? >> > >> > -- >> >> I'd actually like to delete the SBC code and replace it with a generic >> GStreamer bin. That would allow us to be codec agnostic, and support any of >> the codecs that are supported by GStreamer (which includes those that ffmpeg >> provides). > > This does not sound like a good idea. The only two relevant bluetooth > codecs for most people are SBC and aptX. > > IIRC you cannot just choose arbitrary codec and use it in bluetooth, you > need to know how to put it into A2DP. Therefore for each bluetooth codec > you need to write some A2DP code or at least declarative definition. So > it would not work just adding dependency on gstreamer and let gstreamer > provide some encoded stream. I guess we could limit to only codecs we know how to expose the capabilities, but note that it is possible to define vendor specific codecs in A2DP so in theory one can use other codecs like OPUS although it most likely won't have much use without the remote to also support them, but I guess it is a start. > And also we cannot ensure or force at compile time that users would have > installed both gstreamer and ffmpeg at runtime to have working bluetooth > support. We anyway register endpoints at runtime and if we cannot detect SBC for example we can still fallback to non-gstreamer/native mode. > For me it looks like a overkill to add dependency on gstreamer to > pulseaudio, which would have some runtime dependency on ffmpeg to have > working bluetooth support. And it would work only with the last ffmpeg > version which is not widely available yet (and replacing system version > is not always trivial). > > Anyway, I would try to write simple aptX library based on published > details and ffmpeg source code. And try to play with pulseaudio if I > would be able to start streaming aptX to bluetooth headset. This is at > least good starting point to prove that aptX codec is usable or not in > pulseaudio. Having native support won't be bad either but I think we need to have some module support added in order to make easier to add new codecs which should be useful if we ever come to integrate with gstreamer. > -- > Pali Rohár > pali.ro...@gmail.com > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote: > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > > Hi! As you may know lot of bluetooth headsets support not only SBC, but > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > > aptX HD encoder and decoder. AptX codec itself is proprietary, but > > ffmpeg has clean-room implementation based on expired patent. What about > > adding support for aptX via ffmpeg into pulseaudio? > > > > -- > > I'd actually like to delete the SBC code and replace it with a generic > GStreamer bin. That would allow us to be codec agnostic, and support any of > the codecs that are supported by GStreamer (which includes those that ffmpeg > provides). This does not sound like a good idea. The only two relevant bluetooth codecs for most people are SBC and aptX. IIRC you cannot just choose arbitrary codec and use it in bluetooth, you need to know how to put it into A2DP. Therefore for each bluetooth codec you need to write some A2DP code or at least declarative definition. So it would not work just adding dependency on gstreamer and let gstreamer provide some encoded stream. And also we cannot ensure or force at compile time that users would have installed both gstreamer and ffmpeg at runtime to have working bluetooth support. For me it looks like a overkill to add dependency on gstreamer to pulseaudio, which would have some runtime dependency on ffmpeg to have working bluetooth support. And it would work only with the last ffmpeg version which is not widely available yet (and replacing system version is not always trivial). Anyway, I would try to write simple aptX library based on published details and ffmpeg source code. And try to play with pulseaudio if I would be able to start streaming aptX to bluetooth headset. This is at least good starting point to prove that aptX codec is usable or not in pulseaudio. -- 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] Bluetooth aptX codec
On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote: > Hi! As you may know lot of bluetooth headsets support not only SBC, but > also aptX codec. And new version of ffmpeg (4.0) has native aptX and > aptX HD encoder and decoder. AptX codec itself is proprietary, but > ffmpeg has clean-room implementation based on expired patent. What about > adding support for aptX via ffmpeg into pulseaudio? > > -- I'd actually like to delete the SBC code and replace it with a generic GStreamer bin. That would allow us to be codec agnostic, and support any of the codecs that are supported by GStreamer (which includes those that ffmpeg provides). Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
