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

[alsa-devel] [PATCH] Add PM support to the rme96 driver
by Knut Petersen 13 Aug '13

13 Aug '13

Hi everybody! The attached patch adds PM support to the rme96 driver, it should be applied after v2 of the patch adding pcm stream synchronization support posted on 2013-08-08. It does work perfectly here on an RME Digi96/8 PAD: After connecting analog output and analog input executing #! /bin/sh # arecord -D hw:0,0 -d 62 testout.wav & aplay -D hw:0,0 -d 60 testin.wav produces an almost perfect recording even when the test machine is suspended / hibernated and resumed several times. cu, Knut

2 2

[alsa-devel] [PATCH] ASoC: dapm: Ensure kcontrol list is initialised
by Mark Brown 13 Aug '13

13 Aug '13

From: Mark Brown <broonie(a)linaro.org> Ensure that the recently added path kcontrol list is initialised otherwise we may crash trying to delete routes that don't have kcontrols. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/soc-dapm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index b78eaa1..1e0e4ce 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -2357,6 +2357,7 @@ static int snd_soc_dapm_add_path(struct snd_soc_dapm_context *dapm, path->sink = wsink; path->connected = connected; INIT_LIST_HEAD(&path->list); + INIT_LIST_HEAD(&path->list_kcontrol); INIT_LIST_HEAD(&path->list_source); INIT_LIST_HEAD(&path->list_sink); -- 1.8.4.rc1

2 1

[alsa-devel] [PATCH] ASoC: dapm: Don't create routes when creating kcontrols
by Mark Brown 13 Aug '13

13 Aug '13

