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. 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"). I'd also question why the source output is muted. You obviously won't get any audio if you mute the stream. Cheers, Mikel
