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

Re: [alsa-devel] linux-next: Tree for Oct 20 (sound/soc/intel)
by Randy Dunlap 21 Oct '15

21 Oct '15

On 10/19/15 22:26, Stephen Rothwell wrote: > Hi all, > > Changes since 20151019: > on x86_64: when CONFIG_DW_DMAC is not enabled. sound/built-in.o: In function `sst_dma_new': (.text+0xd7b38): undefined reference to `dw_dma_probe' sound/built-in.o: In function `sst_dma_free': (.text+0xd7c0a): undefined reference to `dw_dma_remove' Full randconfig file is attached. -- ~Randy

2 1

[alsa-devel] [PATCH 00/18] ALSA: Add helper function to add single value constraint
by Lars-Peter Clausen 21 Oct '15

21 Oct '15

Apologies if you got this series twice, forgot to Cc the mailinglist on the first try. This series introduces a new helper function which can be used to constrain a configuration parameter to a single. So far the recommended and most efficient way to do this was to set a min-max constraint with the same value for minimum and maximum. It is not necessarily immediately obvious though that this is the right way to do things and some driver have come up with different ways to achieve the same effect, e.g. by installing a list constraint with a single item. This is less efficient since list constraints are dynamic constraints which needed to be re-evaluated multiple times at runtime while a min-max constraint is a static constraint. The function introduced in this patch series is called snd_pcm_hw_constraint_single() which hopefully is semantically more expressive and makes it clear that this is the function to use when setting a single value constraint. All existing drivers that want to set a single value constraint are update to use the new helper function. - Lars Lars-Peter Clausen (18): ALSA: Add helper function to add single value constraint ALSA: korg1212: Use snd_pcm_hw_constraint_single() ALAA: lx6464es: Use snd_pcm_hw_constraint_single() ALSA: rme32: Use snd_pcm_hw_constraint_single() ALSA: rme96: Use snd_pcm_hw_constraint_single() ALSA: rme9652: Use snd_pcm_hw_constraint_single() ASoC: adav80x: Use snd_pcm_hw_constraint_single() ASoC: twl4030: Use snd_pcm_hw_constraint_single() ASoC: uda134x: Use snd_pcm_hw_constraint_single() ASoC: wl1273: Use snd_pcm_hw_constraint_single() ASoC: n810: Use snd_pcm_hw_constraint_single() ASoC: rx51: Use snd_pcm_hw_constraint_single() ASoC: pcm: Use snd_pcm_hw_constraint_single() ASoC: ux500: Use snd_pcm_hw_constraint_single() ASoC: bytcr_rt5640: Use snd_pcm_hw_constraint_single() ASoC: cht_bsw_max98090: Use snd_pcm_hw_constraint_single() ASoC: cht_bsw_rt5645: Use snd_pcm_hw_constraint_single() ASoC: cht_bsw_rt5672: Use snd_pcm_hw_constraint_single() include/sound/pcm.h | 16 ++++++++++++++++ sound/pci/korg1212/korg1212.c | 8 +++++--- sound/pci/lx6464es/lx6464es.c | 4 ++-- sound/pci/rme32.c | 4 ++-- sound/pci/rme96.c | 8 ++++---- sound/pci/rme9652/hdspm.c | 9 ++++----- sound/soc/codecs/adav80x.c | 4 ++-- sound/soc/codecs/twl4030.c | 13 +++++-------- sound/soc/codecs/uda134x.c | 6 ++---- sound/soc/codecs/wl1273.c | 9 ++++----- sound/soc/intel/boards/bytcr_rt5640.c | 14 ++------------ sound/soc/intel/boards/cht_bsw_max98090_ti.c | 14 ++------------ sound/soc/intel/boards/cht_bsw_rt5645.c | 14 ++------------ sound/soc/intel/boards/cht_bsw_rt5672.c | 14 ++------------ sound/soc/omap/n810.c | 3 +-- sound/soc/omap/rx51.c | 3 +-- sound/soc/soc-pcm.c | 10 ++++------ sound/soc/ux500/ux500_msp_dai.c | 4 ++-- 18 files changed, 62 insertions(+), 95 deletions(-) -- 2.1.4

5 24

[alsa-devel] [PATCH v4] ASoC: rt5645: Add the HW EQ for the customized speaker output of Google Celes
by Oder Chiou 21 Oct '15

21 Oct '15

Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> --- include/sound/rt5645.h | 2 + sound/soc/codecs/rt5645.c | 103 +++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 104 insertions(+), 1 deletion(-) diff --git a/include/sound/rt5645.h b/include/sound/rt5645.h index a5cf615..efa9f08 100644 --- a/include/sound/rt5645.h +++ b/include/sound/rt5645.h @@ -23,6 +23,8 @@ struct rt5645_platform_data { unsigned int jd_mode; /* Invert JD when jack insert */ bool jd_invert; + /* Speaker HWEQ */ + bool hweq; }; #endif diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c index 4d54999..6809d1c 100644 --- a/sound/soc/codecs/rt5645.c +++ b/sound/soc/codecs/rt5645.c @@ -42,6 +42,8 @@ #define RT5645_PR_BASE (RT5645_PR_RANGE_BASE + (0 * RT5645_PR_SPACING)) +#define RT5645_HWEQ_NUM 57 + static const struct regmap_range_cfg rt5645_ranges[] = { { .name = "PR", @@ -224,6 +226,11 @@ static const struct reg_default rt5645_reg[] = { { 0xff, 0x6308 }, }; +struct rt5645_eq_param_s { + unsigned short reg; + unsigned short val; +}; + static const char *const rt5645_supply_names[] = { "avdd", "cpvdd", @@ -240,6 +247,7 @@ struct rt5645_priv { struct snd_soc_jack *btn_jack; struct delayed_work jack_detect_work; struct regulator_bulk_data supplies[ARRAY_SIZE(rt5645_supply_names)]; + struct rt5645_eq_param_s *eq_param; int codec_type; int sysclk; @@ -477,6 +485,49 @@ static const DECLARE_TLV_DB_RANGE(spk_clsd_tlv, 7, 7, TLV_DB_SCALE_ITEM(228, 0, 0) ); +static int rt5645_hweq_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + uinfo->type = SNDRV_CTL_ELEM_TYPE_BYTES; + uinfo->count = RT5645_HWEQ_NUM * sizeof(struct rt5645_eq_param_s); + + return 0; +} + +static int rt5645_hweq_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_component *component = snd_kcontrol_chip(kcontrol); + struct rt5645_priv *rt5645 = snd_soc_component_get_drvdata(component); + char *p = ucontrol->value.bytes.data; + + if (rt5645->pdata.hweq) + memcpy(p, rt5645->eq_param, + RT5645_HWEQ_NUM * sizeof(struct rt5645_eq_param_s)); + + return 0; +} + +static int rt5645_hweq_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_component *component = snd_kcontrol_chip(kcontrol); + struct rt5645_priv *rt5645 = snd_soc_component_get_drvdata(component); + char *p = ucontrol->value.bytes.data; + + if (rt5645->pdata.hweq) + memcpy(rt5645->eq_param, p, + RT5645_HWEQ_NUM * sizeof(struct rt5645_eq_param_s)); + + return 0; +} + +#define RT5645_HWEQ(xname) \ +{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \ + .info = rt5645_hweq_info, \ + .get = rt5645_hweq_get,\ + .put = rt5645_hweq_put } + static const struct snd_kcontrol_new rt5645_snd_controls[] = { /* Speaker Output Volume */ SOC_DOUBLE("Speaker Channel Switch", RT5645_SPK_VOL, @@ -541,6 +592,7 @@ static const struct snd_kcontrol_new rt5645_snd_controls[] = { /* I2S2 function select */ SOC_SINGLE("I2S2 Func Switch", RT5645_GPIO_CTRL1, RT5645_I2S2_SEL_SFT, 1, 1), + RT5645_HWEQ("Speaker HWEQ"), }; /** @@ -631,6 +683,31 @@ static int is_using_asrc(struct snd_soc_dapm_widget *source, } +static bool rt5645_validate_hweq(unsigned short reg) +{ + if ((reg >= 0x1a4 && reg <= 0x1cd) | (reg >= 0x1e5 && reg <= 0x1f8) | + (reg == RT5645_EQ_CTRL2)) + return true; + + return false; +} + +static int rt5645_enable_hweq(struct snd_soc_codec *codec) +{ + struct rt5645_priv *rt5645 = snd_soc_codec_get_drvdata(codec); + int i; + + for (i = 0; i < RT5645_HWEQ_NUM; i++) { + if (rt5645_validate_hweq(rt5645->eq_param[i].reg)) + regmap_write(rt5645->regmap, rt5645->eq_param[i].reg, + rt5645->eq_param[i].val); + else + break; + } + + return 0; +} + /** * rt5645_sel_asrc_clk_src - select ASRC clock source for a set of filters * @codec: SoC audio codec device. @@ -1532,9 +1609,12 @@ static int rt5645_spk_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) { struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm); + struct rt5645_priv *rt5645 = snd_soc_codec_get_drvdata(codec); switch (event) { case SND_SOC_DAPM_POST_PMU: + if (rt5645->pdata.hweq) + rt5645_enable_hweq(codec); snd_soc_update_bits(codec, RT5645_PWR_DIG1, RT5645_PWR_CLS_D | RT5645_PWR_CLS_D_R | RT5645_PWR_CLS_D_L, @@ -1543,6 +1623,8 @@ static int rt5645_spk_event(struct snd_soc_dapm_widget *w, break; case SND_SOC_DAPM_PRE_PMD: + if (rt5645->pdata.hweq) + snd_soc_write(codec, RT5645_EQ_CTRL2, 0); snd_soc_update_bits(codec, RT5645_PWR_DIG1, RT5645_PWR_CLS_D | RT5645_PWR_CLS_D_R | RT5645_PWR_CLS_D_L, 0); @@ -3060,6 +3142,11 @@ static int rt5645_probe(struct snd_soc_codec *codec) snd_soc_dapm_sync(dapm); } + if (rt5645->pdata.hweq) + rt5645->eq_param = devm_kzalloc(codec->dev, + RT5645_HWEQ_NUM * sizeof(struct rt5645_eq_param_s), + GFP_KERNEL); + return 0; } @@ -3209,6 +3296,20 @@ static int strago_quirk_cb(const struct dmi_system_id *id) return 1; } +static struct rt5645_platform_data celes_platform_data = { + .dmic1_data_pin = RT5645_DMIC1_DISABLE, + .dmic2_data_pin = RT5645_DMIC_DATA_IN2P, + .jd_mode = 3, + .hweq = true, +}; + +static int celes_quirk_cb(const struct dmi_system_id *id) +{ + rt5645_pdata = &celes_platform_data; + + return 1; +} + static const struct dmi_system_id dmi_platform_intel_braswell[] = { { .ident = "Intel Strago", @@ -3219,7 +3320,7 @@ static const struct dmi_system_id dmi_platform_intel_braswell[] = { }, { .ident = "Google Celes", - .callback = strago_quirk_cb, + .callback = celes_quirk_cb, .matches = { DMI_MATCH(DMI_PRODUCT_NAME, "Celes"), }, -- 1.8.1.1.439.g50a6b54

2 3

[alsa-devel] Headphone Mic and PA
by Takashi Iwai 21 Oct '15

21 Oct '15

Hi David, I'm currently checking the bug report regarding PA, and this looks like an issue with "Headphone Mic" jack control. The reported problem is that PA doesn't react properly when both HP and dock line-out jacks are plugged and line-out is unplugged. The machine in question is Dell E7250, and I see that it has only "Headphone Mic Jack" kctl without "Headphone Jack" kctl. Is this the intentional behavior? I see the code in hda_jack.c: int snd_hda_jack_add_kctls(struct hda_codec *codec, const struct auto_pin_cfg *cfg) { const hda_nid_t *p; int i, err; for (i = 0; i < cfg->num_inputs; i++) { /* If we have headphone mics; make sure they get the right name before grabbed by output pins */ if (cfg->inputs[i].is_headphone_mic) { if (auto_cfg_hp_outs(cfg) == 1) err = add_jack_kctl(codec, auto_cfg_hp_pins(cfg)[0], cfg, "Headphone Mic"); else err = add_jack_kctl(codec, cfg->inputs[i].pin, cfg, "Headphone Mic"); } else err = add_jack_kctl(codec, cfg->inputs[i].pin, cfg, NULL); So, the driver seems doing what it was written. Meanwhile, the headphone mic comes from the quirk: [ALC293_FIXUP_DELL1_MIC_NO_PRESENCE] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl[]) { { 0x18, 0x01a1913d }, /* use as headphone mic, without its own jack detect */ { 0x1a, 0x01a1913c }, /* use as headset mic, without its own jack detect */ { } }, .chained = true, .chain_id = ALC269_FIXUP_HEADSET_MODE }, and this appears as if it were supposed to be a phantom jack. The alsa-info output is found in the bugzilla https://bugzilla.suse.com/show_bug.cgi?id=948979 thanks, Takashi

3 5

[alsa-devel] [PATCH 1/1] BAT: Add man page
by han.lu＠intel.com 21 Oct '15

21 Oct '15

From: "Lu, Han" <han.lu(a)intel.com> Add more information about BAT utility, including design intent, principles, use mode, hardware connection, options, example and return value. Signed-off-by: Lu, Han <han.lu(a)intel.com> diff --git a/bat/Makefile.am b/bat/Makefile.am index 0849d0d..3a76d7f 100644 --- a/bat/Makefile.am +++ b/bat/Makefile.am @@ -1,4 +1,7 @@ bin_PROGRAMS = bat +man_MANS = bat.1 + +EXTRA_DIST = bat.1 bat_SOURCES = \ bat.c \ diff --git a/bat/bat.1 b/bat/bat.1 new file mode 100644 index 0000000..e00fc27 --- /dev/null +++ b/bat/bat.1 @@ -0,0 +1,158 @@ +.TH BAT 1 "20th October 2015" +.SH NAME +bat \- command\-line sound tester for ALSA sound card driver + +.SH SYNOPSIS +\fBbat\fP [\fIflags\fP] + +.SH DESCRIPTION +\fBBAT(Basic Audio Tester)\fP is a simple command\-line utility intended +to help automate audio driver and sound server testing with little human +interaction. BAT can be used to test audio quality, stress test features +and test audio before and after PM state changes. + +BAT's design is relatively simple. BAT plays an audio stream and captures +the same stream in either a digital or analog loop back. It then compares +the captured stream using a FFT to the original to determine if the test +case passes or fails. + +BAT can either run wholly on the target machine being tested (standalone +mode) or can run as a client/server mode where by bat client runs on the +target and runs as a server on a separate tester machine. The client/server +mode still requires some manual interaction for synchronization, but this +is actively being developed for future releases. + +The hardware testing configuration may require the use of an analog cable +connecting target to tester machines or a cable to create an analog +loopback if no loopback mode is not available on the sound hardware that +is being tested. +An analog loopback cable can be used to connect the "line in" to "line out" +jacks to create a loopback. If only headphone and mic jacks (or combo jack) +are available then the following simple circuit can be used to create an +analog loopback :- + +https://source.android.com/devices/audio/loopback.html + +.SH OPTIONS +.TP +\fI\-h, \-\-help\fP +Help: show syntax. +.TP +\fI\-D\fP +Select sound card to be tested by name. +.TP +\fI\-P\fP +Select the playback PCM device. +.TP +\fI\-C\fP +Select the capture PCM device. +.TP +\fI\-f\fP +Sample format +.br +Recognized sample formats are: U8 S16_LE S24_3LE S32_LE +.br +Some of these may not be available on selected hardware +.br +The available format shortcuts are: +.nf +\-f cd (16 bit little endian, 44100, stereo) [\-f S16_LE \-c2 \-r44100] +\-f dat (16 bit little endian, 48000, stereo) [\-f S16_LE \-c2 \-r48000] +.fi +If no format is given S16_LE is used. +.TP +\fI\-c\fP +The number of channels. The default is one channel. +Valid values at the moment are 1 or 2. +.TP +\fI\-r\fP +Sampling rate in Hertz. The default rate is 44100 Hertz. +Valid values depends on hardware support. +.TP +\fI\-n\fP +Duration of generated signal. +The value could be either of the two forms: +.br +1. Decimal integer, means number of frames; +.br +2. Floating point with suffix 's', means number of seconds. +.br +The default is 2 seconds. +.TP +\fI\-k\fP +Sigma k value for analysis. +.br +The analysis function reads data from WAV file, run FFT against the data +to get magnitude of frequency vectors, and then calculates the average +value and standard deviation of frequency vectors. After that, we define +a threshold: +.br +threshold = k * standard_deviation + mean_value +.br +Frequencies with amplitude larger than threshold will be recognized as a +peak, and the frequency with largest peak value will be recognized as a +detected frequency. +.br +BAT then compares the detected frequency to target frequency, to decide +if the detecting passes or fails. +.br +The default value is 3.0. +.TP +\fI\-F\fP +Target frequency for signal generation and analysis, in Hertz. +The default is 997.0 Hertz. +Valid range is (DC_THRESHOLD, 40% * Sampling rate). +.TP +\fI\-p\fP +Total number of periods to play or capture. +.TP +\fI\-\-log=#\fP +Write stderr and stdout output to this log file. +.TP +\fI\-\-file=#\fP +Input WAV file for playback. +.TP +\fI\-\-saveplay=#\fP +Target WAV file to save capture test content. +.TP +\fI\-\-local\fP +Internal loopback mode. +Playback, capture and analysis internal to BAT only. This is intended for +developers to test new BAT features as no audio is routed outside of BAT. + +.SH EXAMPLES + +.TP +\fBbat \-P plughw:0,0 \-C plughw:0,0 \-c 2 \-f S32_LE \-F 250\fR +Generate and play a sine wave of 250 Hertz with 2 channel and S32_LE format, +and then capture and analyze. + +.TP +\fBbat \-P plughw:0,0 \-C plughw:0,0 \-\-file 500Hz.wav\fR +Play the RIFF WAV file "500Hz.wav" which contains 500 Hertz waveform LPCM +data, and then capture and analyze. + +.SH RETURN VALUE +.br +On success, returns 0. +.br +If no peak be detected, returns -1001; +.br +If only DC be detected, returns -1002; +.br +If peak frequency does not match with the target frequency, returns -1003. + +.SH SEE ALSO +\fB +aplay(1) +\fP + +.SH BUGS +Currently only support RIFF WAV format with PCM data. Please report any bugs to +the alsa-devel mailing list. + +.SH AUTHOR +\fBbat\fP is by Liam Girdwood <liam.r.girdwood(a)linux.intel.com>, Bernard Gautier +<bernard.gautier(a)intel.com> and Han Lu <han.lu(a)intel.com>. +This document is by Liam Girdwood <liam.r.girdwood(a)linux.intel.com> and Han Lu +<han.lu(a)intel.com>. -- 1.9.1

2 1

[alsa-devel] [PATCH 0/5 v2] ALSA: firewire-tascam: fix sending the same MIDI bytes in two transactions
by Takashi Sakamoto 21 Oct '15

21 Oct '15

Hi, This patchset is revised version of my previous post: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-October/099123.ht… The main purpose of this patchset is to fix an issue that a transaction can include MIDI bytes in the next message. The last patch solves this issue, and the first 4 patches are for better shape of code including a small fixes. Changes: * add buffer alias * refine local variables Takashi Sakamoto (5): ALSA: firewire-tascam: remove buffer initialization in driver side ALSA: firewire-tascam: change type of valiables according to function prototype ALSA: firewire-tascam: use better name for local variables to describe their intension ALSA: firewire-tascam: fix loop condition with some readable variables ALSA: firewire-tascam: clear extra MIDI byte in an asynchronous transaction sound/firewire/tascam/tascam-transaction.c | 73 +++++++++++++++++------------- 1 file changed, 41 insertions(+), 32 deletions(-) -- 2.1.4

2 7

[alsa-devel] [PATCH] ASoC: wm8904: Correct number of EQ registers
by Charles Keepax 20 Oct '15

20 Oct '15

There are 24 EQ registers not 25, I suspect this bug came about because the registers start at EQ1 not zero. The bug is relatively harmless as the extra register written is an unused one. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- include/sound/wm8904.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/sound/wm8904.h b/include/sound/wm8904.h index 898be3a..6d8f8fb 100644 --- a/include/sound/wm8904.h +++ b/include/sound/wm8904.h @@ -119,7 +119,7 @@ #define WM8904_MIC_REGS 2 #define WM8904_GPIO_REGS 4 #define WM8904_DRC_REGS 4 -#define WM8904_EQ_REGS 25 +#define WM8904_EQ_REGS 24 /** * DRC configurations are specified with a label and a set of register -- 1.7.2.5

2 1

[alsa-devel] [PATCH 1/2] ASoC: ssm2518: Drop .volatile_reg implementation
by Axel Lin 20 Oct '15

20 Oct '15

The implementation of ssm2518_register_volatile always returns false, this behavior is the same as no .volatile_reg callback implementation when cache_type != REGCACHE_NONE. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/ssm2518.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/sound/soc/codecs/ssm2518.c b/sound/soc/codecs/ssm2518.c index ddb0203..86b81a60 100644 --- a/sound/soc/codecs/ssm2518.c +++ b/sound/soc/codecs/ssm2518.c @@ -723,17 +723,11 @@ static struct snd_soc_codec_driver ssm2518_codec_driver = { .num_dapm_routes = ARRAY_SIZE(ssm2518_routes), }; -static bool ssm2518_register_volatile(struct device *dev, unsigned int reg) -{ - return false; -} - static const struct regmap_config ssm2518_regmap_config = { .val_bits = 8, .reg_bits = 8, .max_register = SSM2518_REG_DRC_9, - .volatile_reg = ssm2518_register_volatile, .cache_type = REGCACHE_RBTREE, .reg_defaults = ssm2518_reg_defaults, -- 2.1.4

3 5

[alsa-devel] BAT: why MAX_NUMBER_OF_CHANNELS and CHANNEL_MAX separate?
by Caleb Crome 20 Oct '15

20 Oct '15

Hi, I'm starting to bring up BAT on my board to see if it's going to work for me. I'm starting from https://github.com/hanlui/bat, is that the correct place to start from? I'm bringing up a 16 channel board, so need BAT to support more channels (currently it supports only 2). bat/include/common.h has the following defines: #define MAX_NUMBER_OF_CHANNELS 2 #define CHANNEL_MAX 2 #define CHANNEL_MIN 1 Is there any reason we need both MAX_NUMBER_OF_CHANNELS and CHANNEL_MAX? They sure seem like they can be merged to me. Once I get the program up and running, I'll add the ramp test, and start thinking about the other tests we talked about. Thanks, -Caleb

3 5

[alsa-devel] Getting ICS43432 MEMS mic working with TMS320DM365 processor
by Ankhit Vivekananda 20 Oct '15

20 Oct '15

Hello, I have configured the TM320DM365 McBSP with clock and frame synchronization signals. Also see the ICS43432 MIC serial data on the oscilloscope, but do not get the right output in my application. I have mapped the DaVinci McBSP with the CQ0093VC audio codec driver. Is this mapping correct or is it necessary to map the McBSP with ICS-43432 codec driver? Since, I have not applied the patch, I have used CQ0093VC codec driver. Please do let me know if the ICS-43432 patch really necessary for the MIC to work. Thank you, Ankhit

2 1