[Librem-5-dev] [review v2] Voice implementation fixes (with audio channel setup handlers)

[Dan Williams]

On Thu, 2018-08-16 at 17:30 +0100, Bob Ham wrote:
> On 10/08/18 14:31, Aleksander Morgado wrote:
> 
> > The Huawei USB dongles that support voice require a command
> > (AT^DDSETEX=2) to be executed when the call is established, and
> > also
> > need to report which port is being used for audio. In order to
> > support
> > that, instead of subclassing all start/accept/hangup methods, I
> > extended the MMBaseCall class with two new handlers that allow
> > setting
> > up and cleaning up the audio channel however the plugin needs it.
> > Bob,
> > you could use these two methods for the custom AT commands you
> > require
> > for the SIMCom implementation, right?
> 
> Possibly, yes.  The SimTech (== SIMCom) plugin is using the
> MMBroadbandModemQmi class which means I either need to (1) subclass
> MMBroadbandModemQmi and mix in AT commands, or (2) use the plugin's
> AT-only MBroadbandModemSimtech class and add to it.  I'd rather stick
> with QMI but I don't know how well the modem will cope with it so I
> need
> to experiment.

I'd be very curious if the modem supports the QMI Voice service and if
so, how that interacts with the actual audio ports the modem exposes. 
Or if you do indeed need to use AT commands to do the voice operations,
and QMI is completely unaware.

> > Dan's original changes also include support for reporting which
> > port
> > and which audio format to use in the call, so plugins may use that
> > to
> > report to upper layers that required information. Instead of
> > updating
> > that information within the Huawei implementation, that is now
> > managed
> > by the base call object.
> 
> My intention was to handle the audio completely outside of
> ModemManager.
>  Out of interest, what upper layers make use of this information?

Any kind of dialer implementation.  The idea is to make the
ModemManager API as generic as possible, though we understand that this
won't always be possible.

The only other example I have of a voice-capable modem is an AT-based
Huawei device that switches its DIAG tty from QCDM to raw PCM frames
when a voice call is active.  You literally read the PCM data off the
USB tty or write PCM to it as a Linux character device.  Obviously
that's not how they all work, especially in setups where the DAC is
handled by the modem board.  Some older Sierras were like that too;
they had a headphone jack on the card that magically became active
during voice calls.

The point is there are a number of ways audio is exposed by the
hardware, and ModemManager should try to expose those in an
informative, marginally consistent way so that userspace applications
can find and/or control the audio.

Dan

> Cheers,
> 
> Bob
> 
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel