August 2010 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Device name hints and the value of DEV
by Anssi Hannula 03 Aug '10

03 Aug '10

Hi all! I was confused as to why on one of my boxes "aplay -L" says hdmi:CARD=NVidia,DEV=0 and on another it says hdmi:CARD=NVidia I looked into it, and saw that namehint.c:add_card() loops through the pcm device numbers using snd_ctl_pcm_next_device(), and then proceeds in try_config() to append ',DEV=device_number' to the device name. However, in reality DEV does not match the device number, as e.g. DEV=0 may mean the '0' in HDA-Intel.pcm.hdmi.0, and the slave pcm of that is device 3, not device 0. If there is no device 0 on the NVidia card, the 'hdmi:CARD=NVidia,DEV=0' entry is never added (instead the one without ",DEV=0" is), even though these are not really related.. Now, I don't have a good understanding of all the code in namehint.c, but surely the occupied device numbers should not have any side-effects like this? -- Anssi Hannula

1 0

[alsa-devel] Rates/formats available upstream from the plug plugin
by Pavel Hofman 03 Aug '10

03 Aug '10

Hi, mplayer checks hw_params for availability of the current format http://mplayer-ww.git.sourceforge.net/git/gitweb.cgi?p=mplayer-ww/mplayer-w… . If the check fails, it uses 16bits as fixed default. Now if we define the card to be plughw:0, the check still fails for formats unsupported directly by the card. Which in fact is incorrect since the plug plugin takes care of most formats known. The same holds for sample rates. IMO either the plug plugin should reconfigure hw_params for upstream use, or mplayer should use a different API call for checking parameters of the actual alsa device (not just the hardware itself, as defined by its alsa driver) - which one? Thanks a lot, Pavel.

3 5

[alsa-devel] ASoC DaVinci voicecodec based on copyfromuser
by Raffaele Recalcati 03 Aug '10

03 Aug '10

In dm365 cpu it is not possible to run CQ93VC Voice Codec together with McBSP I2S peripheral, because they share the same dma event. With this patchset it is possible to run the CQ93VC Voice Codec using copyfromuser.

2 7

Re: [alsa-devel] Driver for AK4555 codec
by Mark Brown 03 Aug '10

03 Aug '10

On 29 Jul 2010, at 23:45, Yoran Brondsema <yoran.brondsema(a)gmail.com> wrote: > On 29 July 2010 20:42, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > On Thu, Jul 29, 2010 at 09:18:43AM +0200, Yoran Brondsema wrote: Don't drop CCs to the mailing lists; if nothing else advice is often useful to other people searching the mailing list archives. > So my main question is whether I have to write this lpc3xxx-ak4555.c. It would be great if someone could clear me up on this. Yes, you'll have to write a driver for your machine. It says how the CODEC and CPU are wired up on your particular board - either component could also be used with another device, or another machine may have a different way of connecting the same components which requires a different setup.

2 2

[alsa-devel] [RFC 0/2] soc-dapm or TWL4030: Runtime DAPM ordering problem
by Peter Ujfalusi 03 Aug '10

03 Aug '10

