diff for duplicates of <4B6A3D25.2040508@intel.com> diff --git a/a/1.txt b/N1/1.txt index 339d8cc..22e1de2 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,63 +1,73 @@ -SGkgSnBydml0YSwKCk9uIDAyLzA0LzIwMTAgMDI6MzAgQU0sIEpvw6NvIFBhdWxvIFJlY2hpIFZp -dGEgd3JvdGU6Cj4+Pgo+Pj4gSnVzdCB1cGRhdGluZywgdGhpcyBwYXRjaCBhY3R1YWxseSB3b3Jr -ZWQgd2hlbiB0ZXN0aW5nIHdpdGggYQo+Pj4gZGlmZmVyZW50IGFkYXB0ZXIgKEZ1aml0c3UtU2ll -bWVucyBDU1ItYmFzZWQpLiBUaGUgYWRhcHRlciBjYXVzaW5nCj4+PiBwcm9ibGVtcyB3YXMgYSBC -cm9hZGNvbSAyLjEsIHRoZSBpbnRlcm5hbCBhZGFwdGVyIG9mIGEgRGVsbCBNaW5pMTAuCj4+PiBB -bHNvLCBzdXNwZW5kaW5nIHRoZSBzb3VyY2UgLyBzaW5rIGFjdHVhbGx5IGRvZXNuJ3QgaW50ZXJm -ZXJlLgo+Pj4KPj4+IEkgZGlkIGEgc21hbGwgdmlkZW8gb2YgdGhlIHdob2xlIHN0dWZmOiBodHRw -Oi8vd3d3LnZpbWVvLmNvbS85MDc4Nzk5Cj4+Pgo+Pj4gVGhlcmUgYXJlIHN0aWxsIHNvbWUgcHJv -YmxlbXMgd2hlbiB0ZXN0aW5nIGFnYWluc3QgTm9raWEgTjkwMCBhbmQKPj4+IDI2NjAuIEFmdGVy -IHRoZSAiZW5hYmxlLW1vZGVtIiBzdGVwLCB0aGUgUkZDT01NIGxpbmsgaXMgY29ubmVjdGVkIGFu -ZAo+Pj4gdGhlIFNDTyBqdXN0IGFmdGVyIHRoYXQsIGxlYWRpbmcgbW9kdWxlLWJsdWV0b290aC1k -aXNjb3ZlciB0byBsb2FkCj4+PiBtb2R1bGUtYmx1ZXRvb3RoLWRldmljZS4gU29tZXRpbWVzIGFm -dGVyIHRoYXQgdGhlIHBvbGxpbmcgb24gdGhlCj4+PiBzdHJlYW0gZmQgZ2V0IGEgUE9MTEhVUCBh -bmQgdGhlIG1vZHVsZS1ibHVldG9vdGgtZGV2aWNlIHVubG9hZHMKPj4+IGl0c2VsZi4gT3RoZXIg -dGltZXMgdGhlIFBPTExIVVAgZG9lc24ndCBoYXBwZW4gYW5kIHRoZSByZW1haW5pbmcgc3RlcHMK -Pj4+IGdvIHdpdGhvdXQgYW55IHByb2JsZW0uCj4+Pgo+Pj4gSWRlYXMgb24gaG93IHRvIGltcHJv -dmUgdGhpcyBzY2VuYXJpbyB3aWxsIGJlIHZlcnkgaGVscGZ1bC4KPj4+Cj4+Pgo+Pgo+PiBUaGUg -b3V0cHV0IGZyb20gYmx1ZXRvb3RoZCBsaWtlcyBiZWxvdzoKPj4KPj4gYmx1ZXRvb3RoZFsyMTE0 -MV06IEFjY2VwdGVkIEFHIGNvbm5lY3Rpb24gZnJvbSAwMDpCRDozQTpENDo0RTo1MyBmb3IKPj4g -L29yZy9ibHVlei8yMTE0MS9oY2kwL2Rldl8wMF9CRF8zQV9ENF80RV81Mwo+PiBibHVldG9vdGhk -WzIxMTQxXTogQWNjZXB0ZWQgU0NPIGNvbm5lY3Rpb24gZnJvbSAwMDpCRDozQTpENDo0RTo1Mwo+ -PiBibHVldG9vdGhkWzIxMTQxXTogTm8gbWF0Y2hpbmcgY29ubmVjdGlvbiBmb3VuZCBmb3IgaGFu -ZGxlIDYKPj4gYmx1ZXRvb3RoZFsyMTE0MV06IHNjbyBjb25uZWN0aW9uIGlzIHJlbGVhc2VkCj4+ -Cj4+IEkgdGhpbmsgeW91IHNob3VsZCBub3QgbG9hZCBtb2R1bGUtYmx1ZXRvb3RoLWRldmljZSB1 -bnRpbCBhIHZvaWNlIGNhbGwgaXMKPj4gc3RhcnRlZCwgbm8gbWF0dGVyIGluY29taW5nIG9yIG91 -dGdvaW5nLiBCZWNhdXNlIFBBIG1heSBwbGF5IG11c2ljIGZyb20KPj4gb3RoZXIgZGV2aWNlIGF0 -IHRoZSBzYW1lIHRpbWUuIEFuZCBibHVldG9vdGgtZGV2aWNlIGFuZCBsb29wYmFjayBtb2R1bGUg -YXJlCj4+IGxvYWRlZCB0b2dldGhlci4gQWNjb3JkaW5nIHRvIEhGUCB2MS41IDQuMTMsIHRoZXJl -IGFyZSB0d28gY2FzZXMgZm9yCj4+IGluY29taW5nIGNhbGwuIEFuZCBvdXRnb2luZyBjYWxsIGlz -IHNpbXBsZXIgdGhhbiBpbmNvbWluZyBjYWxsLgo+Pgo+PiBJZiBBRyBhbmQgSEYgYm90aCBzdXBw -b3J0IGluIGJhbmQgcmluZyB0b25lcywgd2Ugc2hvdWxkIHNlbmQgYSBzaWduYWwgZnJvbQo+PiBv -Rm9ubyB0byBQQSB3aGVuIGNhbGxzZXR1cD0xLiBJZiBub3QsIHdlIHNob3VsZCBzZW5kIGl0IHdo -ZW4gY2FsbD0xLgo+Pgo+PiBJIGhhZCBhIHBhdGNoIG9yaWdpbmFsbHkgYnV0IEkgY2Fubm90IGZp -bmQgaXQgbm93LiA6LSguIFRoZSBiYXNpYyBpZGVhIGlzIHRvCj4+IGFkZCBhIGZpbHRlciBpbiBj -aWV2X25vdGlmeSgpIHRvIGVtaXQgc2lnbmFsIChDYWxsU3RhcnRlZCBhbmQgQ2FsbEVuZGVkKSB0 -bwo+PiBQQS4gQW5kIFBBIGxvYWRzIG1vZHVsZSBvbmNlIGl0IGdvdCB0aGF0IHNpZ25hbC4gTWF5 -YmUgdGhlIHNpZ25hbCBuYW1lIHdhcwo+PiBiYWQgYW5kIHlvdSBjb3VsZCBjaG9vc2UgYmV0dGVy -IG9uZSBhcyB5b3Ugd2FudC4gOy0pCj4+Cj4KPiBJIHRoaW5rIGxvYWRpbmcgbW9kdWxlLWJsdWV0 -b290aC1kZXZpY2Ugb25seSB3aGVuIHRoZXJlIGlzIGFuIGFjdGl2ZQo+IGNhbGwgY2FuIGJlIGEg -Z29vZCBzb2x1dGlvbi4gQnV0IEknbSBjb25jZXJuZWQgYWJvdXQgb3RoZXIgYXVkaW8KPiBldmVu -dHMsIGkuIGUuOiByaW5naW5nLCBTTVMgbm90aWZpY2F0aW9uIGV0Yy46IGRvZXNuJ3QgdGhlIEFH -Cj4gZXN0YWJsaXNoZXMgYSBTQ08gY2hhbm5lbCBmb3IgdGhlIHRoZXNlIGV2ZW50cz8gQWxzbywg -SSBkb24ndCB0aGluawo+IHB1bHNlIHNob3VsZCBsaXN0ZW4gdG8gb2Zvbm8gc2lnbmFscywgaXQg -c2hvdWxkIGJlIGFnZW50LWFnbm9zdGljLiBCdXQKPiBhIHNpZ25hbCBjb3VsZCBiZSBhZGRlZCB0 -byB0aGUgYWdlbnQgaW50ZXJmYWNlIGluIHRoaXMgY2FzZS4KClllYWguIE1heWJlIHlvdSBhcmUg -cmlnaHQuIFBBIHNob3VsZCBub3QgbGlzdGVuIHRvIG9mb25vIHNpZ25hbCBkaXJlY3RseSAKYnV0 -IHRocm91Z2ggYW4gYWdlbnQgc2lnbmFsIHRvIG1ha2UgaXQgbW9yZSBnZW5lcmljLiBBRkFLLCBT -TVMgCm5vdGlmaWNhdGlvbiBkb2Vzbid0IHJlcXVpcmUgU0NPLiBVcHBlciBhcHAgY291bGQgc2lt -cGx5IHdhdGNoIHRoZSAKcHJvcGVydHkgY2hhbmdlcyBmcm9tIG9Gb25vLgoKPiBBbmQgSSdtIG5v -dCBzdXJlIGlmIGF1dG9tYXRpY2FsbHkgbG9hZGluZyBtb2R1bGUtbG9vcGJhY2sgaXMgYSBnb29k -Cj4gaWRlYSwgSSB0aGluayB3ZSBiZXR0ZXIgZXhwb3NlIHRocm91Z2ggdGhlIFVJIGhvdyB0byBo -YW5kbGUgdGhlIGF1ZGlvCj4gc3RyZWFtLiBTb21lIHVzZXJzIG1heSBoYXZlIGEgYnVuY2ggb2Yg -c291bmRjYXJkcyBvciBzb21lIHZlcnkgd2VpcmQKPiBhdWRpbyBzZXR1cCwgYW5kIGl0J3MgdXAg -dG8gdGhlbSB0byBkZWNpZGUgd2hpY2ggc291bmRjYXJkIHRvIGNvbm5lY3QKPiB0aGUgSEZQIHN0 -cmVhbS4KPgoKSSBhbSBub3QgYXVkaW8gZXhwZXJ0IGJ1dCBBRkFLIFBBIGhhcyB2YXJpYW50IHBv -bGljaWVzIHRvIGNvbnRyb2wgd2hpY2ggCmF1ZGlvIHN0cmVhbSBzaG91bGQgYmUgZmVlZGVkIGlu -dG8gdGhlIHNwZWFrZXIvbWljLiBMb2FkaW5nIAptb2R1bGUtYmx1ZXRvb3RoLWRldmljZSBpcyBv -bmx5IHRoZSAxc3Qgc3RlcCB0byBjcmVhdGUgc291cmNlL3NpbmsuIEkgCnRoaW5rIHRoZSB2b2lj -ZWNhbGwgaGF2ZSB0aGUgaGlnaGVyIHByaW9yaXR5IHRoYW4gb3RoZXIgc3RlYW0gbGlrZSAKbXVz -aWMsIGV0Yy4gQW5kIHllcywgbG9hZGluZyBtb2R1bGUtbG9vcGJhY2sgY291bGQgYmUgZGVjaWRl -ZCBieSBQQSBwb2xpY3kuCgpUaGFua3MuClpoZW5odWEuCgpfX19fX19fX19fX19fX19fX19fX19f -X19fX19fX19fX19fX19fX19fX19fX19fXwpvZm9ubyBtYWlsaW5nIGxpc3QKb2Zvbm9Ab2Zvbm8u -b3JnCmh0dHA6Ly9saXN0cy5vZm9uby5vcmcvbGlzdGluZm8vb2Zvbm8K +Hi Jprvita, + +On 02/04/2010 02:30 AM, João Paulo Rechi Vita wrote: +>>> +>>> Just updating, this patch actually worked when testing with a +>>> different adapter (Fujitsu-Siemens CSR-based). The adapter causing +>>> problems was a Broadcom 2.1, the internal adapter of a Dell Mini10. +>>> Also, suspending the source / sink actually doesn't interfere. +>>> +>>> I did a small video of the whole stuff: http://www.vimeo.com/9078799 +>>> +>>> There are still some problems when testing against Nokia N900 and +>>> 2660. After the "enable-modem" step, the RFCOMM link is connected and +>>> the SCO just after that, leading module-bluetooth-discover to load +>>> module-bluetooth-device. Sometimes after that the polling on the +>>> stream fd get a POLLHUP and the module-bluetooth-device unloads +>>> itself. Other times the POLLHUP doesn't happen and the remaining steps +>>> go without any problem. +>>> +>>> Ideas on how to improve this scenario will be very helpful. +>>> +>>> +>> +>> The output from bluetoothd likes below: +>> +>> bluetoothd[21141]: Accepted AG connection from 00:BD:3A:D4:4E:53 for +>> /org/bluez/21141/hci0/dev_00_BD_3A_D4_4E_53 +>> bluetoothd[21141]: Accepted SCO connection from 00:BD:3A:D4:4E:53 +>> bluetoothd[21141]: No matching connection found for handle 6 +>> bluetoothd[21141]: sco connection is released +>> +>> I think you should not load module-bluetooth-device until a voice call is +>> started, no matter incoming or outgoing. Because PA may play music from +>> other device at the same time. And bluetooth-device and loopback module are +>> loaded together. According to HFP v1.5 4.13, there are two cases for +>> incoming call. And outgoing call is simpler than incoming call. +>> +>> If AG and HF both support in band ring tones, we should send a signal from +>> oFono to PA when callsetup=1. If not, we should send it when call=1. +>> +>> I had a patch originally but I cannot find it now. :-(. The basic idea is to +>> add a filter in ciev_notify() to emit signal (CallStarted and CallEnded) to +>> PA. And PA loads module once it got that signal. Maybe the signal name was +>> bad and you could choose better one as you want. ;-) +>> +> +> I think loading module-bluetooth-device only when there is an active +> call can be a good solution. But I'm concerned about other audio +> events, i. e.: ringing, SMS notification etc.: doesn't the AG +> establishes a SCO channel for the these events? Also, I don't think +> pulse should listen to ofono signals, it should be agent-agnostic. But +> a signal could be added to the agent interface in this case. + +Yeah. Maybe you are right. PA should not listen to ofono signal directly +but through an agent signal to make it more generic. AFAK, SMS +notification doesn't require SCO. Upper app could simply watch the +property changes from oFono. + +> And I'm not sure if automatically loading module-loopback is a good +> idea, I think we better expose through the UI how to handle the audio +> stream. Some users may have a bunch of soundcards or some very weird +> audio setup, and it's up to them to decide which soundcard to connect +> the HFP stream. +> + +I am not audio expert but AFAK PA has variant policies to control which +audio stream should be feeded into the speaker/mic. Loading +module-bluetooth-device is only the 1st step to create source/sink. I +think the voicecall have the higher priority than other steam like +music, etc. And yes, loading module-loopback could be decided by PA policy. + +Thanks. +Zhenhua. diff --git a/a/content_digest b/N1/content_digest index 25b2990..2b597aa 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,77 +1,82 @@ - "ref\01264776266-7646-1-git-send-email-jprvita@gmail.com\0" - "ref\0aa32413d1002010909h1ba06e13n1511d56903406945@mail.gmail.com\0" - "ref\04B67A102.6090304@intel.com\0" "ref\0aa32413d1002031030s446edef6gea3d234bc440c170@mail.gmail.com\0" "From\0Zhenhua Zhang <zhenhua.zhang@intel.com>\0" "Subject\0Re: [RFC] [PATCH 0/2] HFP AG integration with PulseAudio\0" "Date\0Thu, 04 Feb 2010 11:21:09 +0800\0" - "To\0Jo\303\243o Paulo Rechi Vita <jprvita@gmail.com>\0" - "Cc\0linux-bluetooth@vger.kernel.org <linux-bluetooth@vger.kernel.org>" - " ofono@ofono.org <ofono@ofono.org>\0" - "\00:1\0" + "To\0ofono@ofono.org\0" + "\01:1\0" "b\0" - "SGkgSnBydml0YSwKCk9uIDAyLzA0LzIwMTAgMDI6MzAgQU0sIEpvw6NvIFBhdWxvIFJlY2hpIFZp\n" - "dGEgd3JvdGU6Cj4+Pgo+Pj4gSnVzdCB1cGRhdGluZywgdGhpcyBwYXRjaCBhY3R1YWxseSB3b3Jr\n" - "ZWQgd2hlbiB0ZXN0aW5nIHdpdGggYQo+Pj4gZGlmZmVyZW50IGFkYXB0ZXIgKEZ1aml0c3UtU2ll\n" - "bWVucyBDU1ItYmFzZWQpLiBUaGUgYWRhcHRlciBjYXVzaW5nCj4+PiBwcm9ibGVtcyB3YXMgYSBC\n" - "cm9hZGNvbSAyLjEsIHRoZSBpbnRlcm5hbCBhZGFwdGVyIG9mIGEgRGVsbCBNaW5pMTAuCj4+PiBB\n" - "bHNvLCBzdXNwZW5kaW5nIHRoZSBzb3VyY2UgLyBzaW5rIGFjdHVhbGx5IGRvZXNuJ3QgaW50ZXJm\n" - "ZXJlLgo+Pj4KPj4+IEkgZGlkIGEgc21hbGwgdmlkZW8gb2YgdGhlIHdob2xlIHN0dWZmOiBodHRw\n" - "Oi8vd3d3LnZpbWVvLmNvbS85MDc4Nzk5Cj4+Pgo+Pj4gVGhlcmUgYXJlIHN0aWxsIHNvbWUgcHJv\n" - "YmxlbXMgd2hlbiB0ZXN0aW5nIGFnYWluc3QgTm9raWEgTjkwMCBhbmQKPj4+IDI2NjAuIEFmdGVy\n" - "IHRoZSAiZW5hYmxlLW1vZGVtIiBzdGVwLCB0aGUgUkZDT01NIGxpbmsgaXMgY29ubmVjdGVkIGFu\n" - "ZAo+Pj4gdGhlIFNDTyBqdXN0IGFmdGVyIHRoYXQsIGxlYWRpbmcgbW9kdWxlLWJsdWV0b290aC1k\n" - "aXNjb3ZlciB0byBsb2FkCj4+PiBtb2R1bGUtYmx1ZXRvb3RoLWRldmljZS4gU29tZXRpbWVzIGFm\n" - "dGVyIHRoYXQgdGhlIHBvbGxpbmcgb24gdGhlCj4+PiBzdHJlYW0gZmQgZ2V0IGEgUE9MTEhVUCBh\n" - "bmQgdGhlIG1vZHVsZS1ibHVldG9vdGgtZGV2aWNlIHVubG9hZHMKPj4+IGl0c2VsZi4gT3RoZXIg\n" - "dGltZXMgdGhlIFBPTExIVVAgZG9lc24ndCBoYXBwZW4gYW5kIHRoZSByZW1haW5pbmcgc3RlcHMK\n" - "Pj4+IGdvIHdpdGhvdXQgYW55IHByb2JsZW0uCj4+Pgo+Pj4gSWRlYXMgb24gaG93IHRvIGltcHJv\n" - "dmUgdGhpcyBzY2VuYXJpbyB3aWxsIGJlIHZlcnkgaGVscGZ1bC4KPj4+Cj4+Pgo+Pgo+PiBUaGUg\n" - "b3V0cHV0IGZyb20gYmx1ZXRvb3RoZCBsaWtlcyBiZWxvdzoKPj4KPj4gYmx1ZXRvb3RoZFsyMTE0\n" - "MV06IEFjY2VwdGVkIEFHIGNvbm5lY3Rpb24gZnJvbSAwMDpCRDozQTpENDo0RTo1MyBmb3IKPj4g\n" - "L29yZy9ibHVlei8yMTE0MS9oY2kwL2Rldl8wMF9CRF8zQV9ENF80RV81Mwo+PiBibHVldG9vdGhk\n" - "WzIxMTQxXTogQWNjZXB0ZWQgU0NPIGNvbm5lY3Rpb24gZnJvbSAwMDpCRDozQTpENDo0RTo1Mwo+\n" - "PiBibHVldG9vdGhkWzIxMTQxXTogTm8gbWF0Y2hpbmcgY29ubmVjdGlvbiBmb3VuZCBmb3IgaGFu\n" - "ZGxlIDYKPj4gYmx1ZXRvb3RoZFsyMTE0MV06IHNjbyBjb25uZWN0aW9uIGlzIHJlbGVhc2VkCj4+\n" - "Cj4+IEkgdGhpbmsgeW91IHNob3VsZCBub3QgbG9hZCBtb2R1bGUtYmx1ZXRvb3RoLWRldmljZSB1\n" - "bnRpbCBhIHZvaWNlIGNhbGwgaXMKPj4gc3RhcnRlZCwgbm8gbWF0dGVyIGluY29taW5nIG9yIG91\n" - "dGdvaW5nLiBCZWNhdXNlIFBBIG1heSBwbGF5IG11c2ljIGZyb20KPj4gb3RoZXIgZGV2aWNlIGF0\n" - "IHRoZSBzYW1lIHRpbWUuIEFuZCBibHVldG9vdGgtZGV2aWNlIGFuZCBsb29wYmFjayBtb2R1bGUg\n" - "YXJlCj4+IGxvYWRlZCB0b2dldGhlci4gQWNjb3JkaW5nIHRvIEhGUCB2MS41IDQuMTMsIHRoZXJl\n" - "IGFyZSB0d28gY2FzZXMgZm9yCj4+IGluY29taW5nIGNhbGwuIEFuZCBvdXRnb2luZyBjYWxsIGlz\n" - "IHNpbXBsZXIgdGhhbiBpbmNvbWluZyBjYWxsLgo+Pgo+PiBJZiBBRyBhbmQgSEYgYm90aCBzdXBw\n" - "b3J0IGluIGJhbmQgcmluZyB0b25lcywgd2Ugc2hvdWxkIHNlbmQgYSBzaWduYWwgZnJvbQo+PiBv\n" - "Rm9ubyB0byBQQSB3aGVuIGNhbGxzZXR1cD0xLiBJZiBub3QsIHdlIHNob3VsZCBzZW5kIGl0IHdo\n" - "ZW4gY2FsbD0xLgo+Pgo+PiBJIGhhZCBhIHBhdGNoIG9yaWdpbmFsbHkgYnV0IEkgY2Fubm90IGZp\n" - "bmQgaXQgbm93LiA6LSguIFRoZSBiYXNpYyBpZGVhIGlzIHRvCj4+IGFkZCBhIGZpbHRlciBpbiBj\n" - "aWV2X25vdGlmeSgpIHRvIGVtaXQgc2lnbmFsIChDYWxsU3RhcnRlZCBhbmQgQ2FsbEVuZGVkKSB0\n" - "bwo+PiBQQS4gQW5kIFBBIGxvYWRzIG1vZHVsZSBvbmNlIGl0IGdvdCB0aGF0IHNpZ25hbC4gTWF5\n" - "YmUgdGhlIHNpZ25hbCBuYW1lIHdhcwo+PiBiYWQgYW5kIHlvdSBjb3VsZCBjaG9vc2UgYmV0dGVy\n" - "IG9uZSBhcyB5b3Ugd2FudC4gOy0pCj4+Cj4KPiBJIHRoaW5rIGxvYWRpbmcgbW9kdWxlLWJsdWV0\n" - "b290aC1kZXZpY2Ugb25seSB3aGVuIHRoZXJlIGlzIGFuIGFjdGl2ZQo+IGNhbGwgY2FuIGJlIGEg\n" - "Z29vZCBzb2x1dGlvbi4gQnV0IEknbSBjb25jZXJuZWQgYWJvdXQgb3RoZXIgYXVkaW8KPiBldmVu\n" - "dHMsIGkuIGUuOiByaW5naW5nLCBTTVMgbm90aWZpY2F0aW9uIGV0Yy46IGRvZXNuJ3QgdGhlIEFH\n" - "Cj4gZXN0YWJsaXNoZXMgYSBTQ08gY2hhbm5lbCBmb3IgdGhlIHRoZXNlIGV2ZW50cz8gQWxzbywg\n" - "SSBkb24ndCB0aGluawo+IHB1bHNlIHNob3VsZCBsaXN0ZW4gdG8gb2Zvbm8gc2lnbmFscywgaXQg\n" - "c2hvdWxkIGJlIGFnZW50LWFnbm9zdGljLiBCdXQKPiBhIHNpZ25hbCBjb3VsZCBiZSBhZGRlZCB0\n" - "byB0aGUgYWdlbnQgaW50ZXJmYWNlIGluIHRoaXMgY2FzZS4KClllYWguIE1heWJlIHlvdSBhcmUg\n" - "cmlnaHQuIFBBIHNob3VsZCBub3QgbGlzdGVuIHRvIG9mb25vIHNpZ25hbCBkaXJlY3RseSAKYnV0\n" - "IHRocm91Z2ggYW4gYWdlbnQgc2lnbmFsIHRvIG1ha2UgaXQgbW9yZSBnZW5lcmljLiBBRkFLLCBT\n" - "TVMgCm5vdGlmaWNhdGlvbiBkb2Vzbid0IHJlcXVpcmUgU0NPLiBVcHBlciBhcHAgY291bGQgc2lt\n" - "cGx5IHdhdGNoIHRoZSAKcHJvcGVydHkgY2hhbmdlcyBmcm9tIG9Gb25vLgoKPiBBbmQgSSdtIG5v\n" - "dCBzdXJlIGlmIGF1dG9tYXRpY2FsbHkgbG9hZGluZyBtb2R1bGUtbG9vcGJhY2sgaXMgYSBnb29k\n" - "Cj4gaWRlYSwgSSB0aGluayB3ZSBiZXR0ZXIgZXhwb3NlIHRocm91Z2ggdGhlIFVJIGhvdyB0byBo\n" - "YW5kbGUgdGhlIGF1ZGlvCj4gc3RyZWFtLiBTb21lIHVzZXJzIG1heSBoYXZlIGEgYnVuY2ggb2Yg\n" - "c291bmRjYXJkcyBvciBzb21lIHZlcnkgd2VpcmQKPiBhdWRpbyBzZXR1cCwgYW5kIGl0J3MgdXAg\n" - "dG8gdGhlbSB0byBkZWNpZGUgd2hpY2ggc291bmRjYXJkIHRvIGNvbm5lY3QKPiB0aGUgSEZQIHN0\n" - "cmVhbS4KPgoKSSBhbSBub3QgYXVkaW8gZXhwZXJ0IGJ1dCBBRkFLIFBBIGhhcyB2YXJpYW50IHBv\n" - "bGljaWVzIHRvIGNvbnRyb2wgd2hpY2ggCmF1ZGlvIHN0cmVhbSBzaG91bGQgYmUgZmVlZGVkIGlu\n" - "dG8gdGhlIHNwZWFrZXIvbWljLiBMb2FkaW5nIAptb2R1bGUtYmx1ZXRvb3RoLWRldmljZSBpcyBv\n" - "bmx5IHRoZSAxc3Qgc3RlcCB0byBjcmVhdGUgc291cmNlL3NpbmsuIEkgCnRoaW5rIHRoZSB2b2lj\n" - "ZWNhbGwgaGF2ZSB0aGUgaGlnaGVyIHByaW9yaXR5IHRoYW4gb3RoZXIgc3RlYW0gbGlrZSAKbXVz\n" - "aWMsIGV0Yy4gQW5kIHllcywgbG9hZGluZyBtb2R1bGUtbG9vcGJhY2sgY291bGQgYmUgZGVjaWRl\n" - "ZCBieSBQQSBwb2xpY3kuCgpUaGFua3MuClpoZW5odWEuCgpfX19fX19fX19fX19fX19fX19fX19f\n" - "X19fX19fX19fX19fX19fX19fX19fX19fXwpvZm9ubyBtYWlsaW5nIGxpc3QKb2Zvbm9Ab2Zvbm8u\n" - b3JnCmh0dHA6Ly9saXN0cy5vZm9uby5vcmcvbGlzdGluZm8vb2Zvbm8K + "Hi Jprvita,\n" + "\n" + "On 02/04/2010 02:30 AM, Jo\303\243o Paulo Rechi Vita wrote:\n" + ">>>\n" + ">>> Just updating, this patch actually worked when testing with a\n" + ">>> different adapter (Fujitsu-Siemens CSR-based). The adapter causing\n" + ">>> problems was a Broadcom 2.1, the internal adapter of a Dell Mini10.\n" + ">>> Also, suspending the source / sink actually doesn't interfere.\n" + ">>>\n" + ">>> I did a small video of the whole stuff: http://www.vimeo.com/9078799\n" + ">>>\n" + ">>> There are still some problems when testing against Nokia N900 and\n" + ">>> 2660. After the \"enable-modem\" step, the RFCOMM link is connected and\n" + ">>> the SCO just after that, leading module-bluetooth-discover to load\n" + ">>> module-bluetooth-device. Sometimes after that the polling on the\n" + ">>> stream fd get a POLLHUP and the module-bluetooth-device unloads\n" + ">>> itself. Other times the POLLHUP doesn't happen and the remaining steps\n" + ">>> go without any problem.\n" + ">>>\n" + ">>> Ideas on how to improve this scenario will be very helpful.\n" + ">>>\n" + ">>>\n" + ">>\n" + ">> The output from bluetoothd likes below:\n" + ">>\n" + ">> bluetoothd[21141]: Accepted AG connection from 00:BD:3A:D4:4E:53 for\n" + ">> /org/bluez/21141/hci0/dev_00_BD_3A_D4_4E_53\n" + ">> bluetoothd[21141]: Accepted SCO connection from 00:BD:3A:D4:4E:53\n" + ">> bluetoothd[21141]: No matching connection found for handle 6\n" + ">> bluetoothd[21141]: sco connection is released\n" + ">>\n" + ">> I think you should not load module-bluetooth-device until a voice call is\n" + ">> started, no matter incoming or outgoing. Because PA may play music from\n" + ">> other device at the same time. And bluetooth-device and loopback module are\n" + ">> loaded together. According to HFP v1.5 4.13, there are two cases for\n" + ">> incoming call. And outgoing call is simpler than incoming call.\n" + ">>\n" + ">> If AG and HF both support in band ring tones, we should send a signal from\n" + ">> oFono to PA when callsetup=1. If not, we should send it when call=1.\n" + ">>\n" + ">> I had a patch originally but I cannot find it now. :-(. The basic idea is to\n" + ">> add a filter in ciev_notify() to emit signal (CallStarted and CallEnded) to\n" + ">> PA. And PA loads module once it got that signal. Maybe the signal name was\n" + ">> bad and you could choose better one as you want. ;-)\n" + ">>\n" + ">\n" + "> I think loading module-bluetooth-device only when there is an active\n" + "> call can be a good solution. But I'm concerned about other audio\n" + "> events, i. e.: ringing, SMS notification etc.: doesn't the AG\n" + "> establishes a SCO channel for the these events? Also, I don't think\n" + "> pulse should listen to ofono signals, it should be agent-agnostic. But\n" + "> a signal could be added to the agent interface in this case.\n" + "\n" + "Yeah. Maybe you are right. PA should not listen to ofono signal directly \n" + "but through an agent signal to make it more generic. AFAK, SMS \n" + "notification doesn't require SCO. Upper app could simply watch the \n" + "property changes from oFono.\n" + "\n" + "> And I'm not sure if automatically loading module-loopback is a good\n" + "> idea, I think we better expose through the UI how to handle the audio\n" + "> stream. Some users may have a bunch of soundcards or some very weird\n" + "> audio setup, and it's up to them to decide which soundcard to connect\n" + "> the HFP stream.\n" + ">\n" + "\n" + "I am not audio expert but AFAK PA has variant policies to control which \n" + "audio stream should be feeded into the speaker/mic. Loading \n" + "module-bluetooth-device is only the 1st step to create source/sink. I \n" + "think the voicecall have the higher priority than other steam like \n" + "music, etc. And yes, loading module-loopback could be decided by PA policy.\n" + "\n" + "Thanks.\n" + Zhenhua. -7c0d419082dec57d0bb73398cf46fc1832e90925ce52f6013b7ced31de232000 +1cb4c1e558cdce26df3293b8eaf9086fd4e453b03b524bccbc10907e652f9000
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.