On Mon, 2016-02-01 at 09:06 +0000, Samiran Sarkar wrote: > root at baytrail32:~# journalctl -u pulseaudio > -- Logs begin at Sun 2012-01-01 00:00:34 UTC, end at Thu 2015-12-10 10:16:46 UTC. -- > Dec 10 10:09:45 baytrail32 pulseaudio[312]: E: [pulseaudio] main.c: Sink alsa_output.usb-Jabra_Jabra_UC_VOICE_150_duo_000000000000- > Dec 10 10:09:45 baytrail32 pulseaudio[312]: E: [pulseaudio] main.c: Source alsa_input.usb-Jabra_Jabra_UC_VOICE_150_duo_000000000000 > Dec 10 10:10:18 baytrail32 pulseaudio[312]: E: [pulseaudio] backend-ofono.c: Deferred setup failed on fd -1: Transport endpoint is > Dec 10 10:15:52 baytrail32 pulseaudio[312]: E: [pulseaudio] backend-ofono.c: Deferred setup failed on fd -1: Transport endpoint is > Dec 10 10:16:30 baytrail32 systemd[1]: pulseaudio.service: main process exited, code=killed, status=11/SEGV Segfaulting is never good... > Dec 10 10:16:30 baytrail32 systemd[1]: Unit pulseaudio.service entered failed state. > Dec 10 10:16:36 baytrail32 pulseaudio[362]: E: [pulseaudio] main.c: Sink alsa_output.usb-Jabra_Jabra_UC_VOICE_150_duo_000000000000- > Dec 10 10:16:36 baytrail32 pulseaudio[362]: E: [pulseaudio] main.c: Source alsa_input.usb-Jabra_Jabra_UC_VOICE_150_duo_000000000000 > Dec 10 10:16:36 baytrail32 pulseaudio[362]: E: [pulseaudio] backend-ofono.c: Deferred setup failed on fd -1: Transport endpoint is > > > #pactl list modules > > Module #23 >         Name: module-bluez5-device >         Argument: path=/org/bluez/hci0/dev_F8_32_E4_FB_FD_28 >         Usage counter: 2 >         Properties: >                 module.author = "João Paulo Rechi Vita" >                 module.description = "BlueZ 5 Bluetooth audio sink and source" >                 module.version = "6.0-dirty" > > Module #24 >         Name: module-loopback >         Argument: sink="bluez_sink.F8_32_E4_FB_FD_28" sink_dont_move="true" source_output_properties="media.role=phone" >         Usage counter: n/a >         Properties: >                 module.author = "Pierre-Louis Bossart" >                 module.description = "Loopback from source to sink" >                 module.version = "6.0-dirty" > > Module #25 >         Name: module-loopback >         Argument: source="bluez_source.F8_32_E4_FB_FD_28" source_dont_move="true" sink_input_properties="media.role=phone" >         Usage counter: n/a >         Properties: >                 module.author = "Pierre-Louis Bossart" >                 module.description = "Loopback from source to sink" >                 module.version = "6.0-dirty" > > --------------------------------------------------------------------- > ------------------------------------------------------------------- > ------------------------------------------------------------------- > ------- > This( Above) is the normal condition -- if I make a call I can't > transfer my Smart Phone voice to Bluetooth Device/ By the "Bluetooth Device", do you mean the device that is running PulseAudio? I'm assuming that the setup is a device running PulseAudio with alsa input and output, connected to a phone via Bluetooth. "pactl list modules" doesn't show how audio is routed. "pactl list sink-inputs" and "pactl list source-outputs" will show what streams exist in the system. For each stream the listing includes the module that created the stream and the device that the stream is connected to. Based on that information you can figure out the real connections that the loopback modules are making between devices. > then if I do loopback it allows to transfer Voice from Phone > to Bluetooth device ( no sound at Phone , making sure that > Conversation has transferred to BT Device) Since you already have the two loopbacks loaded by module-bluetooth- policy, you shouldn't need to load any additional loopbacks. > #pacmd load-module module-loopback source=bluez_source.F8_32_E4_FB_FD_28 sink=alsa_output.usb-Jabra_Jabra_UC_VOICE_150_duo_000000000000-00-duo.analog-stereo > > again whatever I 'm speaking over MIC I 'm able to listen in > headphone Speaker. But Voice conversation is missing which supposed > to get via Bluetooth Is "MIC" the alsa source and "headphone Speaker" the alsa sink? If so, I don't know why the loopback module that you loaded manually would cause such connection. The only reason I can think of is that something moves the source output of the loopback to the alsa source. Hence I suggested using the "source_dont_move" parameter. But as I said, loading module-loopback manually should not be done if you're trying to use module-bluetooth-policy to manage the loopbacks. -- Tanu
