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


On Fri, 6 Mar 2015, Pavel Machek wrote:

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

Lossy was perhaps not the best choice of words, non-continuous would be 
a better choice in the uplink case. To adjust timing, some samples from 
the continuous locally recorded PCM stream need to be skipped and/or 
duplicated. This would normally be done between speech bursts to avoid 

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

Yes, we need flags that tell about the frame. Please see docs for 
'frame_flags' and 'spc_flags' in libcmtspeechdata cmtspeech.h:

Kernel space does not have enough info to handle these flags as the audio 
mixer is not implemented in kernel, so they have to be passed to/from 

And some further info in libcmtspeechdata/docs/

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

But how would you implement that via the ALSA API? With cmt_speech, a 
speech packet is prepared in a mmap'ed buffer, flags are set to describe 
the buffer, and at the correct time, write() is called to trigger 
transmission in HW (see cmtspeech_ul_buffer_release() in 
libcmtspeechdata() -> compare this to snd_pcm_mmap_commit() in ALSA). In 
ALSA, the mmap commit and PCM write variants just add data to the 
ringbuffer and update the appl pointer. Only initial start (and stop) on 
stream have the "do something now" semantics in ALSA.

The ALSA compressed offload API did not exist back when we were working on 
cmt_speech, but that's still not a good fit, although adds some of the 
concepts (notably frames).

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

See above, ALSA just doesn't work like that, there's no syscall for "send 
these samples now", the model is different.

Br, Kai

      reply	other threads:[~2015-03-06 20:50 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     ` Right interface for cellphone modem audio (was Re: [PATCHv2 0/2] N900 Modem Speech Support) Pavel Machek
2015-03-06 20:49       ` Kai Vehmanen [this message]

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=alpine.DEB.2.00.1503062139320.2610@ecabase.localdomain \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: 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).