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

[alsa-devel] i8253 locking and PC speaker on non-{mips,x86}
by Ralf Baechle 28 May '11

28 May '11

No longer terribly relevant these days but ... drivers/input/misc/pcspkr.c: #if defined(CONFIG_MIPS) || defined(CONFIG_X86) /* Use the global PIT lock ! */ #include <asm/i8253.h> #else #include <asm/8253pit.h> static DEFINE_RAW_SPINLOCK(i8253_lock); #endif sound/drivers/pcsp/pcsp.h: #if defined(CONFIG_MIPS) || defined(CONFIG_X86) /* Use the global PIT lock ! */ #include <asm/i8253.h> #else #include <asm/8253pit.h> static DEFINE_RAW_SPINLOCK(i8253_lock); $ git grep -F pcsp.h sound/drivers/pcsp sound/drivers/pcsp/pcsp.c:#include "pcsp.h" sound/drivers/pcsp/pcsp_input.c:#include "pcsp.h" sound/drivers/pcsp/pcsp_lib.c:#include "pcsp.h" sound/drivers/pcsp/pcsp_mixer.c:#include "pcsp.h" $ git grep -w i8253_lock sound/drivers/pcsp/ sound/drivers/pcsp/pcsp.h:static DEFINE_RAW_SPINLOCK(i8253_lock); sound/drivers/pcsp/pcsp_input.c: raw_spin_lock_irqsave(&i8253_lock, flags sound/drivers/pcsp/pcsp_input.c: raw_spin_unlock_irqrestore(&i8253_lock, sound/drivers/pcsp/pcsp_lib.c: raw_spin_lock_irqsave(&i8253_lock, flags sound/drivers/pcsp/pcsp_lib.c: raw_spin_unlock_irqrestore(&i8253_lock, sound/drivers/pcsp/pcsp_lib.c: raw_spin_lock(&i8253_lock); sound/drivers/pcsp/pcsp_lib.c: raw_spin_unlock(&i8253_lock); sound/drivers/pcsp/pcsp_lib.c: raw_spin_lock(&i8253_lock); sound/drivers/pcsp/pcsp_lib.c: raw_spin_unlock(&i8253_lock); Locks are great, everybody should have their own lock! $ find . -name 8253pit.h ./arch/powerpc/include/asm/8253pit.h ./arch/alpha/include/asm/8253pit.h $ cat arch/*/include/asm/8253pit.h /* * 8253/8254 Programmable Interval Timer */ /* * 8253/8254 Programmable Interval Timer */ $ Eh... $ git grep -w PCSPKR_PLATFORM arch/mips/Kconfig: select PCSPKR_PLATFORM arch/mips/Kconfig: select PCSPKR_PLATFORM arch/mips/Kconfig: select PCSPKR_PLATFORM arch/powerpc/platforms/amigaone/Kconfig: select PCSPKR_PLATFORM drivers/input/misc/Kconfig: depends on PCSPKR_PLATFORM init/Kconfig:config PCSPKR_PLATFORM sound/drivers/Kconfig: depends on PCSPKR_PLATFORM && X86 && HIGH_RES_TIMERS So works on MIPS and x86. Compiles on PowerPC but locking is wrong. On Alpha can't even be selected though it sees otherwise right except the locking and even worse for the rest. Ralf

2 1

[alsa-devel] HDA HDMI pin to converter mapping
by Stephen Warren 27 May '11

27 May '11

