September 2011 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] link between HDMI ELD and PCM devices
by David Henningsson 26 Sep '11

26 Sep '11

On 09/21/2011 03:20 PM, Pierre-Louis Bossart wrote: >> This won't work - in the case of several HDMI codecs (common with >> NVidia) there will be more than one "HDMI 0". > > No, the code doesn't use a constant, It's actually four constants, please see generic_hdmi_pcm_names in patch_hdmi.c. But my point is that this restarts from 0 on every codec. > it's assigned in the same way as the > device name. You would have HDMI 0, HDMI 1..4. I don't have this kind of > hardware, it'd be good if someone could verify that the name is indeed > dynamic. On a 3.0 based kernel, here's part of my aplay -l output: card 3: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: NVidia [HDA NVidia], device 7: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: NVidia [HDA NVidia], device 8: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: NVidia [HDA NVidia], device 9: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 >> The solution is to actually find the device number out, like this: >> >> struct hdmi_spec *spec = codec->spec; >> int pcmdev = spec->pcm_rec[pin_idx].device; > > That's what I wanted initially, but this device field is not > used/initialized, and like I said the device assignment comes after the pin > sensing and all the ELD handling A good place to do this is generic_hdmi_build_controls, both because it is normally used to add controls (which is what you do), and because it is triggered after the pcm device is assigned. (A side note to Takashi: for some reason hda-emu has the calls to build_controls and build_pcms switched, compared to the real implementation.) -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

4 6

[alsa-devel] [PATCH] ASoC: sdp4430: Fix string for FM input name
by Peter Ujfalusi 26 Sep '11

26 Sep '11

The name contains invalid valid character (/), which causes problems when trying to create the debugfs directory structure: ASoC: Failed to create Aux/FM Stereo In debugfs file Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/omap/sdp4430.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/omap/sdp4430.c b/sound/soc/omap/sdp4430.c index a951774..d462f1a 100644 --- a/sound/soc/omap/sdp4430.c +++ b/sound/soc/omap/sdp4430.c @@ -88,7 +88,7 @@ static const struct snd_soc_dapm_widget sdp4430_twl6040_dapm_widgets[] = { SND_SOC_DAPM_MIC("Headset Mic", NULL), SND_SOC_DAPM_HP("Headset Stereophone", NULL), SND_SOC_DAPM_SPK("Earphone Spk", NULL), - SND_SOC_DAPM_INPUT("Aux/FM Stereo In"), + SND_SOC_DAPM_INPUT("FM Stereo In"), }; static const struct snd_soc_dapm_route audio_map[] = { @@ -113,8 +113,8 @@ static const struct snd_soc_dapm_route audio_map[] = { {"Earphone Spk", NULL, "EP"}, /* Aux/FM Stereo In: AFML, AFMR */ - {"AFML", NULL, "Aux/FM Stereo In"}, - {"AFMR", NULL, "Aux/FM Stereo In"}, + {"AFML", NULL, "FM Stereo In"}, + {"AFMR", NULL, "FM Stereo In"}, }; static int sdp4430_twl6040_init(struct snd_soc_pcm_runtime *rtd) -- 1.7.6

3 4

Re: [alsa-devel] [PATCH] ASoC: Drop exporting ad1980_dai
by Mark Brown 26 Sep '11

26 Sep '11

On Sat, Sep 24, 2011 at 06:43:43PM +0800, Axel Lin wrote: > ad1980_dai is not used outside this driver, > thus drop exporting it. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] ASoC: Drop exporting sn95031_get_mic_bias
by Mark Brown 26 Sep '11

26 Sep '11

On Sat, Sep 24, 2011 at 06:16:15PM +0800, Axel Lin wrote: > sn95031_get_mic_bias() is not used outside this driver > and it is a static function now. > Thus drop exporting sn95031_get_mic_bias. Applied, thanks.

1 0

[alsa-devel] [PATCH] ASoC: omap-mcbsp: Fix compile time warning about ambiguous ‘else’
by Peter Ujfalusi 26 Sep '11

