LKML Archive on
help / color / mirror / Atom feed
From: Pavel Machek <>
To: Kai Vehmanen <>,,,
Cc: Sebastian Reichel <>,
	Peter Ujfalusi <>,
	Kai Vehmanen <>,
	Pali Rohar <>,
	Aaro Koskinen <>,
	Ivaylo Dimitrov <>,,,
Subject: Right interface for cellphone modem audio (was Re: [PATCHv2 0/2] N900 Modem Speech Support)
Date: Fri, 6 Mar 2015 10:43:54 +0100	[thread overview]
Message-ID: <20150306094354.GA32369@amd> (raw)
In-Reply-To: <alpine.DEB.2.00.1503051844420.2610@ecabase.localdomain>


> >>Userland access goes via /dev/cmt_speech. The API is implemented in
> >>libcmtspeechdata, which is used by ofono and the project.
> >Yes, the ABI is "tested" for some years, but it is not documented, and
> >it is very wrong ABI.
> >
> >I'm not sure what they do with the "read()". I was assuming it is
> >meant for passing voice data, but it can return at most 4 bytes,
> >
> >We already have perfectly good ABI for passing voice data around. It
> >is called "ALSA". libcmtspeech will then become unneccessary, and the
> >daemon routing voice data will be as simple as "read sample from
> I'm no longer involved with cmt_speech (with this driver nor modems in
> general), but let me clarify some bits about the design.

Thanks a lot for your insights; high level design decisions are quite
hard to understand from C code.

> First, the team that designed the driver and the stack above had a lot of
> folks working also with ALSA (and the ALSA drivers have been merged to
> mainline long ago) and we considered ALSA on multiple occasions as the
> interface for this as well.
> Our take was that ALSA is not the right interface for cmt_speech. The
> cmt_speech interface in the modem is _not_ a PCM interface as modelled by
> ALSA. Specifically:
> - the interface is lossy in both directions
> - data is sent in packets, not a stream of samples (could be other things
>   than PCM samples), with timing and meta-data
> - timing of uplink is of utmost importance

I see that you may not have data available in "downlink" scenario, but
how is it lossy in "uplink" scenario? Phone should always try to fill
the uplink, no? (Or do you detect silence and not transmit in this
case?) (Actually, I guess applications should be ready for "data not
ready" case even on "normal" hardware due to differing clocks.)

Packets vs. stream of samples... does userland need to know about the
packets? Could we simply hide it from the userland? As userland daemon
is (supposed to be) realtime, do we really need extra set of
timestamps? What other metadata are there?

Uplink timing... As the daemon is realtime, can it just send the data
at the right time? Also normally uplink would be filled, no?

> Some definite similarities:
>  - the mmap interface to manage the PCM buffers (that is on purpose
>    similar to that of ALSA)
> The interface was designed so that the audio mixer (e.g. Pulseaudio) is run
> with a soft real-time SCHED_FIFO/RR user-space thread that has full control
> over _when_ voice _packets_ are sent, and can receive packets with meta-data
> (see libcmtspeechdata interface, cmtspeech.h), and can detect and handle
> gaps in the received packets.

Well, packets are of fixed size, right? So the userland can simply
supply the right size in the common case. As for sending at the right
time... well... if the userspace is already real-time, that should be

Now, there's a difference in the downlink. Maybe ALSA people have an
idea what to do in this case? Perhaps we can just provide artificial
"zero" data?

> This is very different from modems that offer an actual PCM voice link for
> example over I2S to the application processor (there are lots of these on
> the market). When you walk out of coverage during a call with these modems,
> you'll still get samples over I2S, but not so with cmt_speech, so ALSA is
> not the right interface.

Yes, understood.

> Now, I'm not saying the interface is perfect, but just to give a bit of
> background, why a custom char-device interface was chosen.

Thanks and best regards,
(cesky, pictures)

  reply	other threads:[~2015-03-06  9:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03  0:44 [PATCHv2 0/2] N900 Modem Speech Support Sebastian Reichel
2015-03-03  0:44 ` [PATCHv2 1/2] HSI: cmt_speech: Add cmt-speech driver Sebastian Reichel
2015-03-04 11:09   ` Paul Bolle
2015-03-03  0:44 ` [PATCHv2 2/2] HSI: nokia-modem: Add cmt-speech support Sebastian Reichel
2015-03-04 19:24 ` [PATCHv2 0/2] N900 Modem Speech Support Pavel Machek
2015-03-04 19:36   ` Aaro Koskinen
2015-03-04 19:55     ` Pavel Machek
2015-03-04 19:41   ` Pavel Machek
2015-03-05 11:30 ` Pavel Machek
2015-03-05 17:32   ` Kai Vehmanen
2015-03-06  9:43     ` Pavel Machek [this message]
2015-03-06 20:49       ` Right interface for cellphone modem audio (was Re: [PATCHv2 0/2] N900 Modem Speech Support) Kai Vehmanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150306094354.GA32369@amd \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Right interface for cellphone modem audio (was Re: [PATCHv2 0/2] N900 Modem Speech Support)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).