Sorry, for seeing this one a bit late.

First of all the relevant problem is

(  15.152|   0.000) E: [pulseaudio] volume.c: Assertion
'pa_channels_valid(channels)' failed at pulse/volume.c:74, function
pa_cvolume_set(). Aborting.

Which basically means there is a volume level being set for an invalid
channel (simply a number which is out of range once passed to

Looking into the code the function source_set_volume_cb in
src/modules/bluetooth/module-bluez5-device.c (line 961) calls
pa_cvolume_set and also sink_set_volume_cb (line 1187). Each gets called
for either when a source or sink is added to the device and the profile
being used is PA_BLUETOOTH_PROFILE_HEADSET_HEAD_UNIT. The sample_spec
struct being used to provide the channel is configured in
transport_config which is according to the log file attached in comment
#1 never called before the abort happens. The function transport_acquire
is called before and returns an error according to:

(  14.894|   0.000) D: [pulseaudio] module-bluez5-device.c: Acquiring transport 
(  14.894|   0.000) I: [pulseaudio] backend-native.c: doing connect
(  15.151|   0.257) E: [pulseaudio] backend-native.c: connect(): Function not 

That the connect() syscall returns "Function no implemented" is

If we're going further in the log file we see

(  15.152|   0.000) D: [pulseaudio] backend-native.c: Transport
/org/bluez/hci0/dev_44_5E_F3_B4_07_29/fd49 available for profile

which happens inside src/modules/bluetooth/backend-native.c in function
profile_new_connection when we get called back from bluez if the HFP
profile you get connected with the remote side.

The next line is the interesting one:

(  15.152|   0.000) D: [pulseaudio] backend-native.c: RFCOMM << AT+VGS=8

This actually comes from set_speaker_gain in src/modules/bluetooth
/backend-native.c line 276 and is called by sink_set_volume_cb in
src/modules/bluetooth/module-bluez5-device.c (line 1187) which is called
subsequently from add_sink -> init_profile. As set_speaker_gain prints
out the string "RFCOMM << AT+VGS=8" AFTER it has the set volume in
sink_set_volume_cb the first call to pa_cvolume_set already happened and
went through without the assert in pa_cvolume_set failing for an
incorrect channel. The only left candidate then is source_set_volume_cb
but that one is using the same u->sample_spec.channels value as we used
before and it shouldn't have changed in between.

What somebody should now look into: Add pa_log_debug lines before and
after the actual pa_cvolume_set calls in src/modules/bluetooth/module-
bluez5-device.c so that we can verify which is actually causing the
abort. These should also print the value of u->sample_spec.channels.
With that we have at least the line which is causing the abort and can
then look into possible reasons why this is happening. I suspect the
order of a specific code flow has change slightly with the SCO-over-PCM
changes we did for Ubuntu Touch.

Also it would be great if someone who removed the patches can provide a
log file for pulseaudio in debug mode where the headset gets connected
and no abort occurs.

@Luke: Can you provide packages with the necessary changes so that
people expiring the abort can install these and provide new log files?

You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

  pulseaudio crashes when connecting to bluetooth headphones (due to
  ubuntu changes?)

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to