Re: [pulseaudio-discuss] [PATCH v2 3/3] bluetooth: add correct HFP rfcomm negotiation

2016-08-26 Thread James Bottomley
On Wed, 2016-08-24 at 16:17 +0300, Tanu Kaskinen wrote:
> On Tue, 2016-08-23 at 08:37 -0400, James Bottomley wrote:
> > On Mon, 2016-08-22 at 15:12 +0300, Tanu Kaskinen wrote:
> > >  and AT+CHLD=?.
> > 
> > This one is a bit weird: in theory the response should be call hold
> > states, but we didn't show any call held indicators, so none (i.e. 
> > just respond OK) is the correct response.  I actually experimented 
> > with showing some and the headset crashed.
> 
> Ok. I couldn't find a statement from the HFP spec about how "we don't
> support any of the +CHLD values" should be reported, but judging from
> the 3GPP 27.007 spec, it looks like the response to AT+CHLD=? is
> optional.

Actually, if you've found spec support from only responding OK, I'll
rework the code to do that rather than making up a pointless indicator.
 The slight problem is what happens to the mandatory AT+CHLD?
negotiation because I can see some headsets not sending that if we
don't support any indicators, but I think I can cope with that in the
sequence.

> AT+CIND=? is pretty similar in that we'd rather not pretend to 
> support any indicators, but the 3GPP spec doesn't mark the reply as 
> optional in that case, and the list of indicators has to have at 
> least one entry. However, "if MT is not currently reachable, +CME 
> ERROR:  is returned" - maybe returning +CME ERROR for AT+CIND=? 
> would make more sense?

I'd really rather make up an indicator than return error, because I bet
error in the initialisation sequence isn't usual for headsets.

> > > > > Now that I've read some of the HFP spec, I believe there are 
> > > > > other commands (possibly many of them) that we may encounter 
> > > > > too  after the initial setup, for example AT+CMER. How did 
> > > > > these two commands end up being handled specially? Did your 
> > > > > headset not work without this code?
> > > > 
> > > > We handle AT+CMER.  The v1.6 version of the standard contains a
> > > > diagram which shows the minimum dialog you need.  It's 
> > > > basically BRSF, two CINDS and a CMER.  Once the CMER is sent 
> > > > and replied to, you can establish audio.  The other end may 
> > > > optionally send a  AT+CHLD=? but we can just reply OK to that. 
> > > >  I actually theorise  that just replying OK to this entire 
> > > > negotiation sequence is fine  because it indicates a minimal 
> > > > but functional audio gateway, so in  theory, the negotiation is 
> > > > an optional best practice because the original headset code
> > > > will just reply OK on its own.
> > > 
> > > We don't handle AT+CMER, except as part of the initial setup 
> > > sequence. Further AT+CMER commands get "ERROR" as reply.
> > 
> > We should only ever get one.  Actually 3,0,0,1 to enable event
> > reporting.
> 
> Why should we only ever get one? Why should the headset never send
> 3,0,0,0 to disable event reporting? (If you're going to change the 
> code to respond OK to everything, this question becomes moot, but 
> still I'm somewhat interested in how we can make assumptions about 
> what commands headsets will or will not use.)

The latest code will just respond OK to this ... it doesn't matter
because we never send event indicators, so whether the headset wants
them on or off is irrelevant to us.

> > > What makes AT+BTRH? special in that we should reply "OK" to it 
> > > and "ERROR" to all other commands?
> > 
> > Actually, I think we should just reply OK to all commands (a bit 
> > like HFP).  There's no harm and we don't alter any state.
> 
> That sounds good, if it removes the need for special handling for a
> headset-specific set of commands.

Yes, see below ... I'll post the complete set as a v3, but this is what
I currently have.

> > > > > One possibility for avoiding manual configuration in HFP-only 
> > > > > use cases would be to add some logic to automatically 
> > > > > register the HFP profile when we notice that a HFP-only 
> > > > > headset is being used.
> > > > 
> > > > It would still obscure HSP, though, if you're switching 
> > > > headsets without reloading the modules.
> > > 
> > > True. However, that would be a problem only if
> > > 
> > > - the user actively uses multiple headsets
> > > - one of the headsets supports both HSP and HFP, and one supports
> > > only HFP
> > > - the HSP+HFP headset works only with HSP
> > > 
> > > Seems very marginal case to me, and enabling HFP by default would
> > > anyway break the HSP+HFP headset.
> > 
> > Yes, I agree, lets just do it and see if there's a problem.  I 
> > suspect all phones negotiate for HFP first (android certainly 
> > does), so we'd just be doing what every headset expects.
> 
> I'm not sure if you understood what I meant. I suggested not
> registering HFP support until a HFP-only headset appears. Your 
> response sounds more like you thought that I was suggesting enabling 
> HFP by default as your patches currently do, but I'm not sure, maybe 
> "let's just do it" means that you'll happily write the 

