Re: [pulseaudio-discuss] Pulseaudio latency
On Wed, Aug 1, 2018 at 12:27 AM Georg Chini wrote: > On 31.07.2018 10:22, Harish Gaddameedi wrote: > > > On Tue, Jul 31, 2018 at 12:42 PM Harish Gaddameedi < > harish.gaddame...@smartron.com> wrote: > >> On Tue, Jul 31, 2018 at 12:11 PM Harish Gaddameedi < >> harish.gaddame...@smartron.com> wrote: >> >>> >>> >>> *Please do not top-post. To me it looks like that is an issue in the >>> ALSA driver and not related to pulseaudio. The driver must be reporting the >>> wrong latency. Did you set the loopback latency to* >>> *300 ms? Default is 200 ms.* >>> >>> >>> Sorry, I use default settings, gmail is doing top posting. >>> No, i didn't set any loopback latency. I'll check with the alsa driver >>> and get back to you. >>> >>> -- >>> Thanks, >>> Harish Gaddameedi >>> >> > Hi Georg, > > There is one more important point i wanted to discuss, this is which we > have capture from your reply of clock synchronisation. Can you conform > whether the system clock and audio clock both are same or different? > > > System clock and audio clock need not be equal. Each sound card has its own > clock which might not be synchronized with system clock or wall clock. > Basically, if your sound card claims to run on 44100 Hz, it may be slightly > more or less if measured in "real" (wall clock) time. > module-loopback is normally capable of detecting the clock difference and > adjusts the sink-input sample rate so that the latency remains constant. > This > is why you see in the log, that the module is not using 44100 Hz but in > fact > some other (in your case lower) sample rate. PA then does re-sampling > from that rate to your sound card rate. > > For the A2DP sink (bluetooth headset or speaker) the system clock is used > for timing, so for this special case the audio clock matches system clock. > Hi Georg, I have found some cause for the pulseaudio Latency, can you please look into the below log. During this process of "*alsa-sink.c: Tried rewind, but was apparently not possible*", the latency is coming. Fri Aug 10 11:21:28 2018 user.info pulseaudio[4396]: (50087.559| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: Tried rewind, but was apparently not possible. Fri Aug 10 11:21:28 2018 user.debug pulseaudio[4396]: (50087.575| 0.015) [alsa-sink-I2S cx2072x-dsp-0] protocol-native.c: Requesting rewind due to end of underrun. Fri Aug 10 11:21:28 2018 user.debug pulseaudio[4396]: (50087.575| 0.000) [alsa-sink-I2S cx2072x-dsp-0] protocol-native.c: Requesting rewind due to end of underrun. Fri Aug 10 11:21:28 2018 user.debug pulseaudio[4396]: (50087.577| 0.001) [alsa-sink-I2S cx2072x-dsp-0] protocol-native.c: Requesting rewind due to end of underrun. Fri Aug 10 11:21:28 2018 user.debug pulseaudio[4396]: (50087.579| 0.002) [alsa-sink-I2S cx2072x-dsp-0] protocol-native.c: Requesting rewind due to end of underrun. Fri Aug 10 11:21:28 2018 user.debug pulseaudio[4396]: (50087.580| 0.000) [alsa-sink-I2S cx2072x-dsp-0] sink-input.c: Requesting rewind due to uncorking Fri Aug 10 11:21:28 2018 user.debug pulseaudio[4396]: (50087.580| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: Requested to rewind 76608 bytes. Fri Aug 10 11:21:28 2018 user.debug pulseaudio[4396]: (50087.580| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: Limited to 68288 bytes. Fri Aug 10 11:21:28 2018 user.debug pulseaudio[4396]: (50087.581| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: before: 17072 Fri Aug 10 11:21:28 2018 user.debug pulseaudio[4396]: (50087.581| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: after: 0 Fri Aug 10 11:21:28 2018 user.info pulseaudio[4396]: (50087.581| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: Tried rewind, but was apparently not possible. Fri Aug 10 11:21:31 2018 user.debug pulseaudio[4396]: (50090.231| 2.650) [alsa-sink-I2S cx2072x-dsp-0] sink-input.c: Requesting rewind due to corking Fri Aug 10 11:21:31 2018 user.debug pulseaudio[4396]: (50090.231| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: Requested to rewind 76608 bytes. Fri Aug 10 11:21:31 2018 user.debug pulseaudio[4396]: (50090.232| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: Limited to 12992 bytes. Fri Aug 10 11:21:31 2018 user.debug pulseaudio[4396]: (50090.232| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: before: 3248 Fri Aug 10 11:21:31 2018 user.debug pulseaudio[4396]: (50090.232| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: after: 0 Fri Aug 10 11:21:31 2018 user.info pulseaudio[4396]: (50090.232| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: Tried rewind, but was apparently not possible. Fri Aug 10 11:21:31 2018 user.debug pulseaudio[4396]: (50090.241| 0.009) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: hwbuf_unused=0 Fri Aug 10 11:21:31 2018 user.debug pulseaudio[4396]: (50090.241| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: setting avail_min=18193 Fri Aug 10 11:21:31 2018 user.debug pulseaudio[4396]: (50090.242| 0.000) [alsa-sink-I2S cx2072x-dsp-0] alsa-sink.c: Requested to
Re: [pulseaudio-discuss] [PATCH v2 0/2] Bluetooth A2DP aptX codec support
On Sunday 05 August 2018 11:08:25 Arun Raghavan wrote: > On Fri, 3 Aug 2018, at 7:13 PM, ValdikSS wrote: > > On 03.08.2018 16:32, Pali Rohár wrote: > > > On Friday 03 August 2018 16:22:05 ValdikSS wrote: > > >> Doesn't work for me with Intel 7260 Bluetooth 4.0 and RealForce > > >> OverDrive D1. > > >> > > >> When I connect headphones and change Pulseaudio profile from "Off" to > > >> "High Fidelity SBC playback (a2dp sink)", everything works as expected > > >> with SBC. > > >> Profile does not switch if I choose "High Fidelity aptX playback (a2dp > > >> sink)" when SBC profile is already active, log message: > > >> > > >> W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to > > >> a2dp_aptx_sink: Not connected > > > Profile switching does not work -- bluez does not provide API for it. > > > > > > Codec is chosen by bluez and headset when doing handshake. Try to > > > initialize A2DP connection from computer, not from headset. Then bluez > > > should choose aptX codec in case your headset supports it. > > > > Works now: > > AVDTP: Set Configuration (0x03) Command (0x00) type 0x00 label 10 > > nosp 0 > > ACP SEID: 5 > > INT SEID: 1 > > Service Category: Media Transport (0x01) > > Service Category: Media Codec (0x07) > > Media Type: Audio (0x00) > > Media Codec: Non-A2DP (0xff) > > Vendor ID: APT Licensing Ltd. (0x004f) > > Vendor Specific Codec ID: aptX (0x0001) > > Frequency: 44100 (0x20) > > Channel Mode: Stereo (0x02) > > > > > > > >> When I try to switch to aptX profile from "off" profile, pulseaudio > > >> crashes: > > >> > > >> E: [pulseaudio] module-bluez5-device.c: Assertion '!u->thread' failed at > > >> modules/bluetooth/module-bluez5-device.c:1491, function start_thread(). > > >> Aborting. > > > Try: > > > > > > $ pactl unload-module module-bluetooth-policy > > > > > > Seems that policy module needs to be fixed for new aptx profiles. > > > > That works, thanks. > > > > > > > >> Thread 1 "pulseaudio" received signal SIGABRT, Aborted. > > >> 0x744edfeb in raise () from /lib64/libc.so.6 > > >> (gdb) bt > > >> #0 0x744edfeb in raise () from /lib64/libc.so.6 > > >> #1 0x744d85c1 in abort () from /lib64/libc.so.6 > > >> #2 0x7fff7f3dab45 in start_thread (u=u@entry=0x5593d640) at > > >> modules/bluetooth/module-bluez5-device.c:1491 > > >> #3 0x7fff7f3dd263 in set_profile_cb (c=, > > >> new_profile=0x559251a0) at > > >> modules/bluetooth/module-bluez5-device.c:1859 > > >> #4 0x77b5148e in pa_card_set_profile (c=c@entry=0x558e4c20, > > >> profile=profile@entry=0x559251a0, save=save@entry=true) at > > >> pulsecore/card.c:318 > > >> #5 0x7fffe0a0362d in command_set_card_profile (pd=, > > >> command=, tag=127, t=, userdata= > >> out>) at pulsecore/protocol-native.c:4728 > > >> #6 0x76d83813 in pa_pdispatch_run (pd=0x55a2e4b0, > > >> packet=packet@entry=0x558a3020, > > >> ancil_data=ancil_data@entry=0x55975bf8, > > >> userdata=userdata@entry=0x558bebf0) at pulsecore/pdispatch.c:346 > > >> #7 0x7fffe0a0bee9 in pstream_packet_callback (p=0x55975960, > > >> packet=0x558a3020, ancil_data=0x55975bf8, > > >> userdata=0x558bebf0) at pulsecore/protocol-native.c:4951 > > >> #8 0x76d8629d in do_read (p=p@entry=0x55975960, > > >> re=re@entry=0x55975b28) at pulsecore/pstream.c:1012 > > >> #9 0x76d890eb in do_pstream_read_write (p=0x55975960) at > > >> pulsecore/pstream.c:248 > > >> #10 0x76d8949d in srb_callback (srb=0x558b0660, > > >> userdata=0x55975960) at pulsecore/pstream.c:287 > > >> #11 0x76d89d2a in srbchannel_rwloop (sr=0x558b0660) at > > >> pulsecore/srbchannel.c:190 > > >> #12 0x778fc8a8 in dispatch_pollfds (m=0x5576f120) at > > >> pulse/mainloop.c:140 > > >> #13 pa_mainloop_dispatch (m=m@entry=0x5576f120) at > > >> pulse/mainloop.c:898 > > >> #14 0x778fcb80 in pa_mainloop_iterate (m=0x5576f120, > > >> block=, retval=0x7fffdc18) at pulse/mainloop.c:929 > > >> #15 0x778fcc20 in pa_mainloop_run (m=0x5576f120, > > >> retval=0x7fffdc18) at pulse/mainloop.c:945 > > >> #16 0xb0c9 in main (argc=, argv= > >> out>) at daemon/main.c:1144 > > >> > > >> > > >> I haven't installed any patches for bluez itself. Should I? If yes, > > >> which exactly? > > > There are no bluez patches. > > > > > >> I moved libopenaptx to autotools and made Fedora .spec file for > > >> openaptx, are you interested in autotools support for libopenaptx, > > >> should I create a pull request to your repository? > > > Nope, I'm not interested to use autohell, simple Makefile for simple > > > library is enough :-) Basically I see no reason for conversion to tool > > > which then just generate Makefile back. > > > > I don't like autotools either, but it make
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] Bi-directional Bluetooth A2DP
On Wednesday 08 August 2018 10:00:28 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Sat, Jul 28, 2018 at 10:34 PM, Pali Rohár wrote: > > Hi! > > > > Some Bluetooth A2DP codecs like aptX Low Latency or FastStream provides > > "backchannel" support for voice data. And it really in A2DP profile. > > > > It can be very useful as there is no need to switch between A2DP and HSP > > modes. > > > > Now I was able to get FastStream codec (rebranded SBC) working in > > PulseAudio. And in "btmon" I see that my headset started sending > > backchannel voice data in SBC codec. I decoded that dump and it is > > really SBC codec, voice is in very good quality, better then in > > HSP profile. I hope that bluez can send them to pulseaudio via file > > descriptor. > > The fd sent to PA is a socket which is already bi-directional. Ok. > > Question is, how to handle this configuration in pulseaudio? Should it > > be a new profile for bluetooth devices which would provides both sink > > and source? Because now A2DP is one-direction profile, not > > bi-directional. > > While A2DP only configures a single direction we can assume > bi-directional depending on the endpoint, so in theory all you have to > do is register an endpoint for FastStream and create both sink and > source when it is connected. That said note that A2DP uses L2CAP on > top of ACL link which is asynchronous so it may not be as low latency > as SCO, but I guess being able to chat while listening to stereo audio > is quite convenient in some situations (e.g. when gaming). I mean how to export this configuration from pulseaudio. If it should be a new profile on pulseaudio card, or something different. After correct bluez endpoint registration I was able to send data to headset which correctly played it -- this is working. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
