[pulseaudio-discuss] Bluetooth devices no longer detected after upgrade from 2.0 to 4.0
Georg Chini
georg at chini.tk
Mon Jul 1 03:16:59 PDT 2013
On 01.07.2013 10:47, Mikel Astiz wrote:
> Hi Georg,
>
> On Sun, Jun 30, 2013 at 2:48 PM, Georg Chini <georg at chini.tk> wrote:
>> Hi again,
>>
>>
>> On 30.06.2013 12:57, Mikel Astiz wrote:
>>> Hi Georg,
>>>
>>> On Sun, Jun 30, 2013 at 11:00 AM, Georg Chini <georg at chini.tk> wrote:
>>>> On 30.06.2013 10:28, Mikel Astiz wrote:
>>>>> Hi Georg,
>>>>>
>>>>> On Sat, Jun 29, 2013 at 9:39 PM, Georg Chini <georg at chini.tk> wrote:
>>>>>> On 28.06.2013 08:23, Mikel Astiz wrote:
>>>>>>> Hi Georg,
>>>>>>>
>>>>>>> On Thu, Jun 27, 2013 at 1:31 PM, Georg Chini <georg at chini.tk> wrote:
>>>>>>>> On 27.06.2013 08:22, Mikel Astiz wrote:
>>>>>>>>> Hi Georg,
>>>>>>>>>
>>>>>>>>> On Wed, Jun 26, 2013 at 8:45 PM, Georg Chini <georg at chini.tk> wrote:
>>>>>>>>>> Hi Mikel,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 26.06.2013 16:54, Mikel Astiz wrote:
>>>>>>>>>>> Hi Georg,
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jun 26, 2013 at 3:27 PM, Georg Chini <georg at chini.tk>
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>> Later on I decided to keep the modules around and just move them
>>>>>>>>>>>> to
>>>>>>>>>>>> the
>>>>>>>>>>>> right
>>>>>>>>>>>> source/sink when needed and move them to the default sound card
>>>>>>>>>>>> and
>>>>>>>>>>>> mute
>>>>>>>>>>>> them when not in use.
>>>>>>>>>>> As a side suggestion, you probably want to use the profile
>>>>>>>>>>> availability to do this (if profile is available, it means
>>>>>>>>>>> 'playing').
>>>>>>>>>>>
>>>>>>>>>>>> The problem is that this does no longer work. Pavucontrol still
>>>>>>>>>>>> shows
>>>>>>>>>>>> the
>>>>>>>>>>>> correct
>>>>>>>>>>>> sink/source but I do not get any sound when the modules are
>>>>>>>>>>>> reused.
>>>>>>>>>>>> It
>>>>>>>>>>>> seems
>>>>>>>>>>>> to be
>>>>>>>>>>>> a problem of resampling, the modules start to behave strangely as
>>>>>>>>>>>> soon
>>>>>>>>>>>> as
>>>>>>>>>>>> sink and
>>>>>>>>>>>> source are moved the first time.
>>>>>>>>>>>> In the debug output I get endless repetition of:
>>>>>>>>>>>>
>>>>>>>>>>>> [alsa-sink-VT1828S Analog] module-loopback.c: Could not peek into
>>>>>>>>>>>> queue
>>>>>>>>>>>> [alsa-sink-VT1828S Analog] module-loopback.c: Requesting rewind
>>>>>>>>>>>> due
>>>>>>>>>>>> to
>>>>>>>>>>>> end
>>>>>>>>>>>> of underrun.
>>>>>>>>>>>> [alsa-sink-VT1828S Analog] module-loopback.c: Requesting rewind
>>>>>>>>>>>> due
>>>>>>>>>>>> to
>>>>>>>>>>>> end
>>>>>>>>>>>> of underrun.
>>>>>>>>>>>> [alsa-sink-VT1828S Analog] module-loopback.c: Requesting rewind
>>>>>>>>>>>> due
>>>>>>>>>>>> to
>>>>>>>>>>>> end
>>>>>>>>>>>> of underrun.
>>>>>>>>>>>> [alsa-sink-VT1828S Analog] module-loopback.c: Requesting rewind
>>>>>>>>>>>> due
>>>>>>>>>>>> to
>>>>>>>>>>>> end
>>>>>>>>>>>> of underrun.
>>>>>>>>>>>>
>>>>>>>>>>>> The initial approach of using fresh modules each time the phone
>>>>>>>>>>>> goes
>>>>>>>>>>>> to
>>>>>>>>>>>> "playing" still
>>>>>>>>>>>> works fine.
>>>>>>>>>>> I think you hit a real issue here. I've experienced similar issues
>>>>>>>>>>> too
>>>>>>>>>>> at some point, but I can't reproduce it anymore.
>>>>>>>>>>>
>>>>>>>>>>> Can you tell us which exact states the source (assuming A2DP from
>>>>>>>>>>> the
>>>>>>>>>>> phone) and the source-output have? They should in theory be both
>>>>>>>>>>> in
>>>>>>>>>>> RUNNING state.
>>>>>>>>>> Sorry, I cannot find out. You can find a log of a complete session
>>>>>>>>>> on
>>>>>>>>>> http://philipp.chini.tk/pulse/pulse-session.log
>>>>>>>>>> Maybe there is something useful in it. If not, please tell me how
>>>>>>>>>> to
>>>>>>>>>> get
>>>>>>>>>> the state of the source or what else I can do to locate the
>>>>>>>>>> problem.
>>>>>>>>> You should use 'pactl list sources' and 'pactl list source-outputs',
>>>>>>>>> during the issue you describe about rewind requests.
>>>>>>>>>
>>>>>>>> All sources and source-outputs are in RUNNING state. The output
>>>>>>>> for the relevant module (now it's A2DP from the phone, so only one
>>>>>>>> module needed) looks like this:
>>>>>>>> index: 6
>>>>>>>> driver: <module-loopback.c>
>>>>>>>> flags: START_CORKED
>>>>>>>> state: RUNNING
>>>>>>> This looks good. Have you checked if the bar in pavucontrol shows some
>>>>>>> audio corresponding to this source?
>>>>>>>
>>>>>>>> source: 2 <alsa_input.pci-0000_00_1b.0.analog-stereo>
>>>>>>>> volume: 0: 100% 1: 100%
>>>>>>>> 0: -0,00 dB 1: -0,00 dB
>>>>>>>> balance 0,00
>>>>>>>> muted: yes
>>>>>>> Is it muted?
>>>>>>>
>>>>>>>> current latency: 0,00 ms
>>>>>>>> requested latency: 135,29 ms
>>>>>>>> sample spec: s16le 2ch 44100Hz
>>>>>>>> channel map: front-left,front-right
>>>>>>>> Stereo
>>>>>>>> resample method: (null)
>>>>>>>> owner module: 27
>>>>>>>> properties:
>>>>>>>> media.role = "abstract"
>>>>>>>> module-stream-restore.id =
>>>>>>>> "source-output-by-media-role:abstract"
>>>>>>>> media.name = "Loopback to Internes Audio Analog
>>>>>>>> Stereo"
>>>>>>>> media.icon_name = "audio-card-pci"
>>>>>>>>
>>>>>>>> Maybe the "resample method: (null)" is the problem?
>>>>>>> No, I don't think the resample method is relevant here. It also shows
>>>>>>> as null for me, and the audio just works.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mikel
>>>>>> Hi Mikel,
>>>>>>
>>>>>> after a bit of testing, I found an easy way to reproduce the problem.
>>>>>> It seems to occur when the phone is in "connected" state and you try
>>>>>> to move the source away from the loopback module. Pacmd shows the
>>>>>> bluetooth source as "SUSPENDED" while the source-output is "RUNNING".
>>>>> This looks perfectly fine to me. The Bluetooth source is no longer in
>>>>> use (you moved away the source-output) and therefore SUSPENDED, as
>>>>> opposed to the source-output which is pulling audio from the alsa card
>>>>> (your sound card, I guess).
>>>>>
>>>>> You should check whether your alsa source is RUNNING. If not, you
>>>>> might have hit an issue. I however think this is completely unrelated
>>>>> to the Bluetooth modules.
>>>>>
>>>>>> Doing the following triggers the problem:
>>>>>>
>>>>>> 1) insert a loopback module with source=your_phone
>>>>>> 2) wait until the phone is no longer playing
>>>>>> 3) with pavucontrol move the source of the loopback module to another
>>>>>> device
>>>>>>
>>>>>> What is strange is that the messages start after the source has already
>>>>>> changed.
>>>>>> I inserted a few log statements in module-loopback.c and got:
>>>>>>
>>>>>> [bluetooth] module-loopback.c: Source Output detach
>>>>>> bluez_source.00_12_D1_8C_FC_80
>>>>>> [pulseaudio] module-loopback.c: Source Output moving to
>>>>>> alsa_input.pci-0000_00_1b.0.analog-stereo
>>>>>> [alsa-source-VT1828S Analog] module-loopback.c: Source Output attach
>>>>>> alsa_input.pci-0000_00_1b.0.analog-stereo
>>>>>> [alsa-sink-USB Audio] module-loopback.c: Requesting rewind due to end
>>>>>> of
>>>>>> underrun.
>>>>>> [alsa-sink-USB Audio] module-loopback.c: Requesting rewind due to end
>>>>>> of
>>>>>> underrun.
>>>>>> ...
>>>>> Have you tried loading module-loopback (regardless of BT devices) with
>>>>> the same sink and source (as resulted from your sequence above, i.e.
>>>>> probably from alsa to alsa) and see if the issue with the rewinds
>>>>> reproduces?
>>>>>
>>>>> Cheers,
>>>>> Mikel
>>>> Hi Mikel,
>>>>
>>>> this only happens with the BT device and only if the phone is not
>>>> playing. I can move the source to another device when the phone
>>>> is playing without any issue. I can also move other source devices
>>>> around without triggering the problem. The BT source is suspended
>>>> even if module-suspend-on-idle is not loaded. Maybe the problem is
>>> If the phone is streaming no audio the source will be suspended
>>> regardless of module-suspend-on-idle. If you have a closer look,
>>> you'll see that the suspend cause is USER.
>>>
>>>> that when the phone goes inactive the effective profile is "off" and not
>>>> the one that was last used. The issue is also triggered if I load the
>>>> loopback module for a2dp_source, wait until the phone is inactive
>>>> and then switch to hfgw.
>>> Can you describe again the actual issue you're having? I'd like to
>>> distinguish whether there's some inconsistent state in PA or not.
>>
>> See below.
>>
>>
>>> If I get this right, you switch the profile to hfgw and move the
>>> source-output to the corresponding source. At this point, the question
>>> is whether hfgw is actually streaming audio or not. If yes, BlueZ
>>> should be in 'playing' state and PA should expose the profile as
>>> 'available: yes' (use pacmd to check this). The source should be
>>> RUNNING and the source-output too. Besides, you should see the audio
>>> bars moving in pavucontrol for the hfgw source and also in the
>>> playback tab (show: "All stream").
>>
>> Yes, all of this is the case. The problem occurs AFTER the phone goes
>> from playing to connected.
>>
>> In my script, I do the following:
>> Initially, there is no loopback module loaded. When the phone goes
>> to "playing" (regardless if it is a2dp_source or hfgw) I insert loopback
>> modules. If it is hfgw one from my microphone to the phone and one
>> from the phone to my sound output, if it is a2dp_source only one from
>> the phone to my sound output.
>> When the phone switches back to "connected" instead of unloading
>> the module(s) I move them to my default sink and source and mute the
>> source-output so that I do not hear the microphone on my sound output.
>> When the phone goes to "playing" again I reuse the loopback modules,
>> unmuting them and moving them back to the BT source/sink.
>> I keep different modules around for a2dp and hfgw, so when a phone
>> is able to do both and both have been playing at some time, then I have
>> 3 modules loaded. This worked fine with Pulseaudio 2.0.
>> With 4.0 the problem occurs at the moment the modules are moved away
>> from the BT source.
>>
>> To make sure the issue is not triggered by my script I tried to reproduce
>> it without any additional software. That is what I described a few mails
>> ago.
>> You get the phone to "playing" and then insert the loopback module manually
>> using pactl. This works fine, you can hear the sound. Then wait until the
>> phone goes back to "connected" state. If you now reconnect the same profile,
>> sound is still audible.
>> But if you move the source after the phone played and is back to connected
>> (again, manually with pavucontrol) the issue will start. So to trigger the
>> problem,
>> the following conditions must be met:
>>
>> - While the phone is playing (it doesn't matter if it is a2dp_source or
>> hfgw),
>> a loopback module with the phone as source is inserted
>> - The phone goes back to "connected" and the source-output of the loopback
>> module is still connected to the (now suspended) BT source
>> - In this situation you move the source away from the source-output of the
>> loopback module
>>
>> The exact symptom is that the loopback module is unusable from that moment
>> on
>> (no sound, regardless which sink/source you choose) and with debug logging
>> the
>> rewind messages can be seen and continue until the module is unloaded.
> I was able to reproduce this issue and submitted a patch to fix it: "
> loopback: Fix cork state not updated after move".
>
> Please check if this patch solves your problem.
Hi Mikel,
yes, the patch fixes the problem! Thanks a lot for your help and patience.
Regards
Georg
> Cheers,
> Mikel
More information about the pulseaudio-discuss
mailing list