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. (0x0000004f) > >            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. > > >> 0x00007ffff44edfeb in raise () from /lib64/libc.so.6 > > >> (gdb) bt > > >> #0 0x00007ffff44edfeb in raise () from /lib64/libc.so.6 > > >> #1 0x00007ffff44d85c1 in abort () from /lib64/libc.so.6 > > >> #2 0x00007fff7f3dab45 in start_thread (u=u at entry=0x55555593d640) at modules/bluetooth/module-bluez5-device.c:1491 > > >> #3 0x00007fff7f3dd263 in set_profile_cb (c=<optimized out>, new_profile=0x5555559251a0) at modules/bluetooth/module-bluez5-device.c:1859 > > >> #4 0x00007ffff7b5148e in pa_card_set_profile (c=c at entry=0x5555558e4c20, profile=profile at entry=0x5555559251a0, save=save at entry=true) at pulsecore/card.c:318 > > >> #5 0x00007fffe0a0362d in command_set_card_profile (pd=<optimized out>, command=<optimized out>, tag=127, t=<optimized out>, userdata=<optimized out>) at pulsecore/protocol-native.c:4728 > > >> #6 0x00007ffff6d83813 in pa_pdispatch_run (pd=0x555555a2e4b0, packet=packet at entry=0x5555558a3020, ancil_data=ancil_data at entry=0x555555975bf8, userdata=userdata at entry=0x5555558bebf0) at pulsecore/pdispatch.c:346 > > >> #7 0x00007fffe0a0bee9 in pstream_packet_callback (p=0x555555975960, packet=0x5555558a3020, ancil_data=0x555555975bf8, userdata=0x5555558bebf0) at pulsecore/protocol-native.c:4951 > > >> #8 0x00007ffff6d8629d in do_read (p=p at entry=0x555555975960, re=re at entry=0x555555975b28) at pulsecore/pstream.c:1012 > > >> #9 0x00007ffff6d890eb in do_pstream_read_write (p=0x555555975960) at pulsecore/pstream.c:248 > > >> #10 0x00007ffff6d8949d in srb_callback (srb=0x5555558b0660, userdata=0x555555975960) at pulsecore/pstream.c:287 > > >> #11 0x00007ffff6d89d2a in srbchannel_rwloop (sr=0x5555558b0660) at pulsecore/srbchannel.c:190 > > >> #12 0x00007ffff78fc8a8 in dispatch_pollfds (m=0x55555576f120) at pulse/mainloop.c:140 > > >> #13 pa_mainloop_dispatch (m=m at entry=0x55555576f120) at pulse/mainloop.c:898 > > >> #14 0x00007ffff78fcb80 in pa_mainloop_iterate (m=0x55555576f120, block=<optimized out>, retval=0x7fffffffdc18) at pulse/mainloop.c:929 > > >> #15 0x00007ffff78fcc20 in pa_mainloop_run (m=0x55555576f120, retval=0x7fffffffdc18) at pulse/mainloop.c:945 > > >> #16 0x000055555555b0c9 in main (argc=<optimized out>, argv=<optimized 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 packaging much easier since > > all distros support autotools packaging almost automatically. It also > > handles shared/static libraries, libtool, different paths and cross- > > compilation with just configure flags. > > It would be maintenance burden to package library with a simple custom > > makefile. I do not think so. This is regular and simple Makefile. You just supply *standard* variables likes CC, CPPFLAGS, CFLAGS, LDFLAGS and everything compiles correctly. There is no problem with cross-compilation. Just set correct CC. What makes cross-compilation, specifying different paths (rpaths, lpaths,...) problematic is autohell and its autodetection which more times is broken. > You can consider meson for this as well. I'm not doing any autodetection, system checks or trying to figure out for dependences and external headers or libraries. This is simple standalone library without any dependency and without any external tools. Therefore I really do not need any special build system as hard dependency. Also I do not need any tool for generating complicated Makefile. My is very simple. -- Pali Rohár pali.rohar at gmail.com