Hello Mark, Liam, I'm facing the following problem with the TWL4030 codec: The order of DAPM register write order different in case, when I start a capture operation after setting up the routing, and when I change the routing during active capture. This is really visible, when I want to record from the digital microphone interface. Because of this ordering problem, when during active capture I switch to the digital mic from analog path, the codec would enable analog bias (2.2 volts) to the digital mic for a moment, and than later it will switch to the correct digital mic bias (1.8 volts). Since the twl4030 codec needs several bits in different registers to be changed, when I change between analog and digital input it is not that obvious how to get the correct ordering all the time. I have two different ways to fix this: A: by reordering how DAPM would handle control changes (patch 1) B: by changing TWL4030 internal DAPM widgets (patch 2) Obviously only one of the two patch is needed, and I'm really not sure if the change in soc-dapm is a correct one, since it will affect all codec driver, and could potentially cause unexpected glitches. Some more thoughts.. A: Reordering in soc-dapm. Currently this is how it works: A.1 Route setup, followed by capture - User selects the digimic0 interface (DAPM_MUX_E) ADCMICSEL: TX1IN_SEL->1 MUX_E(TX1 Capture Route) enum register selects digital path MICBIAS_CTL: MICBIAS1_CTL->1 MUX_E(TX1 Capture Route) POST_REG select digimic bias (1.8 volts) - Capture starts MICBIAS_CTL: MICBIAS1_EN->1 MICBIAS(Mic Bias 1) power enables the micbias1/digimic0 bias (1.8 volts) ADCMICSEL: DIGIMIC0_EN->1 PGA_E(Digimic0 Enable) power enable the digimic0 interface A.2 Changing from analog path to digital path during capture - User selects the digimic0 interface from analog source AVADC_CTL: ADCL_EN->0 PGA(ADC Physical Left) power turn off ADC left ANAMICL: MICAMPL_EN->0 MIXER(Analog Left) power turn off mic amp on analog path MICBIAS_CTL: MICBIAS1_EN->1 MICBIAS(Mic Bias 1) power enables the micbias1/digimic0 bias (2.2 volts) ADCMICSEL: DIGIMIC0_EN->1 PGA(Digimic0 Enable) power enable the digimic0 interface ADCMICSEL: TX1IN_SEL->1 MUX_E(TX1 Capture Route) enum register selects digital path MICBIAS_CTL: MICBIAS1_CTL->1 MUX_E(TX1 Capture Route) POST_REG select digimic bias (1.8 volts) With the reordering in soc-dapm, only the runtime order is going to change: A.2 ADCMICSEL: TX1IN_SEL->1 MUX_E(TX1 Capture Route) enum register selects digital path MICBIAS_CTL: MICBIAS1_CTL->1 MUX_E(TX1 Capture Route) POST_REG select digimic bias (1.8 volts) AVADC_CTL: ADCL_EN->0 PGA(ADC Physical Left) power turn off ADC left ANAMICL: MICAMPL_EN->0 MIXER(Analog Left) power turn off mic amp on analog path MICBIAS_CTL: MICBIAS1_EN->1 MICBIAS(Mic Bias 1) power enables the micbias1/digimic0 bias (1.8 volts) ADCMICSEL: DIGIMIC0_EN->1 PGA(Digimic0 Enable) power enable the digimic0 interface So first DAPM would do the change in the register, than goes on and check the needed things to be done in the DAPM tree. This works with the TWL codec, but I'm not sure what are the implication on other codecs. But from the ordering point of view now there is no difference between 'cold start' or runtime change in DAPM write sequence. B: Reordering in TWL4030 codec driver The sequence will look like this: B.1 Route setup, followed by capture - User selects the digimic0 interface (DAPM_MUX_E) ADCMICSEL: TX1IN_SEL->1 MUX(TX1 Capture Route) enum register selects digital path - Capture starts MICBIAS_CTL: MICBIAS1_CTL->1 SUPPLY(micbias1 select) power select digimic bias (1.8 volts) MICBIAS_CTL: MICBIAS1_EN->1 MICBIAS(Mic Bias 1) power enables the micbias1/digimic0 bias (1.8 volts) ADCMICSEL: DIGIMIC0_EN->1 PGA_E(Digimic0 Enable) power enable the digimic0 interface B.2 Changing from analog path to digital path during capture - User selects the digimic0 interface from analog source AVADC_CTL: ADCL_EN->0 PGA(ADC Physical Left) power turn off ADC left ANAMICL: MICAMPL_EN->0 MIXER(Analog Left) power turn off mic amp on analog path MICBIAS_CTL: MICBIAS1_CTL->1 SUPPLY(micbias1 select) power select digimic bias (1.8 volts) MICBIAS_CTL: MICBIAS1_EN->1 MICBIAS(Mic Bias 1) power enables the micbias1/digimic0 bias (1.8 volts) ADCMICSEL: DIGIMIC0_EN->1 PGA(Digimic0 Enable) power enable the digimic0 interface ADCMICSEL: TX1IN_SEL->1 MUX(TX1 Capture Route) enum register selects digital path In this case the order is still not the same, but at least I avoid feeding wrong bias to the digimic interface. I need either the soc-dapm.c patch _or_ the patch against twl4030 codec to solve my problem. Do you see another way to actually solve this problem? Which approach is acceptable for you? The series generated on top of (needs th previous TWL DAPM fix): git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git:for-2.6.36 Thank you, Peter --- Peter Ujfalusi (2): ASoC: soc-dapm: Reorder DAPM register write sequence ASoC: TWL4030: Capture route runtime DAPM ordering fix sound/soc/codecs/twl4030.c | 48 +++++++++++--------------------------------- sound/soc/soc-dapm.c | 41 ++++++++++++++++++++++-------------- 2 files changed, 37 insertions(+), 52 deletions(-) -- 1.7.2

2 9

[alsa-devel] [PATCH 1/2] ASoC: multi-component - Fix DAI ID scanning from device name
by Jarkko Nikula 03 Aug '10

03 Aug '10