Most cards supported by patch_hdmi.c have the property of a 1:1 mapping or connection between converter widgets and pin widgets. Hence, patch_hdmi.c sets up a PCM for each converter, and occasionally performs some operations on the pin widget as required. However, some new cards don't have this 1:1 mapping. In particular, the new GeForce GT 520 and many future NVIDIA cards, and at least the Intel Ibex Peak (in my wife's laptop), have more pin widgets than converters, and each pin widget has a mux to select which converter to take the audio from. For pretty pictures, see the 4th (and 3rd) diagrams at: ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.ht… I'd like to discuss how best to handle such cards. I'd expect to see a PCM device created for each pin widget. This would create a 1:1 mapping between PCM devices and attached monitors and hence ELD data (with the possible exception of DisplayPort 1.2 daisy-chaining; I have no idea yet how that plays into this). Does this seem like a reasonable approach to everyone? The current situation is that we only create a PCM for each converter that is mux'd to a pin by default HW initialization. On both the GeForce 520 and Ibex Peak, this means that only 1 PCM gets created, since all pin widgets' muxes point at the first converter by default. This: a) Doesn't allow usage of both converters at once, since there's only 1 PCM object. b) Ends up with up to 4 (in NVIDIA's case) pin widgets (and hence ELD information) logically associated with the PCM object. Hence, it'll be confusing for application to know what features they can really use on the PCM. In fact, ALSA actually only enforces the ELD of the first pin associated with the converter, and ignores the rest. The basic mechanics of a-PCM-per-pin would require hdmi_pcm_open to look at the list of converters, find one not in use by a stream, and then dynamically associate the converter with the stream, or fail the open if a converter was not available. We'd also need a custom close or cleanup function to "unassign" the converter from the PCM, and set hda_pcm_stream.nid to an invalid value. That might be easiest to implement if hda_pcm_stream.nid were to refer to the pin widget rather than the converter widget. However, I notice that some core code in hda_codec.c would be confused by this, so perhaps we'd better just have have hdmi_pcm_open use some other way to determine which stream object is associated with the pin. I suppose that it'd be pretty easy to set up a mapping from hda_pcm_stream to pin nid as part of generic_hdmi_build_pcms. As an aside, this rather reminds me of the mux'ing that goes on inside codecs controlled by ASoC, although I don't think we need to expose this muxing to user-space in the case, but instead make it automatic as I outlined above. Thanks for any thoughts. -- nvpublic

3 8

[alsa-devel] [PATCH] ASoC: Fix wm_hubs input PGA ZC bits
by Mark Brown 27 May '11

27 May '11

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm_hubs.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/wm_hubs.c b/sound/soc/codecs/wm_hubs.c index e55b298..9e370d1 100644 --- a/sound/soc/codecs/wm_hubs.c +++ b/sound/soc/codecs/wm_hubs.c @@ -215,23 +215,23 @@ static const struct snd_kcontrol_new analogue_snd_controls[] = { SOC_SINGLE_TLV("IN1L Volume", WM8993_LEFT_LINE_INPUT_1_2_VOLUME, 0, 31, 0, inpga_tlv), SOC_SINGLE("IN1L Switch", WM8993_LEFT_LINE_INPUT_1_2_VOLUME, 7, 1, 1), -SOC_SINGLE("IN1L ZC Switch", WM8993_LEFT_LINE_INPUT_1_2_VOLUME, 7, 1, 0), +SOC_SINGLE("IN1L ZC Switch", WM8993_LEFT_LINE_INPUT_1_2_VOLUME, 6, 1, 0), SOC_SINGLE_TLV("IN1R Volume", WM8993_RIGHT_LINE_INPUT_1_2_VOLUME, 0, 31, 0, inpga_tlv), SOC_SINGLE("IN1R Switch", WM8993_RIGHT_LINE_INPUT_1_2_VOLUME, 7, 1, 1), -SOC_SINGLE("IN1R ZC Switch", WM8993_RIGHT_LINE_INPUT_1_2_VOLUME, 7, 1, 0), +SOC_SINGLE("IN1R ZC Switch", WM8993_RIGHT_LINE_INPUT_1_2_VOLUME, 6, 1, 0), SOC_SINGLE_TLV("IN2L Volume", WM8993_LEFT_LINE_INPUT_3_4_VOLUME, 0, 31, 0, inpga_tlv), SOC_SINGLE("IN2L Switch", WM8993_LEFT_LINE_INPUT_3_4_VOLUME, 7, 1, 1), -SOC_SINGLE("IN2L ZC Switch", WM8993_LEFT_LINE_INPUT_3_4_VOLUME, 7, 1, 0), +SOC_SINGLE("IN2L ZC Switch", WM8993_LEFT_LINE_INPUT_3_4_VOLUME, 6, 1, 0), SOC_SINGLE_TLV("IN2R Volume", WM8993_RIGHT_LINE_INPUT_3_4_VOLUME, 0, 31, 0, inpga_tlv), SOC_SINGLE("IN2R Switch", WM8993_RIGHT_LINE_INPUT_3_4_VOLUME, 7, 1, 1), -SOC_SINGLE("IN2R ZC Switch", WM8993_RIGHT_LINE_INPUT_3_4_VOLUME, 7, 1, 0), +SOC_SINGLE("IN2R ZC Switch", WM8993_RIGHT_LINE_INPUT_3_4_VOLUME, 6, 1, 0), SOC_SINGLE_TLV("MIXINL IN2L Volume", WM8993_INPUT_MIXER3, 7, 1, 0, inmix_sw_tlv), -- 1.7.5.1

2 1

[alsa-devel] [PATCH] ASoC: Tegra: Enable Kaen HP_MUTE at boot
by Stephen Warren 27 May '11

27 May '11

We want the default state of the HP_MUTE signal to be asserted, so that the headphones are muted before the first audio playback. Without this, the headphones are left unmuted until shortly after the first audio playback completes. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/tegra/tegra_wm8903.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/tegra/tegra_wm8903.c b/sound/soc/tegra/tegra_wm8903.c index 0d6738a..a42e9ac 100644 --- a/sound/soc/tegra/tegra_wm8903.c +++ b/sound/soc/tegra/tegra_wm8903.c @@ -267,7 +267,7 @@ static int tegra_wm8903_init(struct snd_soc_pcm_runtime *rtd) } machine->gpio_requested |= GPIO_HP_MUTE; - gpio_direction_output(pdata->gpio_hp_mute, 0); + gpio_direction_output(pdata->gpio_hp_mute, 1); } if (gpio_is_valid(pdata->gpio_int_mic_en)) { -- 1.7.0.4

3 2

[alsa-devel] [PATCH] ASoC: Fix dapm_is_shared_kcontrol so everything isn't shared
by Stephen Warren 27 May '11

27 May '11

Commit af46800 ("ASoC: Implement mux control sharing") introduced function dapm_is_shared_kcontrol. When this function returns true, the naming of DAPM controls is derived from the kcontrol_new. Otherwise, the name comes from the widget (and possibly a widget's naming prefix). A bug in the implementation of dapm_is_shared_kcontrol made it return 1 in all cases. Hence, that commit caused a change in control naming for all controls instead of just shared controls. Specifically, a control is always considered shared because it is always compared against itself. Solve this by never comparing against the widget containing the control being created. Equally, controls should never be shared between DAPM contexts; when the same codec is instantiated multiple times, the same kcontrol_new will be used. However, the control should no be shared between the multiple instances. I tested that with the Tegra WM8903 driver: * Shared is now mostly 0 as expected, and sometimes 1. * The expected controls are still generated after this change. However, I don't have any systems that have a widget/control naming prefix, so I can't test that aspect. Thanks for Jarkko Nikula for pointing out how to fix this. v2: * Don't share across DAPM contexts. * Changed to Tested-by tag below for Jarkko. Reported-by: Liam Girdwood <lrg(a)ti.com> Tested-by: Jarkko Nikula <jhnikula(a)gmail.com> Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/soc-dapm.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 456617e..10bb49b 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -325,6 +325,7 @@ static int dapm_connect_mixer(struct snd_soc_dapm_context *dapm, } static int dapm_is_shared_kcontrol(struct snd_soc_dapm_context *dapm, + struct snd_soc_dapm_widget *kcontrolw, const struct snd_kcontrol_new *kcontrol_new, struct snd_kcontrol **kcontrol) { @@ -334,6 +335,8 @@ static int dapm_is_shared_kcontrol(struct snd_soc_dapm_context *dapm, *kcontrol = NULL; list_for_each_entry(w, &dapm->card->widgets, list) { + if (w == kcontrolw || w->dapm != kcontrolw->dapm) + continue; for (i = 0; i < w->num_kcontrols; i++) { if (&w->kcontrol_news[i] == kcontrol_new) { if (w->kcontrols) @@ -468,7 +471,7 @@ static int dapm_new_mux(struct snd_soc_dapm_context *dapm, return -EINVAL; } - shared = dapm_is_shared_kcontrol(dapm, &w->kcontrol_news[0], + shared = dapm_is_shared_kcontrol(dapm, w, &w->kcontrol_news[0], &kcontrol); if (kcontrol) { wlist = kcontrol->private_data; -- 1.7.0.4

4 3

[alsa-devel] UCM representation questions
by Stephen Warren 27 May '11

27 May '11

Liam, I have a few more questions how to represent things in UCM. The Tegra boards I'm dealing with are set up like this: hw:0,0 >--wm8903--> headphones \---> speakers hw:0,1 >----------> hdmi The WM8903 allows the audio stream to be routed to neither, one, or both of headphones and speakers. hw:0,0 <--wm8903--< Analog Mic (AMIC) \----< Digital Mic (DMIC) The WM8903 can capture from one or the other or AMIC/DMIC, but not both. 1) How to indicate when certain devices can be used together, or are mutually exclusive? Note that Headphone/Speakers/HDMI can be used in any combination, but AMIC/DMIC are mutually exclusive. use_case.h indicates that neither Devices nor Modifiers are mutually exclusive, so neither alone can be used to represent this. I suppose you could just create a separate use-case for each legal set of combinations. Taking a capture-only case, we'd end up with separate "Capture AMIC" and "Capture DMIC" cases. However, a "HiFi" or "Music" case could simply list all 3 devices in a single case since they all can operate at once. 2) Let's then consider a "VoIP" use-case that wants to both play and capture audio. If we represent the exclusivity in the same way, we'd end up with 2 more cases "VoIP AMIC" and "VoIP DMIC", each listing 3 devices for playback, and 1 device for capture. It seems like switching between these two cases while a call was active would be problematic. In particular, in my current UCM files, there is e.g.: SectionDevice."Speakers".0 { Comment "Internal Speakers" EnableSequence [ cdev "hw:0" cset "name='Speaker Switch' on,on" cset "name='Int Spk Switch' on" ] DisableSequence [ cdev "hw:0" cset "name='Speaker Switch' off,off" cset "name='Int Spk Switch' off" ] ... Wouldn't the DisableSequence get run for this device when leaving the "VoIP AMIC" case, and the EnableSequence get run when entering the "VoIP DMIC" case; that would cause a glitch in the receive side of the call even though we were just switching the transmission side between mics. Perhaps the UCM library is intelligent enough to realize that the same device is active in both the old and new case, and then doesn't execute the Enable/DisableSequence in that case. But, that seems dangerous; the sequences might have required effects in some case. I can't omit the DisableSequence to make this work, or disabling the Speakers device (e.g. to switch to just headphones) wouldn't actually disable anything. I suppose I could put the Speaker disable logic in the Headphone EnableSequence, but then I wouldn't be able to use both together. Perhaps the answer is a "virtual" Device "Speakers and Headphones" which enables both. I couldn't correctly represent the device-specific volume controls or PCMs then. Plus, this approach would quickly lead to an explosion of Devices; 8 SectionDevices in my the case of my 3 physical IOs. 3) It seems like there's a lot of potential for duplication in the UCM file content. If I have "VoIP Low Quality", "VoIP High Quality", and "Hifi" cases, the latter with a modifier to allow capture of voice e.g. for voice commands, and each somehow supporting capture from either AMIC or DMIC (ignoring how to represent mutual exclusivity) then the UCM file for each case has to include the cset actions to switch between AMIC and DMIC: SectionDevice."Capture AMIC".0 { Comment "Analog Microphone Jack" EnableSequence [ cdev "hw:0" cset "name='ADC Input' 'ADC'" cset "name='Left Capture Mux' 'Right'" cset "name='Right Capture Mux' 'Right'" ] ... SectionDevice."Capture DMIC".0 { Comment "Internal Digital Microphone" EnableSequence [ cdev "hw:0" cset "name='ADC Input' 'DMIC'" cset "name='Left Capture Mux' 'Left'" cset "name='Right Capture Mux' 'Right'" ] ... Is there any way to avoid this cut/paste? I initially expected the UCM file format defining Devices outside of Verbs, and Verbs to list which devices were associated with the verb by reference rather than inclusion, and perhaps also configuring some additional properties of those devices, but not duplicating the raw "how to route this device to the PCM" instructions. 4) Is listing multiple CaptureVolumes in a single Device's Value section legal. For example, for a stereo analog mic: SectionModifier."Capture AMIC".0 { Comment "Analog Microphone Jack" Value { CaptureVolume "Left Input PGA Volume" CaptureVolume "Right Input PGA Volume" } } ... since the WM8903 exposes separate controls for the L/R channels, and I'd expect applications would want to expose a single control to users, and set them both to the same value all the time. Thanks again for any answers. -- nvpublic

3 6

[alsa-devel] [PATCH 1/4] ASoC: Convert 16x16 write to use cpu_to_be16()
by Mark Brown 27 May '11

27 May '11

Make it clear what we're doing. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-cache.c | 10 ++++------ 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/sound/soc/soc-cache.c b/sound/soc/soc-cache.c index 06b7b81..abdf8d1 100644 --- a/sound/soc/soc-cache.c +++ b/sound/soc/soc-cache.c @@ -277,14 +277,12 @@ static unsigned int snd_soc_16_16_read(struct snd_soc_codec *codec, static int snd_soc_16_16_write(struct snd_soc_codec *codec, unsigned int reg, unsigned int value) { - u8 data[4]; + u16 data[2]; - data[0] = (reg >> 8) & 0xff; - data[1] = reg & 0xff; - data[2] = (value >> 8) & 0xff; - data[3] = value & 0xff; + data[0] = cpu_to_be16(reg); + data[1] = cpu_to_be16(value); - return do_hw_write(codec, reg, value, data, 4); + return do_hw_write(codec, reg, value, data, sizeof(data)); } /* Primitive bulk write support for soc-cache. The data pointed to by -- 1.7.5.1

2 4

[alsa-devel] Suspecting a bug in plugin_ops.h
by Soulard, MathieuX 27 May '11

27 May '11

Hi all, I'm using alsalib and I checked its code because of one issue I have. I did not yet solved my issue, but I think I saw a bug in alsa-lib that I would like to share with you. It is located in [alsa-lib]/src/pcm/plugin_ops.h in the inline function sx24s(). static inline u_int32_t sx24s(u_int32_t x) { if(x&0x00008000) return x|0x000000FF; return x&0xFFFFFF00; } I think that 0x00008000 should be replaced by 0x00000800. Thanks Regards Mathieu

2 2

[alsa-devel] OMAP3530 -- Only One Sound Card allowed for Power Suspension process?
by Philip Chu 26 May '11

26 May '11

Hi all, I have a crash with power suspend to RAM using following command: echo mem > /sys/power/state It shows following message and hangs up: Freezing user space processes ... (elapsed 0.02 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) And I found out the place to cause this trouble is, I have two sound cards registered in my module init function through: platform_device_alloc("soc-audio", -1); // Beagle board sound card and platform_device_alloc("soc-audio", 0); // my own sound card or platform_device_alloc("soc-audio", 0); and platform_device_alloc("soc-audio", 1); If I don't register the 2nd card or register the 2nd with another name, e.g., "soc-myaudio", it can pass power suspension, but it cannot be recognized by soc_driver in soc-core.c, which is using the name "soc-audio" . Anybody knows how I can register two sound cards and still pass power suspension? Philip Chu principal software engineer LogicPD www.logicpd.com 5 Clock Tower Place, Suite 215 Maynard, MA 01754 Phone: 978-243-2450 Fax: 978-461-1598

1 1

Re: [alsa-devel] alsa patch for Fantom G
by Jaroslav Kysela 26 May '11

26 May '11

On Tue, 29 Mar 2011, Axel Schmidt wrote: > Hello, > > I do not know if I make this request to the right person. > > I've seen a simple patch that should make the Roland Fantom G working. > http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg23584.html > This patch is more then 2 years old. Is there any way to integrate this > patch into the official alsa? Clemens, does the patch looks reasonable? Anyway, the right list for patch posting is the alsa-devel mailing list. Jaroslav ----- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.

3 2