26 Sep '11

Fixes the following compile time warning: omap-mcbsp.c:519: warning: suggest explicit braces to avoid ambiguous ‘else’ Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/omap/omap-mcbsp.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 478d607..1391ea0 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -516,11 +516,12 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai, struct omap_mcbsp_reg_cfg *regs = &mcbsp_data->regs; int err = 0; - if (mcbsp_data->active) + if (mcbsp_data->active) { if (freq == mcbsp_data->in_freq) return 0; else return -EBUSY; + } /* The McBSP signal muxing functions are only available on McBSP1 */ if (clk_id == OMAP_MCBSP_CLKR_SRC_CLKR || -- 1.7.6.1

3 2

[alsa-devel] [PATCH 0/8] ASoC/MFD/Input: twl6040: Support for audio driven vibra
by Peter Ujfalusi 26 Sep '11

26 Sep '11

Hello, The following series adds support for the soc driver to route audio (PCM stream) to the vibra ports of the twl6040. We have ALSA controls for the vibra source selection (PDM, or Input/FF). The route can not be changed from Input/FF to PDM during ongoing effect coming from Input/FF. The Input/FF driver can not execute new effect, while the vibra source is configured to be PDM. TO get things working in legacy mode the omap-mcpdm, and twl6040 soc codec driver's channel count needed to be fixed. To minimize the need for reads through the I2C bus, the MFD driver will cache the vibra control registers. With this series we can route PCM audio to drive the twl6040 vibra output. In order to that we need to play 5 channel audio, and place the vibra sample at the 5th channel. This will change with ABE support (change == simplified). The series depends on the previous two from me: ASoC: twl6040: Cleanups and fixes ASoC: omap-mcpdm/twl6040: Offset cancellation Regards, Peter PS: Samuel, Dmitry, Liam: will it be possible to take this through Liam (via audio), since we are going to have dependencies coming via audio. --- Peter Ujfalusi (8): Input: twl6040: Simplify vibra regsiter definitions MFD: twl6040: Cache the vibra control registers MFD: twl6040: function to query the vibra status for clients Input: twl6040-vibra: Check the selected path for vibra ASoC: twl6040: Fix the number of channels for vibra ASoC: twl6040: Correct supported number of playback channels ASoC: omap-mcpdm: Correct the supported number of channels ASoC: twl6040: Support for vibra output paths drivers/input/misc/twl6040-vibra.c | 19 ++++++--- drivers/mfd/twl6040-core.c | 31 ++++++++++++-- include/linux/mfd/twl6040.h | 24 +++++------ sound/soc/codecs/twl6040.c | 78 ++++++++++++++++++++++++++++++++++- sound/soc/omap/omap-mcpdm.c | 14 ++++--- 5 files changed, 134 insertions(+), 32 deletions(-) -- 1.7.6.1

4 25

Re: [alsa-devel] Adding ELD control to alsa-lib hdmi device
by Raymond Yau 25 Sep '11

25 Sep '11

2011/9/24 Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>: > Hi, > Now that I almost done with exposing a read-only ELD control for HDA/HDMI > outputs, I was wondering how to read it from user-land. PulseAudio and > others rely on the 'hdmi' device, and apparently I can't access this new ELD > control, I have to use the 'hw:x,y' details. If you are using iface_pcm http://www.alsa-project.org/alsa-doc/alsa-lib/control_8c.html CTL interface use snd_ctl_open() to open "hw:x" or use alsactl store

1 0

[alsa-devel] [PATCH 0/3] Fallback mechanism for pulse plugin
by Takashi Iwai 25 Sep '11

25 Sep '11

Hi, the following are experimental patches for implementing the fallback option of PCM / control pulse plugin. When the connection to PA server fails, the plugin tries to open the fallback name. For achieving this, I added the new standard definition "sysdefault", which is equal with the normal "default" PCM / control definitions. The difference is only the name, i.e. it won't be overridden by other setups. Then two new API functions for opening a fallback PCM / control, and finally a patch for pulse-plugin will follow. All changes are relatively small and easy. Let me know if you have any suggestions or a better idea. thanks, Takashi

5 23

Re: [alsa-devel] [PATCH] ALSA: snd-aloop: make preallocated buffer size configurable
by Takashi Iwai 24 Sep '11

24 Sep '11

At Wed, 21 Sep 2011 10:02:27 -0500, Pierre-Louis Bossart wrote: > > > I meant to have a kconfig option to limit the upper-bound of pre-alloc > > buffer sizes for all drivers. That is, a patch like below (untested) > > That's a good idea, but the two patches aren't necessarily exclusive. In an > embedded solution you may want a 2s PCM buffer for low-power playback and a > 64k buffer for snd-aloop as it is only used with small periods. Also one > would need to check the buffer/period sizes in each driver, and make sure > they are smaller than this global max. Well, if it's only about snd-aloop, another option would be to use vmalloc'ed buffer for aloop. Since it's no hardware buffer, it's more system-friendly, and you don't need a pre-allocation. Again, an untested patch is below. thanks, Takashi --- diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c index a0da775..4067f15 100644 --- a/sound/drivers/aloop.c +++ b/sound/drivers/aloop.c @@ -575,7 +575,8 @@ static void loopback_runtime_free(struct snd_pcm_runtime *runtime) static int loopback_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { - return snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(params)); + return snd_pcm_lib_alloc_vmalloc_buffer(substream, + params_buffer_bytes(params)); } static int loopback_hw_free(struct snd_pcm_substream *substream) @@ -587,7 +588,7 @@ static int loopback_hw_free(struct snd_pcm_substream *substream) mutex_lock(&dpcm->loopback->cable_lock); cable->valid &= ~(1 << substream->stream); mutex_unlock(&dpcm->loopback->cable_lock); - return snd_pcm_lib_free_pages(substream); + return snd_pcm_lib_free_vmalloc_buffer(substream); } static unsigned int get_cable_index(struct snd_pcm_substream *substream) @@ -740,6 +741,8 @@ static struct snd_pcm_ops loopback_playback_ops = { .prepare = loopback_prepare, .trigger = loopback_trigger, .pointer = loopback_pointer, + .page = snd_pcm_lib_get_vmalloc_page, + .mmap = snd_pcm_lib_mmap_vmalloc, }; static struct snd_pcm_ops loopback_capture_ops = { @@ -751,6 +754,8 @@ static struct snd_pcm_ops loopback_capture_ops = { .prepare = loopback_prepare, .trigger = loopback_trigger, .pointer = loopback_pointer, + .page = snd_pcm_lib_get_vmalloc_page, + .mmap = snd_pcm_lib_mmap_vmalloc, }; static int __devinit loopback_pcm_new(struct loopback *loopback, @@ -771,10 +776,6 @@ static int __devinit loopback_pcm_new(struct loopback *loopback, strcpy(pcm->name, "Loopback PCM"); loopback->pcm[device] = pcm; - - snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_CONTINUOUS, - snd_dma_continuous_data(GFP_KERNEL), - 0, 2 * 1024 * 1024); return 0; }

2 2

[alsa-devel] [PATCH] ALSA: HDA: No power nids on 92HD93
by David Henningsson 24 Sep '11

24 Sep '11

This patch is necessary to make internal speakers work on this chip. Cc: stable(a)kernel.org BugLink: http://bugs.launchpad.net/bugs/854468 Tested-by: Alex Wolfson <alex.wolfson(a)canonical.com> Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_sigmatel.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 1b7c114..987e3cf 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -5630,6 +5630,7 @@ again: switch (codec->vendor_id) { case 0x111d76d1: case 0x111d76d9: + case 0x111d76df: case 0x111d76e5: case 0x111d7666: case 0x111d7667: -- 1.7.5.4

2 1