[review] dcbw/huawei-voice

Fri May 5 15:53:17 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.

> > 
> > > 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?

> > 
> > 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.

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.

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?

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