Hi again,
On 30.06.2013 12:57, Mikel Astiz wrote:
Hi Georg,
On Sun, Jun 30, 2013 at 11:00 AM, Georg Chini <[email protected]> wrote:
On 30.06.2013 10:28, Mikel Astiz wrote:
Hi Georg,
On Sat, Jun 29, 2013 at 9:39 PM, Georg Chini <[email protected]> wrote:
On 28.06.2013 08:23, Mikel Astiz wrote:
Hi Georg,
On Thu, Jun 27, 2013 at 1:31 PM, Georg Chini <[email protected]> wrote:
On 27.06.2013 08:22, Mikel Astiz wrote:
Hi Georg,
On Wed, Jun 26, 2013 at 8:45 PM, Georg Chini <[email protected]> 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 <[email protected]> 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 guess the issue is, that the source is invalid at that point. When the
phone
goes to "connected" the corresponding source and sink do no longer exist.
Now you try to move a source that seems to be there but isn't really valid.
You cannot - for example - move the source from "SUSPENDED" to "RUNNING"
because the connection can only be initiated from the phone end. Maybe
some part of the software tries to read from that source when it moves
and never receives data.
I'd also question why the source output is muted. You obviously won't
get any audio if you mute the stream.
See above.
Cheers,
Mikel
Regards
Georg
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