From: Mark Brown <broonie(a)linaro.org> Attempting to create the route as part of adding a mux control causes us to attempt to add the same route twice since we loop over all sources for the mux after creating the control. Instead do the addition in the callers. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/soc-dapm.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 662a904..b78eaa1 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -665,7 +665,7 @@ static int dapm_is_shared_kcontrol(struct snd_soc_dapm_context *dapm, * create it. Either way, add the widget into the control's widget list */ static int dapm_create_or_share_mixmux_kcontrol(struct snd_soc_dapm_widget *w, - int kci, struct snd_soc_dapm_path *path) + int kci) { struct snd_soc_dapm_context *dapm = w->dapm; struct snd_card *card = dapm->card->snd_card; @@ -766,7 +766,6 @@ static int dapm_create_or_share_mixmux_kcontrol(struct snd_soc_dapm_widget *w, return ret; w->kcontrols[kci] = kcontrol; - dapm_kcontrol_add_path(kcontrol, path); return 0; } @@ -790,9 +789,11 @@ static int dapm_new_mixer(struct snd_soc_dapm_widget *w) continue; } - ret = dapm_create_or_share_mixmux_kcontrol(w, i, path); + ret = dapm_create_or_share_mixmux_kcontrol(w, i); if (ret < 0) return ret; + + dapm_kcontrol_add_path(w->kcontrols[i], path); } } @@ -821,7 +822,7 @@ static int dapm_new_mux(struct snd_soc_dapm_widget *w) path = list_first_entry(&w->sources, struct snd_soc_dapm_path, list_sink); - ret = dapm_create_or_share_mixmux_kcontrol(w, 0, path); + ret = dapm_create_or_share_mixmux_kcontrol(w, 0); if (ret < 0) return ret; -- 1.8.4.rc1

2 1

[alsa-devel] [PATCH 1/2] ALSA: hda - Allow auto_mute_via_amp on bind mute controls
by Takashi Iwai 13 Aug '13

13 Aug '13

The auto-mute using the amp currently works only for a single amp on a pin. Make it working also with HDA_CTL_BIND_MUTE type, too. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_generic.c | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index f6c0344..6ed2209 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -816,6 +816,8 @@ static void resume_path_from_idx(struct hda_codec *codec, int path_idx) static int hda_gen_mixer_mute_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol); +static int hda_gen_bind_mute_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol); enum { HDA_CTL_WIDGET_VOL, @@ -833,7 +835,13 @@ static const struct snd_kcontrol_new control_templates[] = { .put = hda_gen_mixer_mute_put, /* replaced */ .private_value = HDA_COMPOSE_AMP_VAL(0, 3, 0, 0), }, - HDA_BIND_MUTE(NULL, 0, 0, 0), + { + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .info = snd_hda_mixer_amp_switch_info, + .get = snd_hda_mixer_bind_switch_get, + .put = hda_gen_bind_mute_put, /* replaced */ + .private_value = HDA_COMPOSE_AMP_VAL(0, 3, 0, 0), + }, }; /* add dynamic controls from template */ @@ -940,8 +948,8 @@ static int add_stereo_sw(struct hda_codec *codec, const char *pfx, } /* playback mute control with the software mute bit check */ -static int hda_gen_mixer_mute_put(struct snd_kcontrol *kcontrol, - struct snd_ctl_elem_value *ucontrol) +static void sync_auto_mute_bits(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) { struct hda_codec *codec = snd_kcontrol_chip(kcontrol); struct hda_gen_spec *spec = codec->spec; @@ -952,10 +960,22 @@ static int hda_gen_mixer_mute_put(struct snd_kcontrol *kcontrol, ucontrol->value.integer.value[0] &= enabled; ucontrol->value.integer.value[1] &= enabled; } +} +static int hda_gen_mixer_mute_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + sync_auto_mute_bits(kcontrol, ucontrol); return snd_hda_mixer_amp_switch_put(kcontrol, ucontrol); } +static int hda_gen_bind_mute_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + sync_auto_mute_bits(kcontrol, ucontrol); + return snd_hda_mixer_bind_switch_put(kcontrol, ucontrol); +} + /* any ctl assigned to the path with the given index? */ static bool path_has_mixer(struct hda_codec *codec, int path_idx, int ctl_type) { -- 1.8.3.1

1 1

[alsa-devel] [PATCH 1/3] ASoC: wm5102: Add inputs for noise and mic mixers
by Mark Brown 13 Aug '13

13 Aug '13

From: Mark Brown <broonie(a)linaro.org> The noise and mic mixer inputs were not connected, do so. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/codecs/wm5102.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index f38c52d..8bbddc1 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -1423,9 +1423,6 @@ static const struct snd_soc_dapm_route wm5102_dapm_routes[] = { { "Tone Generator 1", NULL, "TONE" }, { "Tone Generator 2", NULL, "TONE" }, - { "Mic Mute Mixer", NULL, "Noise Mixer" }, - { "Mic Mute Mixer", NULL, "Mic Mixer" }, - { "AIF1 Capture", NULL, "AIF1TX1" }, { "AIF1 Capture", NULL, "AIF1TX2" }, { "AIF1 Capture", NULL, "AIF1TX3" }, @@ -1552,6 +1549,9 @@ static const struct snd_soc_dapm_route wm5102_dapm_routes[] = { ARIZONA_MIXER_ROUTES("LHPF3", "LHPF3"), ARIZONA_MIXER_ROUTES("LHPF4", "LHPF4"), + ARIZONA_MIXER_ROUTES("Mic Mute Mixer", "Noise"), + ARIZONA_MIXER_ROUTES("Mic Mute Mixer", "Mic"), + ARIZONA_MUX_ROUTES("ASRC1L", "ASRC1L"), ARIZONA_MUX_ROUTES("ASRC1R", "ASRC1R"), ARIZONA_MUX_ROUTES("ASRC2L", "ASRC2L"), -- 1.8.4.rc1

1 2

[alsa-devel] [PATCH v2 0/2] ALSA: Implement core jack support for kcontrol
by Felipe F. Tonello 12 Aug '13

12 Aug '13

From: "Felipe F. Tonello" <eu(a)felipetonello.com> On this second version I made sure that the patch series can be bisected. Also, since HDA codec has it's own jack infrastructure, I just disabled the support of the core ALSA jack in it. Why? Because it's causing duplication of controls, although the input events works fine. A HDA codec developer might give us more information about it. Patch 1) Is the actual implementation and fixes for users that uses the API. Patch 2) Name fixes. Just to make sure no jack has " Jack" duplicated at the end of its name. Felipe F. Tonello (2): ALSA: Added jack detection KControl support ALSA: SoC: Fix jack names according new API include/sound/control.h | 2 +- include/sound/jack.h | 8 ++-- include/sound/soc.h | 2 +- sound/core/Kconfig | 1 + sound/core/ctljack.c | 15 ++++++- sound/core/jack.c | 88 +++++++++++++++++++++++++++++++++++--- sound/pci/hda/Kconfig | 8 ---- sound/pci/oxygen/xonar_wm87x6.c | 2 +- sound/soc/fsl/wm1133-ev1.c | 4 +- sound/soc/mid-x86/mfld_machine.c | 6 +-- sound/soc/omap/ams-delta.c | 2 +- sound/soc/omap/omap-abe-twl6040.c | 4 +- sound/soc/omap/omap-twl4030.c | 4 +- sound/soc/omap/rx51.c | 6 +-- sound/soc/pxa/hx4700.c | 4 +- sound/soc/pxa/palm27x.c | 4 +- sound/soc/pxa/ttc-dkb.c | 10 ++--- sound/soc/pxa/z2.c | 4 +- sound/soc/samsung/goni_wm8994.c | 7 +-- sound/soc/samsung/h1940_uda1380.c | 4 +- sound/soc/samsung/littlemill.c | 10 ++--- sound/soc/samsung/lowland.c | 6 +-- sound/soc/samsung/rx1950_uda1380.c | 4 +- sound/soc/samsung/smartq_wm8987.c | 4 +- sound/soc/samsung/speyside.c | 6 +-- sound/soc/samsung/tobermory.c | 4 +- sound/soc/soc-jack.c | 5 ++- sound/soc/tegra/tegra_alc5632.c | 4 +- sound/soc/tegra/tegra_rt5640.c | 4 +- sound/soc/tegra/tegra_wm8903.c | 8 ++-- 30 files changed, 163 insertions(+), 77 deletions(-) -- 1.8.3.1

4 13

[alsa-devel] [RFC PATCH] ASoC: omap-mcbsp: Add support for highter rate up to 384000
by Michael Trimarchi 12 Aug '13

12 Aug '13

Add support for highter rate up to 384000Khz. There are codecs in the market that can play up to this frequency. Test was done just with: #define OMAP_MCBSP_RATES (SNDRV_PCM_RATE_8000_192000) playing wav file 32bit/192000Khz stereo. Some glitch has observed but this should depend on the selected min buffer bytes that was left untouched in aplay and in the omap-pcm driver. Signed-off-by: Michael Trimarchi <michael(a)amarulasolutions.com> --- sound/soc/omap/omap-mcbsp.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 7483efb..1e95f6a 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -39,7 +39,9 @@ #include "mcbsp.h" #include "omap-mcbsp.h" -#define OMAP_MCBSP_RATES (SNDRV_PCM_RATE_8000_96000) +#define OMAP_MCBSP_RATES (SNDRV_PCM_RATE_8000_192000 | \ + SNDRV_PCM_RATE_CONTINUOUS | \ + SNDRV_PCM_RATE_KNOT) #define OMAP_MCBSP_SOC_SINGLE_S16_EXT(xname, xmin, xmax, \ xhandler_get, xhandler_put) \ @@ -574,11 +576,15 @@ static struct snd_soc_dai_driver omap_mcbsp_dai = { .channels_max = 16, .rates = OMAP_MCBSP_RATES, .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE, + .rate_min = 8000, + .rate_max = 384000, }, .capture = { .channels_min = 1, .channels_max = 16, .rates = OMAP_MCBSP_RATES, + .rate_min = 8000, + .rate_max = 384000, .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE, }, .ops = &mcbsp_dai_ops, -- 1.7.9.5

2 7

[alsa-devel] [PATCH 1/3] ASoC: dt: Move ALC5632 pin list from Tegra board binding to CODEC binding
by Mark Brown 12 Aug '13

12 Aug '13

From: Mark Brown <broonie(a)linaro.org> The pin list is the same for any board using the CODEC. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- .../devicetree/bindings/sound/alc5632.txt | 20 ++++++++++++++++++ .../bindings/sound/nvidia,tegra-audio-alc5632.txt | 24 ++-------------------- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/alc5632.txt b/Documentation/devicetree/bindings/sound/alc5632.txt index 8608f74..b913b74 100644 --- a/Documentation/devicetree/bindings/sound/alc5632.txt +++ b/Documentation/devicetree/bindings/sound/alc5632.txt @@ -13,6 +13,26 @@ Required properties: - #gpio-cells : Should be two. The first cell is the pin number and the second cell is used to specify optional parameters (currently unused). +Pins on the device (for linking into audio routes): + + * SPK_OUTP + * SPK_OUTN + * HP_OUT_L + * HP_OUT_R + * AUX_OUT_P + * AUX_OUT_N + * LINE_IN_L + * LINE_IN_R + * PHONE_P + * PHONE_N + * MIC1_P + * MIC1_N + * MIC2_P + * MIC2_N + * MICBIAS1 + * DMICDAT + + Example: alc5632: alc5632@1e { diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt index 05ffecb..8b8903e 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt @@ -11,28 +11,8 @@ Required properties: - nvidia,audio-routing : A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. Valid names for sources and - sinks are the ALC5632's pins: - - ALC5632 pins: - - * SPK_OUTP - * SPK_OUTN - * HP_OUT_L - * HP_OUT_R - * AUX_OUT_P - * AUX_OUT_N - * LINE_IN_L - * LINE_IN_R - * PHONE_P - * PHONE_N - * MIC1_P - * MIC1_N - * MIC2_P - * MIC2_N - * MICBIAS1 - * DMICDAT - - Board connectors: + sinks are the ALC5632's pins as documented in the binding for the device + and: * Headset Stereophone * Int Spk -- 1.8.4.rc1

2 3

Re: [alsa-devel] [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams
by Daniel Mack 12 Aug '13

12 Aug '13

On 12.08.2013 13:27, Jesus R wrote: > On Mon, Aug 12, 2013 at 4:52 AM, Daniel Mack <zonque(a)gmail.com > <mailto:zonque@gmail.com>> wrote: > Right now MPD supports DSD/DoP with one selectable on/off option. On > equals DoP output and off equals conversion to PCM. I'm not aware of any > case where it does not work. I would seem to me that there is one > predominant format? Let me clarify that again: I read the above as the two options are a) DSD material is augmented by DOP markers and send as such over a regular PCM interface, or b) convert DSD to PCM in software and then send PCM samples over a regular PCM interface. What applications need to use for my new approach is another is: c) take DSD samples, bit reverse them if necessary, and then send them over the generic DSD data pipe to the Linux kernel. Device-specific details are taken care of by the kernel layer. I'm not aware of any software that uses that new DSD format type directly except for my example program. Daniel

2 1

Re: [alsa-devel] [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams
by Daniel Mack 12 Aug '13

12 Aug '13

[please never drop people from the Cc: list but always use 'reply to all'!] On 12.08.2013 13:27, Jesus R wrote: > On Mon, Aug 12, 2013 at 4:52 AM, Daniel Mack <zonque(a)gmail.com > <mailto:zonque@gmail.com>> wrote: > Given than none of devices have a chance to report their capabilities to > the host, finding out which modes to use is a trial-and-error game, > unless you have access to the firmware sources. > > > Hence, please just look up the USB IDs and alternate interface settings > of your connected device with lsusb, and then augment the code in > snd_usb_interface_dsd_format_quirks() (file sound/usb/quirks.c) and play > around with different possibilities (bitreverse on/off, DSD_U8 vs > DSD_U16 etc). Follow the example that I provided in that function. > > Right now MPD supports DSD/DoP with one selectable on/off option. On > equals DoP output and off equals conversion to PCM. I'm not aware of any > case where it does not work. I would seem to me that there is one > predominant format? It's more complicated than that. Applications were always free to use a usual PCM stream and stuff it with DOP/DSD samples. This is the whole idea of DOP: allow applications to transport DSD samples via regular audio streams. The downside of this is that applications are in charge of adding the DOP markers manually, and information about bit-reversing and marker format (8 bit vs. 16 bit) is up to the application, which is not the right place for it. The patch series I brought in addressed this in a way that all that information about device-specific details is now known to the kernel, which can hence offer a standard compliant interface to userspace. [There's yet one more level of confusion as some file formats store the samples bit-reversed, but there's nothing we can do about that from kernel space except for defining a stable interface application have to obey to in order to be compatible. That is, samples are expected to always carry the oldest bit in the most significant bit of a byte.] So my question is: are you 100% sure that MPD uses the newly introduces ALSA formats, or are they doing the DOP conversion in manually in their own software layers? > You have to recompile and rmmod/insmod the snd-usb driver every time you > make a change, and then you need some sort of userspace tool to test it. > I published one here: > > This may be more than I can do. Can you add the options (bitreverse > on/off, DSD_U8 vs > DSD_U16 etc) to the alas-dsd-player? This would allow me to quickly test > the devices. There are #if0'ed blocks that you can opt-in for bit reversal, but as the marker format is different for 8 and 16 bits, and up to the kernel space now, the dsd player does not know about them. That was the entire intention of bringing that logic to kernel space in the first place. > Take a look at the DSD database so you can see what we are up against. I > could even add the tests results to the database. > https://docs.google.com/spreadsheet/ccc?key=0AgVhKcl_3lHfdFVyenBBNjNpQ2lieG… Nice list. Only devics with USB interface are interesting at this point, but that's a good start. As I said: you need to add the quirks for the devices to the quirks list. Other than that, there's no chance to test them. Copy'n pasting code inside that function and recompiling the kernel is really not as hard as you might think it is. Just search the internet for "compile kernel git <your-distribution-here>" and follow the links. Thanks, Daniel

2 1