[review] dcbw/huawei-voice

Fri May 5 16:56:46 UTC 2017

> On Fri, 2017-05-05 at 16:40 +0200, Riccardo Vangelisti wrote:
>> Hi,
>>> On Thu, 2017-05-04 at 16:30 +0200, Riccardo Vangelisti wrote:
>>>> Hi,
>>>> sorry for late reply but we took some time to test this branch
>>>> using
>>>> these Huawei modems:
>>>>
>>>> +-------------------+-----------------+------------------------
>>>> --+---
>>>> ----+
>>>>> Modem             | Firmware        | ^CVOICE
>>>>> Support          |
>>>>> Voice |
>>>> +-------------------+-----------------+------------------------
>>>> --+---
>>>> ----+
>>>>> Huawei ME909s-120 | 11.617.01.00.00 | ^CVOICE: 1, 8000, 16, 20
>>>>> |
>>>>> Yes  |
>>>>> Huawei MU709s-2   | 11.651.67.00.00 | ^CVOICE: 1, 8000, 16, 20
>>>>> |
>>>>> Yes  |
>>>>> Huawei E1150      | 11.609.18.00.00 |
>>>>> ^CVOICE:0,8000,16,20     |
>>>>> Yes  |
>>>> +-------------------+-----------------+------------------------
>>>> --+---
>>>> ----+
>>>>
>>>> First of all, when ^CVOICE command is not supported by the modem
>>>> all
>>>> of
>>>> voice capabilities are disabled.
>>>> For example, ME909s and MU709s modems have voice capabilities
>>>> supported
>>>> by the firmware but voice is disabled anyway.
>>> So for these devices, they don't implement CVOICE, but do support
>>> voice
>>> via non-host-routed mechanisms, is that correct?
>> Yes, I don't know why manufacturer disable CVOICE command in these
>> modems.
> OK.
>
>>> eg, they have pins for I2C audio or something like that?  How do we
>>> know that these devices support voice, can we tell from firmware
>>> commands?
>> Yes, they have a PCM audio interface (data in, data out, clk and sync
>> on
>> Mini-PCI express) connected to an external audio codec like
>> TLV320AIC3204.
> Ok.  The problem is that ModemManager should only enable the Voice API
> when it knows the modem has audio hardware or an audio interface, which
> most devices like USB sticks and lots of PCIE modems don't.  So we'll
> probably need to use udev rules too.
Ok.
>
>>>> Our proposal is to use ^CVOICE command only for checking PCM
>>>> audio
>>>> port
>>>> capabilities and not for all voice capabilities.
>>>> Can voice capabilities be enabled or not using ATH or AT+CHUP
>>>> command
>>>> ?
>>> No, because most modems support these commands, but do not include
>>> voice capabilities because they have no mechanism to get audio
>>> in/out
>>> of the device.  Only modems with specific voice routing (I2C, USB,
>>> PCM
>>> etc) actually have the voice capabilitiy, and I don't think we
>>> should
>>> enable the interface unless we know.
>>>
>>> Ideally we can use some other firmware commands to detect that
>>> voice is
>>> possible on devices that do not support CVOICE.
>> After a quick search I cannot find a specific command that can be
>> used
>> to check if modem+firmware supports voice.
>> I think that manufacturer deploy a general purpose firmware in most
>> of
>> their modems.
>> I've attached a text file with some test that show voice related at
>> command can't be used to check if voice is supported or not.
>> In particular Huawei E172 make voice call but voice related AT
>> commands
>> return an error.
> I know many modems support the generic voicecall commands, but most
> don't have audio hardware at all.  I wasn't aware the E172 had that
> voice capabilities in any firmware version, are you sure it has the USB
> PCM audio capability like others?
E172 makes call but don't have an audio jack, maybe with a little hack 
with opening the case or something else it can be connected an audio jack.

>
>>> If we cannot, then I think we have to fall back to udev tags or
>>> something.
>> Right, if CVOICE is not supported we can enable voice capability
>> from
>> udev specifying the audio mode, for example external PCM audio or
>> CVOICE
>> mode.
>> Also when CVOICE is supported we could use external PCM audio using
>> udev
>> tags.
>> Something like ID_MM_HUAWEI_FORCE_EXTAUDIO=1
> Since CVOICE only works on Huawei, and only works on some Huawei
> devices, obviously we'd need to find other AT commands for other
> manufacturers, and/or use udev tags.
>
> I would suggest ID_MM_VOICE_SUPPORTED=1 or something like that, and
> make it available to all devices not just Huawei.
Perfect !
>
> The next question is whether these devices should provide anything in
> the "Audio Format" and "Audio Port" properties.  I would say no, since
> it's very hardware specific and not generally applicable.
Ok, I would suggest "Audio Port" something like "forced" or "User 
request" if voice was enabled by udev tags and all "Audio Format" fields 
set to unknown.
>
> So I will modify the branch to add the ID_MM_VOICE_SUPPORTED tag, and
> have that override the CVOICE check in the Huawei plugin.  I just don't
> want MM to say "this modem supports voice!" for a device that clearly
> has no way to get voice out (like many USB sticks).  I think the
> combination of udev tags and plugin-specific probing would make us all
> happy.
>
> What do you think?
Ok, it's correct.

