July 2012 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Audiotrak Maya U5 mixer
by Lollul 24 Jul '12

24 Jul '12

Hello, I'm using an Audiotrak Maya U5 USB card. As far as I can tell it is based on VIA EnvyUSB VT1728A chip. Running on fresh 3.5-rc7 or an old 2.6.32.27 (on openwrt) kernel I have similar problems with the mixer: 1. The controls PCM and PCM 1 are stuck on lowest level. It can play mp3s fine so I guess PCM is initialized somehow on proper levels but I would expect there should be a way to control PCM volume (other than by controlling Speaker volume). 2. I'm unable to achieve a 'loop' between SPDIF input and the Speakers. It works fine with Line-In. But with SPDIF input I have to either use "arecord | aplay" or alsaloop. Since Windows7 is able to turn on 'Listen' mode on SPDIF input on standard drivers I hope hardware can do it but somehow there is no control for this in alsamixer. alsa-info output available at: http://pastebin.ca/2173999 (this is with with laptop's hda modules removed) (Latest Audiotrak firmware was installed) Many Thanks, Rafal

2 2

[alsa-devel] alsa-lib v1.0.16 error
by 박영기 24 Jul '12

24 Jul '12

Hi all, I'm a beginner developer in ALSA. I got an error in my application which uses alsa v1.0.16 and Segmentation Fault too. My system is : - OS: embedded linux - CPU: S3C-6410 CPU - CODEC: WM9713 I want to resolve this problem. So what should I do? is there an patch? Or do I have to migration to higher version? Or how to debug? ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'defaults.ctl.card' ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib confmisc.c:251:(snd_func_getenv) error evaluating default ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_getenv returned error: No such file or directory ALSA lib conf.c:3985:(snd_config_expand) Evaluate error: No such file or directory ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL default Regards, Young-Gi (YG) Park

1 0

[alsa-devel] virtual sound driver
by Liu, George 24 Jul '12

24 Jul '12

I'm trying to write a virtual sound driver to capture PCM data. How do I modify dummy.c to capture PCM into buffer? Does the PCM data ever sent to any of the pcm_op call backs? There's no read/write callbacks? Thanks so much. George

3 4

[alsa-devel] [PATCH] ALSA: pcm - introduce soc_delay
by Vinod Koul 23 Jul '12

23 Jul '12

In many modern SoCs the audio DSP can buffer the PCM ring buffer data. Today we have no means to represent this buffering and ALSA wrongly detects an overrun when hw_ptr reaches app_ptr value, though DSP may still have some buffered data. This patch tries to add a new field "soc_delay" to represent buffering done in DSPs. This value is also used for the xrun calculations in ALSA. Signed-off-by: Vinod Koul <vinod.koul(a)linux.intel.com> -- Once we are okay with this approach, I will send a follow up patch which adds this notion in ASoC and uses this to compute cpu_dai delay. The codec_dai delay along with FIFO delay from cpu_dai should be added and reresented by today's notion of delay. --- include/sound/pcm.h | 1 + sound/core/pcm_lib.c | 14 +++++++++++--- sound/core/pcm_native.c | 6 +++--- 3 files changed, 15 insertions(+), 6 deletions(-) diff --git a/include/sound/pcm.h b/include/sound/pcm.h index a55d5db..405deb7 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -281,6 +281,7 @@ struct snd_pcm_runtime { unsigned long hw_ptr_jiffies; /* Time when hw_ptr is updated */ unsigned long hw_ptr_buffer_jiffies; /* buffer time in jiffies */ snd_pcm_sframes_t delay; /* extra delay; typically FIFO size */ + snd_pcm_sframes_t soc_delay; /* extra delay; typically delay incurred in soc */ /* -- HW params -- */ snd_pcm_access_t access; /* access mode */ diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index 8f312fa..4977012 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -292,7 +292,15 @@ int snd_pcm_update_state(struct snd_pcm_substream *substream, return -EPIPE; } } else { - if (avail >= runtime->stop_threshold) { + snd_pcm_uframes_t actual_avail; + if (avail < runtime->soc_delay) + actual_avail = avail; + else + actual_avail = avail - runtime->soc_delay; + if (actual_avail >= runtime->stop_threshold) { + snd_printd(KERN_ERR "avail > stop_threshold!!\n"); + snd_printd(KERN_ERR "actual_avail %ld, avail %ld, soc_delay %ld!!\n", + actual_avail, avail, runtime->soc_delay); xrun(substream); return -EPIPE; } @@ -440,9 +448,9 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, if (runtime->hw.info & SNDRV_PCM_INFO_BATCH) goto no_jiffies_check; hdelta = delta; - if (hdelta < runtime->delay) + if (hdelta < (runtime->delay + runtime->soc_delay)) goto no_jiffies_check; - hdelta -= runtime->delay; + hdelta -= (runtime->delay + runtime->soc_delay); jdelta = curr_jiffies - runtime->hw_ptr_jiffies; if (((hdelta * HZ) / runtime->rate) > jdelta + HZ/100) { delta = jdelta / diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 53b5ada..fc2d664 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -606,13 +606,13 @@ int snd_pcm_status(struct snd_pcm_substream *substream, if (runtime->status->state == SNDRV_PCM_STATE_RUNNING || runtime->status->state == SNDRV_PCM_STATE_DRAINING) { status->delay = runtime->buffer_size - status->avail; - status->delay += runtime->delay; + status->delay += runtime->delay + runtime->soc_delay; } else status->delay = 0; } else { status->avail = snd_pcm_capture_avail(runtime); if (runtime->status->state == SNDRV_PCM_STATE_RUNNING) - status->delay = status->avail + runtime->delay; + status->delay = status->avail + runtime->delay + runtime->soc_delay; else status->delay = 0; } @@ -2442,7 +2442,7 @@ static int snd_pcm_delay(struct snd_pcm_substream *substream, n = snd_pcm_playback_hw_avail(runtime); else n = snd_pcm_capture_avail(runtime); - n += runtime->delay; + n += runtime->delay + runtime->soc_delay; break; case SNDRV_PCM_STATE_XRUN: err = -EPIPE; -- 1.7.0.4

