Re: [PATCH v4 3/3] ASoC: SOF: Intel: hda: Avoid checking jack on system suspend
Hi,
On Wed, 13 Jan 2021, Kai-Heng Feng wrote:
> System takes a very long time to suspend after commit 215a22ed31a1
> ("ALSA: hda: Refactor codec PM to use direct-complete optimization"):
[...]
> [ 321.262505] snd_hda_codec_realtek ehdaudio0D0: Unable to sync register
> 0x2b8000. -5
> [ 328.426919] snd_hda_codec_realtek ehdaudio0D0: Unable to sync register
> 0x2b8000. -5
> [ 329.490933] ACPI: EC: interrupt blocked
>
> That commit keeps the codec suspended during the system suspend. However,
> mute/micmute LED will clear codec's direct-complete flag by
> dpm_clear_superiors_direct_complete().
thanks Kai-Heng. This indeed explains why the regression is only seen on
some systems (those with mute/micmute LED).
> This doesn't play well with SOF driver. When its runtime resume is
> called for system suspend, hda_codec_jack_check() schedules
> jackpoll_work which uses snd_hdac_is_power_on() to check whether codec
The commit explanation is a bit long, but this is indeed the problem.
jackpoll_work() is common code (also used by snd-hda-intel) and SOF should
align to snd-hda-intel and not call this directly to check jack status,
and especially not when going to system suspend.
There are a lot of details related to exact conditions when this problem
triggers, but in the end, this is the main point.
> When direct-complete path is taken, snd_hdac_is_power_on() returns true
> and hda_jackpoll_work() is skipped by accident. So this is still not
> correct.
This doesn't really affect correctness of the patch, but I'm not sure if
"accident" is the best characterization. This just explains why the bug
was not hit in all cases.
snd_hdac_is_power_on() is called in a few places:
- hda_jackpoll_work()
- snd_hda_bus_reset_codecs()
- snd_hda_update_power_acct()
In first two, the current logic seems appropriate (if runtime-pm is
disabled, the action guarded by is_power_on() should not be taken). The
third case seems suspicious and not sure if current is_power_on()
is appropriate.
So it's not quite clear whether hdaudio.h:snd_hdac_is_power_on() is
wrong or not. But that's now a separate discussion to have, and not
related to this patchset anymore.
> Because devices suspend in reverse order (i.e. child first), it doesn't
> make much sense to resume an already suspended codec from audio
> controller. So avoid the issue by making sure jackpoll isn't used in
> system PM process.
The commit explanation is a bit long, but it is probably useful to have
the background included.
For the whole series:
Reviewed-by: Kai Vehmanen
Br, Kai
Re: [PATCH] ASoC: SOF: Intel: avoid reverse module dependency
Hi Arnd, On Wed, 6 Jan 2021, Arnd Bergmann wrote: > On Tue, Jan 5, 2021 at 8:07 PM Arnd Bergmann wrote: > > Change it to use the normal probe order of starting with a specific > > device in a driver, turning the sof-acpi-dev.c driver into a library. > > There were a couple of build failures introduced by this version. I have > one that does build now, and can post that if others think this is the > direction they want to go. thanks for the follow-up. We have many SOF maintainers still out on holidays this week, so let's give some time for people to digest. This is certainly a big change. The version you posted is already sufficient to describe the idea for sure. Br, Kai
Re: [PATCH] ALSA: hda: fix SND_INTEL_DSP_CONFIG dependency
Hey, On Tue, 5 Jan 2021, Arnd Bergmann wrote: > On Mon, Jan 4, 2021 at 4:05 PM Takashi Iwai wrote: > > As I wrote in another post, a part of the problem is that SOF PCI and > > ACPI drivers call snd_intel_dsp_driver_probe() unconditionally, even > > if no Intel driver is bound. > > Makes sense. Is there an existing Kconfig that could be used to > decide whether the drivers use SND_INTEL_DSP_CONFIG or not? no, unfortunately not. This is selected per platform in sound/soc/sof/intel/Kconfig. CONFIG_SND_SOC_SOF_INTEL_PCI is close, but there is at least one platform that does not use SND_INTEL_DSP_CONFIG. > According to sof_pci_ids[], all PCI IDs are Intel specific, but I can't > tell which ones need the DSP config. Indeed currently all the ids are Intel ones (and with exception of old Merrifield, all use DSP config). But that's just how it is now. > Could it be part of the device specific driver_data? This would certainly be a clean way and allow to remove the Intel-specific calls from sof_pci_probe(). As a short-term solution, IS_REACHABLE() seems ok as well. Br, Kai
Re: [PATCH v2 2/3] ASoC: SOF: Intel: hda: Modify existing helper to disable WAKEEN
Hi, On Mon, 4 Jan 2021, Kai-Heng Feng wrote: > Modify hda_codec_jack_wake_enable() to also support disable WAKEEN. > In addition, this patch also moves the WAKEEN disablement call out of > hda_codec_jack_check() into hda_codec_jack_wake_enable(). ack, this looks good: Acked-by: Kai Vehmanen Br, Kai
Re: [PATCH v2 1/3] ASoC: SOF: Intel: hda: Resume codec to do jack detection
Hi,
On Mon, 4 Jan 2021, Kai-Heng Feng wrote:
> Instead of queueing jackpoll_work, runtime resume the codec to let it
> use different jack detection methods based on jackpoll_interval.
hmm, but jackpoll_work() does the same thing, right? So end result should
be the same.
> This matches SOF driver's behavior with commit a6e7d0a4bdb0 ("ALSA: hda:
> fix jack detection with Realtek codecs when in D3"). Since SOF only uses
> Realtek codec, we don't need any additional check for the resume.
This is not quite correct. First, SOF does support any HDA codec, not just
Realteks (see e.g. https://github.com/thesofproject/linux/issues/1807),
and second, this doesn't really match the hda_intel.c patch you mention.
SOF implements a more conservative approach where we basicly assume
codec->forced_resume=1 to always apply, and do not implement support for
codec->relaxed_resume. So the above patch doesn't fully apply to SOF as
the design is not same.
> diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c
> index 6875fa570c2c..df59c79cfdfc 100644
> --- a/sound/soc/sof/intel/hda-codec.c
> +++ b/sound/soc/sof/intel/hda-codec.c
> @@ -93,8 +93,7 @@ void hda_codec_jack_check(struct snd_sof_dev *sdev)
>* has been recorded in STATESTS
>*/
> if (codec->jacktbl.used)
> - schedule_delayed_work(>jackpoll_work,
> - codec->jackpoll_interval);
> + pm_request_resume(>core.dev);
I think this change is still good. Just drop the but about Realtek
codecs from commit message and maybe s/matches/aligns/.
Br, Kai
Re: [PATCH v2 3/3] ASoC: SOF: Intel: hda: Avoid checking jack on system suspend
Hey,
On Mon, 4 Jan 2021, Kai-Heng Feng wrote:
> System takes a very long time to suspend after commit 215a22ed31a1
> ("ALSA: hda: Refactor codec PM to use direct-complete optimization"):
> [ 90.065964] PM: suspend entry (s2idle)
the patch itself looks good, but can you explain a bit more in what
conditions you hit the delay?
I tried to reproduce the delay on multiple systems (with tip of
tiwai/master), but with no luck. I can see hda_jackpoll_work() called, but
at this point runtime pm has been disabled already (via
__device_suspend()) and snd_hdac_is_power_on() will return true even when
pm_runtime_suspended() is true as well (which is expected as runtime-pm is
disabled at this point for system suspend). End result is codec is not
powered up in hda_jackpoll_work() and suspend is not delayed.
The patch still seems correct. You would hit the problem you describe if
jackpoll_interval was set to a non-zero value (not the case on most
systems supported by SOF, but still a possibility). I'm still curious how
you hit the problem. At minimum, we are missing a scenario in our testing.
Br, Kai
Re: [PATCH] ASoC: SOF: Fix spelling mistake in Kconfig "ond" -> "and"
Hi, thanks Colin. On Wed, 16 Dec 2020, Colin King wrote: > From: Colin Ian King > > There is a spelling mistake in the Kconfig help text. Fix it. > > Signed-off-by: Colin Ian King Acked-by: Kai Vehmanen Br, kai
Re: [PATCH v2 3/4] ALSA: hda: Separate runtime and system suspend
Hi,
thanks, this looks like a good improvement! Some minor notes:
On Tue, 27 Oct 2020, Kai-Heng Feng wrote:
> Both pm_runtime_force_suspend() and pm_runtime_force_resume() have
> some implicit checks, so it can make code flow more straightfoward if we
> separate runtime and systemd suspend callbacks.
straightforward -> straightforward
and systemd? Maybe just "system suspend"? :)
> While at it, also remove AZX_DCAPS_SUSPEND_SPURIOUS_WAKEUP, as the
> original bug commit a6630529aecb ("ALSA: hda: Workaround for spurious
> wakeups on some Intel platforms") solves doesn't happen with this
> patch.
Hmm, so this was gone already with the v1 version (so not related to
programming the WAKEEN when going to system suspend)?
> @@ -143,6 +143,7 @@ struct azx {
> unsigned int align_buffer_size:1;
> unsigned int region_requested:1;
> unsigned int disabled:1; /* disabled by vga_switcheroo */
> + unsigned int prepared:1;
I wonder if "pm_prepared" would be better as ALSA API has a prepare method
as well and this is not related. OTOH, if ok to Takashi, ok for me as
well.
> + azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) &
> +~STATESTS_INT_MASK);
This would fit to one line now.
Br, Kai
Re: linux-next: build warning after merge of the sound-asoc tree
Hello, +Daniel,+Pierre On Fri, 18 Sep 2020, Stephen Rothwell wrote: > After merging the sound-asoc tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > WARNING: modpost: missing MODULE_LICENSE() in sound/soc/sof/imx/imx-common.o thanks for the report. I made a patch and once I get acks from stakeholders, will submit to asoc tree: https://github.com/thesofproject/linux/pull/2450 We'll also follow up how this slipped through our CI. Br, Kai
Re: [PATCH v2] ASoC: hdac_hdmi: support 'ELD' mixer
Hey,
a general comment first. We are trying to move development to patch_hdmi,
but given we still have platforms using hdac_hdmi, this patch seems like a
useful addition.
On Tue, 18 Aug 2020, Brent Lu wrote:
> Add an binary mixer 'ELD' to each HDMI PCM device so user space
> could read the ELD data of external HDMI display.
Minor spelling fixes:
"Add a binary mixer"
"so user space can read"
> +static int hdac_hdmi_eld_ctl_get(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
[...]
> + list_for_each_entry(port, >port_list, head) {
> + eld = >eld;
> +
[...]
> + memcpy(ucontrol->value.bytes.data, eld->eld_buffer,
> +eld->eld_size);
> + break;
> + }
This is a bit iffy part. If same PCM is connected to multiple receivers,
you return ELD data for the first one and ignore the rest. OTOH, this is
inline with comment in hdac_hdmi_get_port_from_cvt() in that this
pcm-to-many routing is not really supported by the driver now. But
jack status reporting is done a port basis, not per PCM/CVTs, so this is
not fully aligned.
Hmm. Given the proposed patch is aligned with the user-space interface
exposed by patch_hdmi.c, I'm ok to go with this. Can you add an explicit
comment to explain what is happening above?
Br, Kai
Re: [PATCH AUTOSEL 4.4 7/9] ALSA: hda/hdmi: fix failures at PCM open on Intel ICL and later
Hi Sasha, On Tue, 14 Jul 2020, Sasha Levin wrote: > From: Kai Vehmanen > > [ Upstream commit 56275036d8185f92eceac7479d48b858ee3dab84 ] > > When HDMI PCM devices are opened in a specific order, with at least one > HDMI/DP receiver connected, ALSA PCM open fails to -EBUSY on the > connected monitor, on recent Intel platforms (ICL/JSL and newer). While we don't have Ice Lake hardware support in the HDA HDMI codec driver in any 4.x stable trees (only in 5.1+), so this patch will not help on those and can be dropped. Br, Kai
Re: [PATCH v3] ASoC: SOF: Intel: hda: Clear RIRB status before reading WP
Hey Brent,
On Fri, 12 Jun 2020, Takashi Iwai wrote:
> On Fri, 12 Jun 2020 12:50:48 +0200, Brent Lu wrote:
> >
> > Port commit 6d011d5057ff ("ALSA: hda: Clear RIRB status before reading
> > WP") from legacy HDA driver to fix the get response timeout issue.
> > Current SOF driver does not suffer from this issue because sync write
> > is enabled in hda_init. The issue will come back if the sync write is
> > disabled for some reason.
> >
> > Signed-off-by: Brent Lu
>
> Reviewed-by: Takashi Iwai
thanks, looks good now:
Reviewed-by: Kai Vehmanen
Re: [PATCH v2] ASoC: SOF: Intel: hda: unsolicited RIRB response
Hi Brent,
On Fri, 12 Jun 2020, Brent Lu wrote:
> Port commit 6d011d5057ff ("ALSA: hda: Clear RIRB status before reading
> WP") from legacy HDA driver to fix the get response timeout issue.
> Current SOF driver does not suffer from this issue because sync write
> is enabled in hda_init. The issue will come back if the sync write is
> disabled for some reason.
better to align the logic, so I'm ok to take this patch to SOF.
Can you fix the summary though:
- ASoC: SOF: Intel: hda: unsolicited RIRB response
+ ASoC: SOF: Intel: hda: Clear RIRB status before reading WP
Br, Kai
Re: [PATCH] ASoC: SOF: Update correct LED status at the first time usage of update_mute_led()
Hi, On Thu, 30 Apr 2020, Kai-Heng Feng wrote: > At the first time update_mute_led() gets called, if channels are already > muted, the temp value equals to led_value as 0, skipping the following > LED setting. thanks, looks good! Acked-by: Kai Vehmanen Br, Kai
Re: [PATCH] soc: imx8m: Make imx8m_dsp_ops static
Hi, [+Daniel] On Sat, 25 Apr 2020, ChenTao wrote: > Fix the following warning: > > sound/soc/sof/imx/imx8m.c:95:20: warning: > symbol 'imx8m_dsp_ops' was not declared. Should it be static? yes, this was missed in the initial version of this driver. Ok to go with this: Acked-by: Kai Vehmanen You did not send a copy of the patch to Mark Brown (broo...@kernel.org). Can you resend with him in the loop, so he can pick the patch up to ALSA ASoC tree. Also please copy the ALSA list (alsa-de...@alsa-project.org). Br, Kai
Re: linux-next: Fixes tag needs some work in the sound-asoc-fixes tree
Hi,
On Wed, 2 Oct 2019, Stephen Rothwell wrote:
> In commit
>
> e66e52c5b742 ("ASoC: SOF: pcm: fix resource leak in hw_free")
>
> Fixes tag
>
> Fixes: c29d96c3b9b4 ("ASoC: SOF: reset DMA state in prepare")
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Did you mean
>
> Fixes: 04c8027764bc ("ASoC: SOF: reset DMA state in prepare")
yes, you are correct. This was a mistake in original patch submission,
which had a fixes SHA1 pointing to the patch SOF project's git tree and
not the merged patch.
Br, Kai
Re: Right interface for cellphone modem audio (was Re: [PATCHv2 0/2] N900 Modem Speech Support)
Hi, 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 artifacts. 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: https://www.gitorious.org/libcmtspeechdata/libcmtspeechdata/source/9206835ea3c96815840a80ccba9eaeb16ff7e294: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 user-space. And some further info in libcmtspeechdata/docs/ https://www.gitorious.org/libcmtspeechdata/libcmtspeechdata/source/9206835ea3c96815840a80ccba9eaeb16ff7e294:doc/libcmtspeechdata_api_docs_main.txt 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Right interface for cellphone modem audio (was Re: [PATCHv2 0/2] N900 Modem Speech Support)
Hi, 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 artifacts. 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: https://www.gitorious.org/libcmtspeechdata/libcmtspeechdata/source/9206835ea3c96815840a80ccba9eaeb16ff7e294: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 user-space. And some further info in libcmtspeechdata/docs/ https://www.gitorious.org/libcmtspeechdata/libcmtspeechdata/source/9206835ea3c96815840a80ccba9eaeb16ff7e294:doc/libcmtspeechdata_api_docs_main.txt 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 0/2] N900 Modem Speech Support
Hi, On Thu, 5 Mar 2015, Pavel Machek wrote: Userland access goes via /dev/cmt_speech. The API is implemented in libcmtspeechdata, which is used by ofono and the freesmartphone.org 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, AFAICT. 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. 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 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. 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. 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. PS Not saying it's enough for mainline inclusion, but libcmtspeechdata [1] was released and documented to enable the driver to be used by other software than the closed pulseaudio modules. You Pavel of course know this as you've been maintaining the library, but FYI for others. [1] https://www.gitorious.org/libcmtspeechdata Br, Kai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 0/2] N900 Modem Speech Support
Hi, On Thu, 5 Mar 2015, Pavel Machek wrote: Userland access goes via /dev/cmt_speech. The API is implemented in libcmtspeechdata, which is used by ofono and the freesmartphone.org 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, AFAICT. 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. 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 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. 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. 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. PS Not saying it's enough for mainline inclusion, but libcmtspeechdata [1] was released and documented to enable the driver to be used by other software than the closed pulseaudio modules. You Pavel of course know this as you've been maintaining the library, but FYI for others. [1] https://www.gitorious.org/libcmtspeechdata Br, Kai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