Format string specifier ".%d" for sscanf cannot scan integer from a string "driver-name.123". Fix this by starting the scan from a position after "driver-name". Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- Liam. This is a trivial fix. No need for separate patch, just embed to your next multi-component update. I noticed this because dai->id in mcbsp_dai_probe was always zero. --- sound/soc/soc-core.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 5c10439..300a9b3 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2803,7 +2803,7 @@ static inline char *fmt_single_name(struct device *dev, int *id) found = strstr(name, dev->driver->name); if (found) { /* get ID */ - if (sscanf(found,".%d", id) == 1) { + if (sscanf(&found[strlen(dev->driver->name)], ".%d", id) == 1) { /* discard ID from name if ID == -1 */ if (*id == -1) -- 1.7.1

2 2

[alsa-devel] Bug 0005086 - no audio on built-in speakers (intel-hda with codec alc272)
by Pierre van Heerden 03 Aug '10

03 Aug '10

Hi I was advised to e-mail and inform you of the problem with my audio, even though I have submitted a tracker<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5086>. In short, no speaker_outs are being reported by the driver (intel-hda using the realtek alc272 codec), even in the latest release, so on my laptop (LG X130) I'm getting audio on the line-out jack but not on the built-in speakers. I've tried all the model= module parameters for the alc272 codec, none of them solved the problem. Please let me know if I can be of any assistance in solving this problem or if you need any further information from me. Kind regards Pierre van Heerden

1 0

[alsa-devel] [PATCH 0/2] ALSA: hda - support HDMI HBR passthrough
by Anssi Hannula 03 Aug '10

03 Aug '10

Hi all! This patchset adds support for passing through IEC 61937 encapsulated compressed audio at high bitrates (i.e. those over 6.144Mbps). At least TrueHD and DTS-HD are such formats. I've tested this using an NVIDIA hdmi codec and the following ffmpeg patch which adds support for TrueHD in its IEC 61937 muxer: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-August/094317.html One needs to set the AES0 & 0x02 (non-audio) bit during playback so that the data is not transmitted as normal 8 channel PCM audio. --- Anssi Hannula (2): ALSA: hda - Set Stream Type in Stream Format according to AES0 ALSA: hda - Add support for HDMI HBR passthrough sound/pci/hda/hda_codec.c | 6 ++++- sound/pci/hda/hda_codec.h | 6 ++++- sound/pci/hda/hda_intel.c | 3 +- sound/pci/hda/patch_hdmi.c | 40 ++++++++++++++++++++++++++++++++++++++- sound/pci/hda/patch_intelhdmi.c | 3 +- sound/pci/hda/patch_nvhdmi.c | 3 +- 6 files changed, 53 insertions(+), 8 deletions(-)

2 5

[alsa-devel] ASoC updates for 2.6.36
by Mark Brown 03 Aug '10

03 Aug '10

The following changes since commit 988b0dc1547f9f6a7c8cae472cad0a55df31818c: Merge branch 'for-2.6.36' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6 into topic/asoc (2010-08-02 12:10:52 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.36 Axel Lin (12): ASoC: ad1836: fix a memory leak if another ad1836 is registered ASoC: ak4642: fix a memory leak if failed to initialise AK4642 ASoC: da7210: fix a memory leak if failed to initialise da7210 audio codec ASoC: wm8523: fix resource reclaim in wm8523_register error path ASoC: wm8711: fix a memory leak if another WM8711 is registered ASoC: wm8904: fix resource reclaim in wm8904_register error path ASoC: wm8940: fix a memory leak if wm8940_register return error ASoC: wm8955: fix resource reclaim in wm8955_register error path ASoC: wm8961: fix resource reclaim in wm8961_register error path ASoC: wm8974: fix a memory leak if another WM8974 is registered ASoC: wm8978: fix a memory leak if a wm8978_register fail ASoC: wm9081: fix resource reclaim in wm9081_register error path Ian Lartey (1): ASoC: Initial WM8741 CODEC driver sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/ad1836.c | 1 + sound/soc/codecs/ak4642.c | 4 +- sound/soc/codecs/da7210.c | 8 +- sound/soc/codecs/wm8523.c | 10 +- sound/soc/codecs/wm8711.c | 3 +- sound/soc/codecs/wm8741.c | 579 +++++++++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/wm8741.h | 214 +++++++++++++++++ sound/soc/codecs/wm8904.c | 13 +- sound/soc/codecs/wm8940.c | 7 +- sound/soc/codecs/wm8955.c | 10 +- sound/soc/codecs/wm8961.c | 9 +- sound/soc/codecs/wm8974.c | 3 +- sound/soc/codecs/wm8978.c | 10 +- sound/soc/codecs/wm9081.c | 11 +- 16 files changed, 857 insertions(+), 31 deletions(-) create mode 100644 sound/soc/codecs/wm8741.c create mode 100644 sound/soc/codecs/wm8741.h

2 1

[alsa-devel] [PATCH] hda-emu: Include stdlib.h, needed for calloc
by David Henningsson 03 Aug '10

03 Aug '10

-- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 1