7 20

[alsa-devel] Can ASoC support SPDIF AC3 passthrough playback (non linear PCM) ?
by Sangsu Park 23 Jul '12

23 Jul '12

Hi, We're developing a platform where we have SPDIF output. And we want to SPDIF AC3 playback (non linear PCM). Our CPU is a kind of ARM architecture one and it has a SPDIF that can support AC3 passthrough playback. I've already know that ALSA can support SPDIF AC3 passthrough playback like follows, http://www.mythtv.org/wiki/Configuring_Digital_Sound_with_AC3_and_SPDIF But, I can't find that any ARM architecture CPU can be supportable for SPDIF AC3 passthrough playback. Are there anyone who have a SPDIF AC3 passthrough playback? or anyone who know the clue about SPDIF AC3 passthrought playback supportable on ASoC? Our SPDIF already can support on linear PCM playback. But we have no experience in SPDIF AC3 passthrough playback. Just changing register setup from linear PCM playback to non-linear PCM playback is enough? Or any reference code on ASoC for SPDIF passthrough playback? Any hint would be greatly appreciated. Thanks.

4 4

[alsa-devel] [PATCH] ASoC: wm8994: Ensure there are enough BCLKs for four channels
by Mark Brown 23 Jul '12

23 Jul '12

Otherwise if someone tries to use all four channels on AIF1 with the device in master mode we won't be able to clock out all the data. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index bb62f4b..235577a 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -2649,7 +2649,7 @@ static int wm8994_hw_params(struct snd_pcm_substream *substream, return -EINVAL; } - bclk_rate = params_rate(params) * 2; + bclk_rate = params_rate(params) * 4; switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE: bclk_rate *= 16; -- 1.7.10.4

1 0

Re: [alsa-devel] Using MMAP feature
by Clemens Ladisch 23 Jul '12

23 Jul '12

