The sad state of voice support in cellular modems(laforge.gnumonks.org) |
The sad state of voice support in cellular modems(laforge.gnumonks.org) |
With these USB modems, although they run Linux & Android, the images are of course proprietary and you fully rely on Huawei for security patches. The patches also don't install automatically, you need to check for them, download and install by yourself.
Most IoT devices have the same problem, so I personally avoid buying them, although they can work behind your home firewall, which can protect against many remote attacks. GSM modem is your gateway to the internet, so you can't put a firewall at front of it.
So, given this, why can't the standards require that the modem expect there to be some other chip (e.g. the SoC in a smartphone; a specialized DSP on a dumbphone; a ground resistor on a mobile data stick) to feed the modem audio packets which have been pre-encoded and serialized to the format it would have done itself, so it can just take them, wrap them in baseband frames, and directly put them on the wire?
In other words, why is the (DAC + GSM/G.722/etc. DSP + ser/des) logic a feature of cellular modems, rather than a feature of phones?
Think about it by analogy: you wouldn't expect a PSTN modem to come with a feature where a computer can make analogue telephone calls using it by hooking it up directly to your microphone and speakers. You'd expect that, if it did any such thing, it'd be by DMAing pre-encoded-for-the-wire packets out of a realtime ring buffer, the same way any network card consumes any other packet. Maybe your sound-card would provide hardware support for some codecs (by consuming one DMA ring and producing another. Or maybe you'd do the audio encoding on your GPU with a GPGPU shader, allowing your phone to speak new voice codecs with just a firmware update.
Also, I'm not sure how easy it would be to even configure the OS to route modem output to default sound card input (your headphones), and the same soundcard's output (your microphone) to the modem input. The assumption of most OS's seems to be that you have one active input and one active output at any given time. It's certainly not something I'd immediately know how to wire up using the default mixer in Windows.
The only vaguely valid technical reason I can think to do it how they have is to reduce latency. Of course the real reason is laziness.
Putting the DAC elsewhere absolves them of this requirement and drastically simplifies their time-to-market statistics. If you make the OS and other layers of the stack responsible for the ADAC, then you don't need to worry about it - as long as there is a usable interface.
Around the world, different markets have regulations governing the recording of calls. Its never supposed to be easy to do this, at a hardware level, because its supposed to be very hard even for the players in various markets to do this - without a third party (i.e. government) involved.
tl;dr the reason this is so, is because hardware vendors have to comply with legislation, and doing squirrely ADAC instead of out of the box Audio routing absolves them of the responsibility.
Systems that use the LGA or m.2 modules often don't use the audio at all, so nobody has cared to make a nice interface.
https://stackoverflow.com/questions/8367864/how-make-use-of-...
> Instead, what some modem vendors have implemented as an ugly hack is the transport of 8kHz 16bit PCM samples over one of the UARTs.