Re: [pulseaudio-discuss] issue with audio over headset_head_unit

2016-08-26 Thread Arun Raghavan


On Thu, 25 Aug 2016, at 06:06 PM, James Bottomley wrote:
> On Thu, 2016-08-25 at 16:35 +0530, Arun Raghavan wrote:
> > On Thu, 25 Aug 2016, at 03:10 PM, Anand Nekkunti wrote:
> > > Hi
> > > I am working audio over Bluetooth . I am able to pair and
> > > connect
> > > with
> > > all speakers(a2dp and HSD ).
> > > but audio coming only  speakers which supports a2dp protocol . I am
> > > not
> > > able to understand why speakers which has HSD protocol not
> > > working(no
> > > error
> > > in pulseaudio log) . Do I need configure anything for this or is
> > > there
> > > any
> > > way forcefully set protocol as a2dp
> > > 
> > > Board :ARM imx6
> > > pulseaudio : 6.0
> > > Bluez :5
> > > 
> > > Working Speaker :
> > > 
> > >  index: 2
> > > name: 
> > > driver: 
> > > flags: HARDWARE DECIBEL_VOLUME LATENCY
> > > state: IDLE
> > > suspend cause:
> > > priority: 9030
> > > volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 /
> > > 100% /
> > > 0.00 dB
> > >balance 0.00
> > > base volume: 65536 / 100% / 0.00 dB
> > > volume steps: 65537
> > > muted: no
> > > current latency: 28.67 ms
> > > max request: 3 KiB
> > > max rewind: 0 KiB
> > > monitor source: 4
> > > sample spec: s16le 2ch 44100Hz
> > > channel map: front-left,front-right
> > > Stereo
> > > used by: 0
> > > linked by: 0
> > > fixed latency: 42.41 ms
> > > card: 2 
> > > module: 21
> > > properties:
> > > bluetooth.protocol = "a2dp_sink"
> > > device.description = "Mi Bluetooth Speaker"
> > > device.string = "00:9E:C8:11:69:42"
> > > device.api = "bluez"
> > > device.class = "sound"
> > > device.bus = "bluetooth"
> > > device.form_factor = "portable"
> > > bluez.path = "/org/bluez/hci0/dev_00_9E_C8_11_69_42"
> > > bluez.class = "0x24041c"
> > > bluez.alias = "Mi Bluetooth Speaker "
> > > device.icon_name = "multimedia-player-bluetooth"
> > > ports:
> > > portable-output: Portable (priority 0, latency offset 0 usec,
> > > available:
> > > yes)
> > > properties:
> > > active port: 
> > > 
> > > 
> > > 
> > > Not Working Speaker:
> > >index: 2
> > > name: 
> > > driver: 
> > > flags: HARDWARE HW_VOLUME_CTRL LATENCY
> > > state: RUNNING
> > > suspend cause:
> > > priority: 9030
> > > volume: mono: 43691 /  67%
> > >balance 0.00
> > > base volume: 65536 / 100%
> > > volume steps: 16
> > > muted: no
> > > current latency: 31.00 ms
> > > max request: 0 KiB
> > > max rewind: 0 KiB
> > > monitor source: 4
> > > sample spec: s16le 1ch 8000Hz
> > > channel map: mono
> > > Mono
> > > used by: 1
> > > linked by: 1
> > > fixed latency: 128.00 ms
> > > card: 2 
> > > module: 21
> > > properties:
> > > bluetooth.protocol = "headset_head_unit"
> > > device.intended_roles = "phone"
> > > device.description = "Bose AE2w 01.01.00"
> > > device.string = "00:0C:8A:67:14:4E"
> > > device.api = "bluez"
> > > device.class = "sound"
> > > device.bus = "bluetooth"
> > > device.form_factor = "headset"
> > > bluez.path = "/org/bluez/hci0/dev_00_0C_8A_67_14_4E"
> > > bluez.class = "0x240404"
> > > bluez.alias = "Bose AE2w 01.01.00"
> > > device.icon_name = "audio-headset-bluetooth"
> > > ports:
> > > headset-output: Headset (priority 0, latency offset 0 usec,
> > > available:
> > > unknown)
> > > properties:
> > > active port: 
> > 
> > Are you using the native backend (HSP) or oFono (HFP) here? Might 
> > help to look at system logs, or get verbose output from PulseAudio 
> > and BlueZ.
> 
> There seems to be a misunderstanding here (I just went around the block
> with Marcel on it).  The fact is that the backend-ofono can only talk
> to a phone, where it emulates HFP, it can't talk to an actual headset. 
>  Meaning that if you have a headset trying to talk to your computer,
> you are ipso facto using the native backend.
> 
> The confusion seems to be because at one time there were patches to
> backend-ofono to talk to headsets, but they depended on non-upstream
> bluez parts and they were never merged.

Right, now I recall talking about this way back with Luiz. I guess your
work on HFP support in backend-native supersedes that work anyway.

Cheers,
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss