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

[alsa-devel] [PATCH 1/2] ASoC: sta32x: Use devm_gpiod_get_optional appropriate place
by Axel Lin 09 May '15

09 May '15

devm_gpiod_get_optional() is equivalent to devm_gpiod_get(), except that when no GPIO was assigned to the requested function it will return NULL. This is convenient for drivers that need to handle optional GPIOs. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/sta32x.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/sound/soc/codecs/sta32x.c b/sound/soc/codecs/sta32x.c index 033b7d9..847fb20 100644 --- a/sound/soc/codecs/sta32x.c +++ b/sound/soc/codecs/sta32x.c @@ -1095,16 +1095,10 @@ static int sta32x_i2c_probe(struct i2c_client *i2c, #endif /* GPIOs */ - sta32x->gpiod_nreset = devm_gpiod_get(dev, "reset"); - if (IS_ERR(sta32x->gpiod_nreset)) { - ret = PTR_ERR(sta32x->gpiod_nreset); - if (ret != -ENOENT && ret != -ENOSYS) - return ret; - - sta32x->gpiod_nreset = NULL; - } else { - gpiod_direction_output(sta32x->gpiod_nreset, 0); - } + sta32x->gpiod_nreset = devm_gpiod_get_optional(dev, "reset", + GPIOD_OUT_LOW); + if (IS_ERR(sta32x->gpiod_nreset)) + return PTR_ERR(sta32x->gpiod_nreset); /* regulators */ for (i = 0; i < ARRAY_SIZE(sta32x->supplies); i++) -- 2.1.0

1 1

[alsa-devel] PreSonus Information For Developers
by Karl Swisher 09 May '15

09 May '15

Hello all, I have what might be useful information to some developers but I do not sure who or how to contact the right people. I recently purchased a PreSonus StudioLive AI 32.4.2 mixer. Have it half way working under Linux. This mixer has a network connection in addition to the firewire interface. I've installed their software under VirtualBox and ran tcpflow capturing packet content between the computer and the mixer. I have started creating text files of the packets of which below is an example of their software performing functions like the mixer booting, backing up, restore, and selecting the digital output channels 33 through 48. 55 43 00 01 06 00 4b 41 65 00 64 00 55 43 00 01 06 00 4b 41 65 00 64 00 55 43 00 01 06 00 4b 41 65 00 64 00 55 43 00 01 06 00 4b 41 65 00 64 00 55 43 00 01 06 00 4b 41 65 00 64 00 55 43 00 01 06 00 4b 41 65 00 64 00 55 43 00 01 06 00 4b 41 65 00 64 00 55 43 00 01 1d 00 46 52 65 00 64 00 01 00 Listpresets/scene 00 00 55 43 00 01 1b 00 46 52 65 00 64 00 01 00 Listpresets/channel 00 00 55 43 00 01 19 00 46 52 65 00 64 00 01 00 Listpresets/geq 00 00 55 43 00 01 19 00 46 52 65 00 64 00 01 00 Listpresets/reverb 00 00 I'm trying to separate out the bin code from the text. Does anyone here know if there is value in this information or anyone that might want it? Have a few functions decoded in the format above. Thanks Karl

2 1

Re: [alsa-devel] Front speakers doesn't work in multichannel output, regression in ALC888
by Raymond Yau 09 May '15

09 May '15

> > > > http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixe > > > > r/paths/analog-output-headphones.conf > > > > > > > > pulseaudio mute external center/lfe controls when headphone jack is > > > > plugged > > That would be unwanted. > This is common to all notebook using headphone jack and two other jacks to support surround51 or surround71 since pulseaudio mute the other retasked mio jack when headphone jack is plugged > > > > I used hdajackretask to override: > > > PIN ID: 0x15 to "Line out (front)" > https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/patch/sound/pc… When the static model were used, the jack was configured as line out instead of headphone jack and there is no headphone playback volume -static const struct hda_verb alc888_acer_aspire_4930g_verbs[] = { -/* Enable unsolicited event for HP jack */ - {0x15, AC_VERB_SET_UNSOLICITED_ENABLE, ALC_HP_EVENT | AC_USRSP_EN}, -/* Connect HP out to front */ - {0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, - {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE}, - {0x15, AC_VERB_SET_CONNECT_SEL, 0x00}, - {0x15, AC_VERB_SET_EAPD_BTLENABLE, 2}, -static const struct snd_kcontrol_new alc888_acer_aspire_4930g_mixer[] = { - HDA_CODEC_VOLUME("Front Playback Volume", 0x0c, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("Front Playback Switch", 0x0c, 2, HDA_INPUT), The jack is configured as headphone jack after the auto parser is used > > Pulseaudio don't know node 0x15 is headphone / Line Out (External > speaker) > > > > select speaker profile mute the headphone playback switch > > Doesn't HP mean HeadPhone? Isn't solution to my problem obvious, namely add > Line out capability to 0x15? > > Are there any side effect if you change the headphone jack to Line Out jack as the jack no longer enable HP amp ? use add_out_jack_modes for create Headphone/Line Out jack mode control to change Headphone to Line Out and vice versa diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index 3d2597b..f25cd23 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -180,10 +180,10 @@ static void parse_user_hints(struct hda_codec *codec) /* the following two are just for compatibility */ val = snd_hda_get_bool_hint(codec, "add_out_jack_modes"); if (val >= 0) - spec->add_jack_modes = !!val; + spec->add_out_jack_modes = !!val; val = snd_hda_get_bool_hint(codec, "add_in_jack_modes"); if (val >= 0) spec->add_jack_modes = !!val; @@ -2640,7 +2642,7 @@ static void get_jack_mode_name(struct hda_codec *codec, hda_nid_t pin, static int get_out_jack_num_items(struct hda_codec *codec, hda_nid_t pin) { struct hda_gen_spec *spec = codec->spec; - if (spec->add_jack_modes) { + if (spec->add_out_jack_modes || spec->add_jack_modes) { unsigned int pincap = snd_hda_query_pin_caps(codec, pin); if ((pincap & AC_PINCAP_OUT) && (pincap & AC_PINCAP_HP_DRV)) return 2; @@ -4892,7 +4895,7 @@ int snd_hda_gen_parse_auto_config(struct hda_codec *codec, return err; } - if (spec->add_jack_modes) { + if (spec->add_out_jack_modes || spec->add_jack_modes) { if (cfg->line_out_type != AUTO_PIN_SPEAKER_OUT) { err = create_out_jack_modes(codec, cfg->line_outs, cfg->line_out_pins); diff --git a/sound/pci/hda/hda_generic.h b/sound/pci/hda/hda_generic.h index 56e4139..8d7568b 100644 --- a/sound/pci/hda/hda_generic.h +++ b/sound/pci/hda/hda_generic.h @@ -227,6 +227,8 @@ struct hda_gen_spec { unsigned int prefer_hp_amp:1; /* enable HP amp for speaker if any */ unsigned int add_stereo_mix_input:2; /* add aamix as a capture src */ unsigned int add_jack_modes:1; /* add i/o jack mode enum ctls */ + unsigned int add_out_jack_modes:1; unsigned int power_down_unused:1; /* power down unused widgets */ unsigned int dac_min_mute:1; /* minimal = mute for DACs */

1 0

[alsa-devel] [PATCH 1/3] ASoC: rt5645: fix add missing widget
by Bard Liao 08 May '15

08 May '15

"IF1 DAC0" and "IF1 DAC3" are used in rt5645_dapm_routes but missing in rt5645_dapm_widgets. Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> Signed-off-by: Bard Liao <bardliao(a)realtek.com> --- sound/soc/codecs/rt5645.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c index 7996c9c..a72d989 100644 --- a/sound/soc/codecs/rt5645.c +++ b/sound/soc/codecs/rt5645.c @@ -1697,8 +1697,10 @@ static const struct snd_soc_dapm_widget rt5645_dapm_widgets[] = { /* Digital Interface */ SND_SOC_DAPM_SUPPLY("I2S1", RT5645_PWR_DIG1, RT5645_PWR_I2S1_BIT, 0, NULL, 0), + SND_SOC_DAPM_PGA("IF1 DAC0", SND_SOC_NOPM, 0, 0, NULL, 0), SND_SOC_DAPM_PGA("IF1 DAC1", SND_SOC_NOPM, 0, 0, NULL, 0), SND_SOC_DAPM_PGA("IF1 DAC2", SND_SOC_NOPM, 0, 0, NULL, 0), + SND_SOC_DAPM_PGA("IF1 DAC3", SND_SOC_NOPM, 0, 0, NULL, 0), SND_SOC_DAPM_MUX("RT5645 IF1 DAC1 L Mux", SND_SOC_NOPM, 0, 0, &rt5645_if1_dac0_tdm_sel_mux), SND_SOC_DAPM_MUX("RT5645 IF1 DAC1 R Mux", SND_SOC_NOPM, 0, 0, -- 1.8.1.1.439.g50a6b54

5 15

Re: [alsa-devel] [PATCH] ASoC: bt-sco: Add devicetree support for bt-sco codec
by Mark Brown 08 May '15

08 May '15

On Tue, May 05, 2015 at 10:15:41PM +0200, Marek Belisko wrote: > +static const struct of_device_id bt_sco_codec_of_match[] = { > + { .compatible = "delta,dfbmcs320", }, > + { .compatible = "linux,bt-sco", }, Is there any burning reason for adding the linux,bt-sco compatible?

2 2

Re: [alsa-devel] [PATCH 2/2] ASoC: rt5645: improve headphone depop function
by Mark Brown 08 May '15

08 May '15

On Fri, May 08, 2015 at 01:53:34PM +0800, John Lin wrote: > We add a calibration function and call it at the beginning of > i2c_probe. The calibration value will be kept until codec is > shutdown. We will reset the codec after the calibration is finished. > So, we set cache_bypass in the calibration function. The benefit is > we can shorter the delay time in headphone depop. This looks fine but seems to depend on the previous patch.

1 0

Re: [alsa-devel] [PATCH 1/2] ASoC: rt5645: fix jack type detect error
by Mark Brown 08 May '15

08 May '15

On Fri, May 08, 2015 at 01:53:33PM +0800, John Lin wrote: > rt5645_jack_detect doesn't report the correct jack type consistently. > This patch can make it more stable. Can you be more specific about what the problem is and how this fixes it pleased? It's a bit hard to review based on your changelog.

1 0

[alsa-devel] [PATCH] ASoC: rt5677: Add DMIC ASRC detect function
by Oder Chiou 08 May '15

08 May '15

The patch adds DMIC ASRC detect function to dominate whether the DMIC ASRC enable or not. Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> --- sound/soc/codecs/rt5677.c | 81 +++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 75 insertions(+), 6 deletions(-) diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index 685e268..8bb7be8 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -1230,6 +1230,75 @@ int rt5677_sel_asrc_clk_src(struct snd_soc_codec *codec, } EXPORT_SYMBOL_GPL(rt5677_sel_asrc_clk_src); +static int rt5677_dmic_use_asrc(struct snd_soc_dapm_widget *source, + struct snd_soc_dapm_widget *sink) +{ + struct snd_soc_codec *codec = snd_soc_dapm_to_codec(source->dapm); + struct rt5677_priv *rt5677 = snd_soc_codec_get_drvdata(codec); + unsigned int asrc_setting; + + switch (source->shift) { + case 11: + regmap_read(rt5677->regmap, RT5677_ASRC_5, &asrc_setting); + asrc_setting = (asrc_setting & RT5677_AD_STO1_CLK_SEL_MASK) >> + RT5677_AD_STO1_CLK_SEL_SFT; + if (asrc_setting >= RT5677_CLK_SEL_I2S1_ASRC && + asrc_setting <= RT5677_CLK_SEL_I2S6_ASRC) + return 1; + break; + + case 10: + regmap_read(rt5677->regmap, RT5677_ASRC_5, &asrc_setting); + asrc_setting = (asrc_setting & RT5677_AD_STO2_CLK_SEL_MASK) >> + RT5677_AD_STO2_CLK_SEL_SFT; + if (asrc_setting >= RT5677_CLK_SEL_I2S1_ASRC && + asrc_setting <= RT5677_CLK_SEL_I2S6_ASRC) + return 1; + break; + + case 9: + regmap_read(rt5677->regmap, RT5677_ASRC_5, &asrc_setting); + asrc_setting = (asrc_setting & RT5677_AD_STO3_CLK_SEL_MASK) >> + RT5677_AD_STO3_CLK_SEL_SFT; + if (asrc_setting >= RT5677_CLK_SEL_I2S1_ASRC && + asrc_setting <= RT5677_CLK_SEL_I2S6_ASRC) + return 1; + break; + + case 8: + regmap_read(rt5677->regmap, RT5677_ASRC_5, &asrc_setting); + asrc_setting = (asrc_setting & RT5677_AD_STO4_CLK_SEL_MASK) >> + RT5677_AD_STO4_CLK_SEL_SFT; + if (asrc_setting >= RT5677_CLK_SEL_I2S1_ASRC && + asrc_setting <= RT5677_CLK_SEL_I2S6_ASRC) + return 1; + break; + + case 7: + regmap_read(rt5677->regmap, RT5677_ASRC_6, &asrc_setting); + asrc_setting = (asrc_setting & RT5677_AD_MONOL_CLK_SEL_MASK) >> + RT5677_AD_MONOL_CLK_SEL_SFT; + if (asrc_setting >= RT5677_CLK_SEL_I2S1_ASRC && + asrc_setting <= RT5677_CLK_SEL_I2S6_ASRC) + return 1; + break; + + case 6: + regmap_read(rt5677->regmap, RT5677_ASRC_6, &asrc_setting); + asrc_setting = (asrc_setting & RT5677_AD_MONOR_CLK_SEL_MASK) >> + RT5677_AD_MONOR_CLK_SEL_SFT; + if (asrc_setting >= RT5677_CLK_SEL_I2S1_ASRC && + asrc_setting <= RT5677_CLK_SEL_I2S6_ASRC) + return 1; + break; + + default: + break; + } + + return 0; +} + /* Digital Mixer */ static const struct snd_kcontrol_new rt5677_sto1_adc_l_mix[] = { SOC_DAPM_SINGLE("ADC1 Switch", RT5677_STO1_ADC_MIXER, @@ -3087,12 +3156,12 @@ static const struct snd_soc_dapm_widget rt5677_dapm_widgets[] = { }; static const struct snd_soc_dapm_route rt5677_dapm_routes[] = { - { "Stereo1 DMIC Mux", NULL, "DMIC STO1 ASRC", can_use_asrc }, - { "Stereo2 DMIC Mux", NULL, "DMIC STO2 ASRC", can_use_asrc }, - { "Stereo3 DMIC Mux", NULL, "DMIC STO3 ASRC", can_use_asrc }, - { "Stereo4 DMIC Mux", NULL, "DMIC STO4 ASRC", can_use_asrc }, - { "Mono DMIC L Mux", NULL, "DMIC MONO L ASRC", can_use_asrc }, - { "Mono DMIC R Mux", NULL, "DMIC MONO R ASRC", can_use_asrc }, + { "Stereo1 DMIC Mux", NULL, "DMIC STO1 ASRC", rt5677_dmic_use_asrc }, + { "Stereo2 DMIC Mux", NULL, "DMIC STO2 ASRC", rt5677_dmic_use_asrc }, + { "Stereo3 DMIC Mux", NULL, "DMIC STO3 ASRC", rt5677_dmic_use_asrc }, + { "Stereo4 DMIC Mux", NULL, "DMIC STO4 ASRC", rt5677_dmic_use_asrc }, + { "Mono DMIC L Mux", NULL, "DMIC MONO L ASRC", rt5677_dmic_use_asrc }, + { "Mono DMIC R Mux", NULL, "DMIC MONO R ASRC", rt5677_dmic_use_asrc }, { "I2S1", NULL, "I2S1 ASRC", can_use_asrc}, { "I2S2", NULL, "I2S2 ASRC", can_use_asrc}, { "I2S3", NULL, "I2S3 ASRC", can_use_asrc}, -- 1.8.1.1.439.g50a6b54

2 1

Re: [alsa-devel] [PATCH RFC v2 10/13] sound/core: add DRM ELD helper
by Russell King - ARM Linux 08 May '15

08 May '15

On Fri, May 08, 2015 at 04:16:08PM +0300, Jyri Sarha wrote: > On 2015-04-02 12:22, Russell King wrote: > >+static const unsigned int eld_rates[] = { > >+ 32000, > >+ 44100, > >+ 48000, > >+ 88200, > >+ 96000, > >+ 176400, > >+ 192000, > >+}; > >+ > > For what I can see, you are setting the cross dependency between > the sample rate and channels incorrectly. There is a dependency between sample rate and channels. > You should look for the > currently tested channel count directly from hw params. I'm not so sure that's right after looking at snd_ac97_pcm_double_rate_rules(). That's pretty much the same problem - AC'97 codecs can operate at a sample rate of either the bus frame frequency or twice the bus frame frequency. They achieve twice the bus frame frequency by reallocating a couple of the PCM data slots which would otherwise be used for >2 channels to the first two channels, thus allowing two front channel samples per frame. AC'97 limits the number of channels to two if: if (rate->min > 48000) { and limits the sample rate to 1-48kHz if: if (channels->min > 2) { > From this side the dependency is missing all together. Yes, it I initially couldn't work out how to do that bit... but I have a solution now which seems to sort-of work. Testing with aplay, I find that it seems to mostly work, and I guess that: aplay -D hw:0,0 -v -f S24_LE -c 6 -r 192000 /dev/zero resulting in: Playing raw data '/dev/zero' : Signed 24 bit Little Endian, Rate 192000 Hz, Channels 6 Warning: rate is not accurate (requested = 192000Hz, got = 48000Hz) please, try the plug plugin Hardware PCM card 0 'DW-HDMI' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S24_LE subformat : STD channels : 6 rate : 48000 exact rate : 48000 (48000/1) is acceptable. Also looking at AC'97, I don't need to list the same parameter as a dependent of the rule... something I'll try when I'm back from the hospital later this afternoon... -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.

2 1

Re: [alsa-devel] [PATCH RFC v2 10/13] sound/core: add DRM ELD helper
by Russell King - ARM Linux 08 May '15

08 May '15

On Fri, May 08, 2015 at 01:56:02PM +0300, Jyri Sarha wrote: > On 2015-04-05 20:26, Russell King - ARM Linux wrote: > >On Sun, Apr 05, 2015 at 06:46:13PM +0200, Takashi Iwai wrote: > >>At Sun, 5 Apr 2015 17:20:34 +0100, > >>Russell King - ARM Linux wrote: > >>> Since (afaik) ALSA has a lack of support for dynamic reconfiguration > >>> according to the attached device changing, the best we can do without > >>> a huge amount of re-work of HDMI support across all adapters is to > >>> process the capabilities of the attached device at prepare time > >>> according to the current capabilities. > >> > >>Yeah, reconfiguration is tricky. BTW, how is the HDMI unplug handled > >>during playback? > > > >We don't handle it right now - and we don't have any notification to > >the audio drivers that that has happened. Even if we did have such a > >notification, I'm not sure what the audio driver could do with it at > >the moment. > > > >>> Implementing dynamic reconfiguration in ALSA is not something I want to > >>> get involved with, and as we /already/ have HDMI support merged in the > >>> kernel, this is not a blocker for at least trying to get some semblence > >>> of sanity, rather than having every driver re-implementing stuff like > >>> this. > >> > >>Well, I didn't mean about the dynamic reconfiguration. I thought of > >>rather min/max pairs, but it was just a wrong assumption. Scratch > >>it. > >> > >>One another question: don't we need to deal with the sample bits in > >>sad[2]? > > > >It should, but I'm very wary about doing that without seeing more > >examples of real SADs. > > If the same constraint setting helpers are to be used also with > external HDMI encoders with i2s interface, there should be an option > to leave out the constraints for the sample bits. There is no direct > connection between the number of bits on I2S and HDMI link. The CPU > DAI may apply its own constraints on the available sample formats and > too strict constraints at the encoder end may lead to zero available > formats. Possibly, but then how do we know which SAD to apply to limit the number of channels? I suspect for the use case you're suggesting above, it's better left to the user rather than generic code to work it out otherwise things get far too complex. We'd need to have some way for the driver to report back to this generic code the actual number of bits on the HDMI link. However, as we currently know, ALSA appears to have a problem here which pretty much makes properly restricting the channels and sample rates impossible to do. That issue is the one I'm much more keen to solve right now, because without that being solved, this set of patches is pretty much dead in the water. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.

1 0