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
