[review] dcbw/huawei-voice
Dan Williams
dcbw at redhat.com
Mon Jun 12 17:03:50 UTC 2017
On Fri, 2017-05-05 at 18:56 +0200, Riccardo Vangelisti wrote:
> > 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.
One last question; do the Huawei modems that you have which do not
support "^CVOICE:0" return "^CVOICE:1"? Or do you have some that *do*
support voice, but return ERROR to the ^CVOICE query?
What I'm trying to figure out is if we can use ^CVOICE (any return
value) to automatically figure out if the Huawei modem supports voice
calls (either USB PCM or hardwired headset), or if there indeed are
devices that somehow support voice but don't implement any ^CVOICE
return.
Supposedly, ^CVOICE:0 = "PC voice", ^CVOICE:1 = "headset". Which would
mean that yes the modem supports voice, just not on a USB port. And
hopefully an ERROR return means it doesn't support *any* kind of voice.
Do you think that would be true for Huawei devices?
Obviously for other devices, we probably have to have a udev tag.
Dan
> 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-d
> > > > > evel
> > > >
> > > > _______________________________________________
> > > > ModemManager-devel mailing list
> > > > ModemManager-devel at lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/modemmanager-dev
> > > > el
> > >
> > > _______________________________________________
> > > 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
>
>
More information about the ModemManager-devel
mailing list