(please don't drop the mailing list) (please configure your mailer to wrap lines) alberto Villa wrote: > Il 23/07/2012 12:38, Clemens Ladisch ha scritto: >> alberto Villa wrote: >>> Hello, >>> I'm going to use the MMAP feature of ALSA. >> >> Why do you need to do this? > > I need to use MMAP because we are running on an embedded system and we > want to optimize its operations. What exactly do you want to optimize? In most cases, mmap is no faster than snd_pcm_write; using mmap make sense only if the samples are generated dynamically without storing them in a userspace buffer. > It was necessary to use snd_pcm_wait() before snd_pcm_begin(), may be > this the reason? If you never wait, the buffer will be filled eventually. Regards, Clemens

1 0

[alsa-devel] ASoC updates for 3.6
by Mark Brown 23 Jul '12

23 Jul '12

The following changes since commit 409b78cc17a4a3d07a541037575da648ced99437: ASoC imx-audmux: add MX31_AUDMUX_PORT7_SSI_PINS_7 define (2012-07-18 22:09:40 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.6 for you to fetch changes up to 15d47763b354256053c390a9b7bc9f2b4f197711: Merge branch 'for-3.5' into for-3.6 (2012-07-23 10:45:07 +0100) Diffstat looks a bit odd with the HDA stuff but as far as I can tell this is due to it showing up some diffs due to commits you've added. ---------------------------------------------------------------- ASoC: Additional updates for 3.6 A few more fixes for 3.6, some of which are relatively important - they've all been in -next for at least some time. - DAPM fixes for the recent locking changes. - Fix for _PRE and _POST widgets (which have been broken for a few releases now). - A couple of minor driver updates. ---------------------------------------------------------------- Benoît Thébaudeau (1): ASoC: dapm: Fix dapm_set_path_status() connect Liam Girdwood (2): ASoC: dapm: Fix locking during codec shutdown ASoC: dapm: Make sure all dapm contexts are updated Mark Brown (2): ASoC: dapm: Fix _PRE and _POST events for DAPM performance improvements Merge branch 'for-3.5' into for-3.6 Peter Ujfalusi (1): ASoC: omap-mcpdm: Add missing MODULE_ALIAS Robert Jarzmik (1): ASoC: mioa701: convert to snd_soc_register_card API sound/pci/hda/Kconfig | 13 ------------- sound/pci/hda/hda_auto_parser.c | 1 - sound/pci/hda/hda_auto_parser.h | 10 ++++++++++ sound/pci/hda/hda_codec.c | 4 ++++ sound/pci/hda/patch_conexant.c | 6 +++++- sound/pci/hda/patch_realtek.c | 15 +++++++++------ sound/pci/hda/patch_sigmatel.c | 7 ++++++- sound/soc/codecs/tlv320aic3x.c | 4 +--- sound/soc/codecs/tlv320aic3x.h | 1 + sound/soc/codecs/wm2200.c | 1 + sound/soc/codecs/wm8994.c | 3 --- sound/soc/omap/omap-mcpdm.c | 1 + sound/soc/pxa/mioa701_wm9713.c | 33 ++++++++++++--------------------- sound/soc/soc-dapm.c | 28 ++++++++++++++++++++-------- sound/usb/mixer_maps.c | 8 ++++++++ sound/usb/quirks-table.h | 30 ++++++++++++++++++++++++++++++ 16 files changed, 108 insertions(+), 57 deletions(-)

2 1

[alsa-devel] Using MMAP feature
by alberto Villa 23 Jul '12

23 Jul '12

Hello, I'm going to use the MMAP feature of ALSA. I understood I have to use snd_pcm_mmap_begin and snd_pcm_mmap_commit functions, but I can't understand the meaning of some parameters in the snd_pcm_mmap_begin function: when I call this function in order to have access to the capture stream on a call like this: err = snd_pcm_mmap_begin(capture, &c_area, &c_offset, &c_frames); it keeps to return c_frames = 0: is it right ? what does this mean? is the buffer full so that I can read samples or the available contiguous space to be read is 0? Thank you, Alberto -- Dr. Villa Alberto Sw Engineer SeleTech srl via Collodi, 8 20052 Monza (MI) tel: +39 039 5962000 fax: +39 039 9716905 email: a.villa(a)seletech.com web: www.seletech.com www.seletech.eu

2 1

[alsa-devel] Using UCM with PulseAudio
by Arun Raghavan 23 Jul '12

23 Jul '12

Hello, I've been working on porting PulseAudio to Android on the OMAP4-based Galaxy Nexus, and have recently looking at the policy-bits. The basic porting has been greatly simplified with Wei Feng's work to renew PulseAudio UCM integration and Liam's help with fixing up some of the UCM config for the Galaxy Nexus. I am, however, facing some trouble mapping how the hardware is used to how UCM presents it (or, perhaps, the UCM-PA mapping does). Some simplified background: the devices of interest on the OMAP4 SoC are the main hifi PCM which can be routed to various outputs, the modem PCM which is not used for actual output but to enable use of the modem during calls, and the tones PCM which is intended to be used for playing ringtones, aiui. The first problem is mutual exclusivity of verbs. From what I can understand, verbs are intended to be mutually exclusive -- if you have a HiFi verb and a VoiceCall verb, only one may be used at a time. We have mapped verbs to card profiles, which offer the same guarantee. However, on Android (which is a fair example of the kind of audio policy we might want), the HiFi verb PCMs maybe used while the VoiceCall PCMs are open. This is done, for example, to play an end-of-call tone from the CPU while the modem PCMs are still held open. Is there some way to do this with UCM? The second problem is having separate PCMs for modifiers. In the OMAP4 profile, ringtone playback is exposed via a PlayTone modifier which corresponds to a separate PCM from regular HiFi playback. In the UCM-PA mapping we decided on, modifiers were implemented as device intended roles on a sink, so that when a stream with that role came in, we could enable the modifier, and disable it when such a stream ends. However, this doesn't account for switching the PCM on which playback is occurring. Should we be creating a separate sink for such modifiers (with lower priority, so they're not routed to unless there's a stream with the required role coming in)? Or should we be reopening the PCM for this? Finally, a question also related to modifiers -- is it expected that there will never be a case where a stream that requires no modifier is being played while a stream that does require a modifier also exists? If not, what kind of policy should we have for enabling the modifier or not? Cheers, Arun

5 13