Thank you,
Riccardo
>
> dan
>
>
>>>> Actually master don't check if modem has voice capabilities but
>>>> simply
>>>> returns an error when you try to make a call.
>>> Right, I changed the check on master to make the CVOICE call for
>>> Huawei
>>> to ensure the modem had voice capability.  Since I only know the
>>> voice
>>> checks for Huawei, that's the only plugin that (in the branch)
>>> exhibits
>>> voice capability.
>> Actually master don't check if modem has voice capabilities because
>> all
>> generic modem that support voice audio interface could make call.
>> In the branch only Huawei modem (with CVOICE or with udev tags) will
>> support voice call. To me it seems to be a regression from master.
>>
>> Can be udev tags made with global scope ? So users can enable it as
>> they
>> want.
>>> I also have a Sierra 860 PCMCIA card with voice capability (has a
>>> headset jack on the card itself) that I was going to improve the
>>> branch
>>> with.  But I know there are Sierra-specific commands that would
>>> allow
>>> me to check whether the modem supports voice calls or not.
>>>
>>>> Aleksander, did you check if this branch works on your MU709 dev
>>>> board ?
>>>>
>>>> Second, we tried to start and receive voice's calls using E1150
>>>> (CVOICE
>>>> supported) but no audio coming from /dev/ttyUSB1 (qcdm).
>>>> # mmcli -m 0 -o 0
>>> This would be a bug if incoming calls are not correctly handled.  I
>>> will investigate and fix it.  Did outgoing calls work on the E1150?
>>>
>>>>>      encoding: 'unknown'
>>>>>    resolution: 'unknown'
>>>>>          rate: 'unknown'
>>>> If we make calls using mmcli --command in debug mode and enabling
>>>> CVOICE
>>>> support (AT^CVOICE=0) and the audio port (AT^DDSETEX=2) all works
>>>> correctly and audio coming from /dev/ttyUSB1.
>>>> Example: # cat /dev/ttyUSB1 | aplay -f S16_BE
>>>>
>>>> Dan, could you indicate the correct sequence to make a call when
>>>> CVOICE
>>>> is supported ? How ModemManager tells me what is the correct
>>>> device
>>>> used
>>>> by audio stream ?
>>> At the moment with the branch, only Huawei supports voice calls,
>>> and
>>> the code currently assumes that any detected QCDM port (there is
>>> almost
>>> always only one) is also the audio port.  I was unable to find
>>> documentation that described what the value returned from
>>> "AT^DDSETEX?"
>>>    actually means, though perhaps it means the USB interface # or
>>> something.  But the only usage I can find is for "2", so it's
>>> unclear.
>>>
>>> Is there any way with the MU709 and ME909 to determine conclusively
>>> that they support voice or not, via AT commands if possible?
>>>
>>> Thanks for testing!!
>>>
>>> Dan
>>>
>>>> Thanks,
>>>> Riccardo
>>>>
>>>>
>>>> Il 18/04/2017 12:29, Aleksander Morgado ha scritto:
>>>>> On Mon, Apr 17, 2017 at 7:08 PM, Dan Williams <dcbw at redhat.com>
>>>>> wrote:
>>>>>> Reworked the audio format stuff and added mmcli support.
>>>>>>
>>>>>> Removed the 'blocked' stuff and started using 'connected'
>>>>>> instead.
>>>>>>
>>>>>> Now the larger change: call state handling in mm-base-
>>>>>> call.c.  I
>>>>>> removed most of the base class call state setting for the MO
>>>>>> (mobile-
>>>>>> originated, eg outgoing) call stuff.  I think the call state
>>>>>> handling
>>>>>> there was wrong; only the subclasses know when the call is
>>>>>> ringing and
>>>>>> has been picked up (answered) on the remote end through
>>>>>> unsolicited
>>>>>> notifications.  So the subclasses must be the ones to update
>>>>>> the
>>>>>> call
>>>>>> state when they get these notifications, not the base call
>>>>>> class.
>>>>>> Huawei calls will now go through UNKNOWN -> DIALING ->
>>>>>> RINGING_OUT ->
>>>>>> ACCEPTED, where previously they went UNKNOWN -> RINGING_OUT
>>>>>> ->
>>>>>> ACTIVE
>>>>>> and at the wrong times.
>>>>>>
>>>>>> Eventually we should implement +CLCC (list current calls)
>>>>>> polling
>>>>>> in
>>>>>> the base class and then we can get this information
>>>>>> generically
>>>>>> for
>>>>>> subclasses that don't implement unsolicited
>>>>>> notifications.  Newer
>>>>>> devices may have support for +CMCCS/+CMCCSI unsolicited
>>>>>> notifications
>>>>>> which could also be used in a generic implementation.
>>>>> Riccardo, Marco, could you guys also review Dan's branch?
>>>>>
>>>> _______________________________________________
>>>> ModemManager-devel mailing list
>>>> ModemManager-devel at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>>> _______________________________________________
>>> ModemManager-devel mailing list
>>> ModemManager-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>> _______________________________________________
>> ModemManager-devel mailing list
>> ModemManager-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel