March 2014 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] RT priority 99 on soundcard
by Joël Krähemann 31 Mar '14

31 Mar '14

Is running on top of soundcard with realtime priority 99 problematic? /* and now async */ { static const struct timespec req = { 0, (250000000 * (1 / 45)), }; if(!AGS_IS_DEVOUT_THREAD(thread)){ nanosleep(&req, NULL); } }

2 1

[alsa-devel] [PATCH 1/6] ASoC: rt5640: Remove the pre-allocated size of reg_default
by Oder Chiou 31 Mar '14

31 Mar '14

In order to prevent the redundant memory usage, the pre-allocated size of reg_default should be remove. Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> --- sound/soc/codecs/rt5640.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c index cf041e3..9427511 100644 --- a/sound/soc/codecs/rt5640.c +++ b/sound/soc/codecs/rt5640.c @@ -59,7 +59,7 @@ static struct reg_default init_list[] = { }; #define RT5640_INIT_REG_LEN ARRAY_SIZE(init_list) -static const struct reg_default rt5640_reg[RT5640_VENDOR_ID2 + 1] = { +static const struct reg_default rt5640_reg[] = { { 0x00, 0x000e }, { 0x01, 0xc8c8 }, { 0x02, 0xc8c8 }, -- 1.8.1.1.439.g50a6b54

2 12

[alsa-devel] [PATCH] ASoC: rsnd: use fast_io for bus
by Ben Dooks 29 Mar '14

29 Mar '14

The rcar sound driver uses regmap to access registers in various parts of the block and uses regmap to manage mappings. The regmap is created without fast_io set, which means it locks with a mutex rather than a lighter-spinlock. The use of the mutex lock causes issues when the IRQ handler is entered as the code needs to read/write register values and thus with lock debugging enabled the system outputs a number of warnings such as: BUG: sleeping function called from invalid context at rnel/locking/mutex.c:616 The rcar registers are all connected via APB bus and thus not that slow to access. The fix is to set the fast_io in the code so that regmap creates the regmap structures using the faster spinlock functions. Signed-off-by: Ben Dooks <ben.dooks(a)codethink.co.uk> --- sound/soc/sh/rcar/gen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sh/rcar/gen.c b/sound/soc/sh/rcar/gen.c index 9094970..6468962 100644 --- a/sound/soc/sh/rcar/gen.c +++ b/sound/soc/sh/rcar/gen.c @@ -66,6 +66,7 @@ static int rsnd_regmap_read32(void *context, } static struct regmap_bus rsnd_regmap_bus = { + .fast_io = true, .write = rsnd_regmap_write32, .read = rsnd_regmap_read32, .reg_format_endian_default = REGMAP_ENDIAN_NATIVE, -- 1.9.0

2 1

[alsa-devel] Input/output error Alsa api
by Thiago Carísio 29 Mar '14

29 Mar '14

Hi! I am Thiago and i'm starting to use the alsa api. I'm testing one function to make the sound capture and i got this input/output error. I don't get it why this is happening...so, please...some kind soul can help me? Thanks

1 0

[alsa-devel] Advanced Gtk+ Sequencer - Beta Release
by Joël Krähemann 29 Mar '14

29 Mar '14

Hi, I just released the very first beta, 3 hours ago. There are 2 weeks towards final release 0.4.0 and any suggestions are welcome. https://sourceforge.net/projects/ags/

1 0

Re: [alsa-devel] [PATCH] ASoC: Add support for multi register mux
by Songhee Baek 28 Mar '14

28 Mar '14

> > On 03/26/2014 11:41 PM, Songhee Baek wrote: > > >> On 03/26/2014 01:02 AM, Arun Shamanna Lakshmi wrote: > > >> > > >> The way you describe this it seems to me that a value array for > > >> this kind of mux would look like. > > >> > > >> 0x00000000, 0x00000000, 0x00000001 > > >> 0x00000000, 0x00000000, 0x00000002 > > >> 0x00000000, 0x00000000, 0x00000003 > > >> 0x00000000, 0x00000000, 0x00000004 > > >> 0x00000000, 0x00000000, 0x00000008 > > >> ... > > >> > > >> That seems to be extremely tedious. If the MUX uses a one hot > > >> encoding how about storing the index of the bit in the values array > > >> and use (1 << value) when writing the value to the register? > > > > > > If we store the index of the bit, the value will be duplicated for > > > each > > registers inputs since register has 0 to 31bits to shift, then we need > > to decode the index to interpret value for which registers to set. If > > we need to interpret the decoded value of index, it is better to have > > custom put/get function in our driver, isn't it? > > > > > > > I'm not sure I understand. If you use (val / 32) to pick the register > > and (val % > > 32) to pick the bit in the register this should work just fine. Maybe > > I'm missing something. Do you have a real world code example of of the > > this type of enum is used? > > > > I can use val/32 and val%32 for this multi register mux. With this logic, put function would be easy however get function becomes tedious due to looping on each bit per register for 3 of them in our case. Rather, it would be easy to identify a unique MUX_OFFSET to distinguish between the 3 registers as shown in the code below. #define MULTI_MUX_INPUT_OFFSET(n) (5 * n) int snd_soc_dapm_get_enum_double(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct snd_soc_codec *codec = snd_soc_dapm_kcontrol_codec(kcontrol); struct soc_enum *e = (struct soc_enum *)kcontrol->private_value; unsigned int reg_val, val, reg_idx; if (e->reg[0] != SND_SOC_NOPM) { for (reg_idx = 0; reg_idx < e->num_regs; reg_idx) { reg_val = snd_soc_read(codec, e->reg[reg_idx]); val = (reg_val >> e->shift_l) & e->mask[reg_idx]; if (val) val += MULTI_MUX_INPUT_OFFSET(reg_idx); } } else { reg_val = dapm_kcontrol_get_value(kcontrol); val = (reg_val >> e->shift_l) & e->mask[0]; } ucontrol->value.enumerated.item[0] = snd_soc_enum_val_to_item(e, val); if (e->shift_l != e->shift_r) { val = (reg_val >> e->shift_r) & e->mask[0]; val = snd_soc_enum_val_to_item(e, val); ucontrol->value.enumerated.item[1] = val; } return 0; } int snd_soc_dapm_put_enum_double(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct snd_soc_codec *codec = snd_soc_dapm_kcontrol_codec(kcontrol); struct snd_soc_card *card = codec->card; struct soc_enum *e = (struct soc_enum *)kcontrol->private_value; unsigned int *item = ucontrol->value.enumerated.item; unsigned int change, i, value, update_idx = 0; unsigned int mask; struct snd_soc_dapm_update update; int ret = 0, reg_val; if (item[0] >= e->items) return -EINVAL; value = snd_soc_enum_item_to_val(e, item[0]) << e->shift_l; mask = e->mask[0] << e->shift_l; if (e->shift_l != e->shift_r) { if (item[1] > e->items) return -EINVAL; value |= snd_soc_enum_item_to_val(e, item[1]) << e->shift_l; mask |= e->mask[0] << e->shift_r; } if (e->num_regs < 2) { goto update_reg; } for (i = 0; i < e->num_regs; i++) { reg_val = value - MULTI_MUX_INPUT_OFFSET(i); /* checking reg_val is power of 2 : one-hot code */ /* if reg_val after subtract MULTI_MUX_INPUT_OFFSET is not power of 2, reg[i] should be zero */ if (reg_val & (reg_val - 1)) { /* clear the current input register */ snd_soc_write(codec, e->reg[i], 0); } else { /* reg_val is power of 2, store updated info */ value = reg_val; mask = e->mask[i]; update_idx = i; } } update_reg: mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME); if (e->reg[update_idx] != SND_SOC_NOPM) change = snd_soc_test_bits(codec, e->reg[update_idx], mask, value); else change = dapm_kcontrol_set_value(kcontrol, value); if (change) { if (e->reg[update_idx] != SND_SOC_NOPM) { update.kcontrol = kcontrol; update.reg = e->reg[update_idx]; update.mask= mask; update.val = value; card->update = &update; } ret = soc_dapm_mux_update_power(card, kcontrol, item[0], e); card->update = NULL; } mutex_unlock(&card->dapm_mutex); if (ret > 0) soc_dpcm_runtime_update(card); return change; } > > >>> - int reg; > > >>> + int reg[SOC_ENUM_MAX_REGS]; > > >>> unsigned char shift_l; > > >>> unsigned char shift_r; > > >>> unsigned int items; > > >>> - unsigned int mask; > > >>> + unsigned int mask[SOC_ENUM_MAX_REGS]; > > >> > > >> If you make mask and reg pointers instead of arrays this should be > > >> much more flexible and not be limited to 3 registers. We will make reg* and mask* instead of arrays and since we use the same structure, the plan is to share the get and put function code. Thanks. Songhee.

1 0

[alsa-devel] [PATCH] ALSA: hda - verify pin:cvt connection on preparing a stream for Intel HDMI codec
by mengdong.lin＠intel.com 28 Mar '14

28 Mar '14

From: Mengdong Lin <mengdong.lin(a)intel.com> The pin:converter connection may get reset after S3 on Intel Broadwell HDMI codec. And this can cause multiple pins share a same convertor and mute control will affect each other. We observed a resumed audio playback become silent after S3. This patch verifies pin:cvt connection on preparing a stream, to assure the pin selects the right convetor and an assigned convertor is not shared by other unused pins. Apply this fix-up on Haswell, Broadwell and Baytrail. Signed-off-by: Mengdong Lin <mengdong.lin(a)intel.com> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 3ab7063..6000ce9 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -68,6 +68,7 @@ struct hdmi_spec_per_pin { hda_nid_t pin_nid; int num_mux_nids; hda_nid_t mux_nids[HDA_MAX_CONNECTIONS]; + int mux_idx; hda_nid_t cvt_nid; struct hda_codec *codec; @@ -1342,6 +1343,8 @@ static int hdmi_choose_cvt(struct hda_codec *codec, if (cvt_idx == spec->num_cvts) return -ENODEV; + per_pin->mux_idx = mux_idx; + if (cvt_id) *cvt_id = cvt_idx; if (mux_id) @@ -1350,6 +1353,22 @@ static int hdmi_choose_cvt(struct hda_codec *codec, return 0; } +/* Assure the pin select the right convetor */ +static void intel_verify_pin_cvt_connect(struct hda_codec *codec, + struct hdmi_spec_per_pin *per_pin) +{ + hda_nid_t pin_nid = per_pin->pin_nid; + int mux_idx, curr; + + mux_idx = per_pin->mux_idx; + curr = snd_hda_codec_read(codec, pin_nid, 0, + AC_VERB_GET_CONNECT_SEL, 0); + if (curr != mux_idx) + snd_hda_codec_write_cache(codec, pin_nid, 0, + AC_VERB_SET_CONNECT_SEL, + mux_idx); +} + /* Intel HDMI workaround to fix audio routing issue: * For some Intel display codecs, pins share the same connection list. * So a conveter can be selected by multiple pins and playback on any of these @@ -1751,6 +1770,12 @@ static int generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo, bool non_pcm; int pinctl; + if (is_haswell_plus(codec) || is_valleyview(codec)) { + /* the pin:cvt connection may get reset after S3 */ + intel_verify_pin_cvt_connect(codec, per_pin); + intel_not_share_assigned_cvt(codec, pin_nid, per_pin->mux_idx); + } + non_pcm = check_non_pcm_per_cvt(codec, cvt_nid); mutex_lock(&per_pin->lock); per_pin->channels = substream->runtime->channels; -- 1.8.1.2

4 10

Re: [alsa-devel] Invalid PCM pointer with CMI8738 and pcm.c buffer underuns
by Raymond Yau 28 Mar '14

28 Mar '14

> > I've previously posted under ALSA's user mailing list so to avoid the > clutter, the details about what's happening is here: > http://article.gmane.org/gmane.linux.alsa.user/38258 > http://article.gmane.org/gmane.linux.alsa.user/38260 > > There was no debug info under /proc/asound/card0/ so nothing to give from > there unless you guys need something specific. > > Output of alsa-debug.sh: > http://www.alsa-project.org/db/?f=26187faadd47f3626029ba667cb004e74695f2b2 https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/p… Seem cannot read valid value from register within three trials state.CMI8738 { control.1 { iface PCM device 2 name 'Playback Channel Map' value.0 0 value.1 0 value.2 0 value.3 0 value.4 0 value.5 0 comment { access read type INTEGER count 6 range '0 - 36' } } Seem bug in adding channel map to iec958 instead of analog https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/p… pcm.!default { type plug slave.pcm "dmixer" } You need asym plugin for playback and capture when overwrite pcm.default

3 5

[alsa-devel] tlv320aic32x4 Codec ADC and DAC must shutdown to alter clocks
by Mike Looijmans 28 Mar '14

28 Mar '14

My general question: If "my" codec needs to alter the state of the DAPM tree, how can the codec ask or inform the DAPM components of this? This problem occurs on tlv320aic32x4 codecs, but probably applies to many others as well. Using the tlv320aic32x4 a simple loop like this may "crash" the codec: while true do speaker-test -c 2 -t sine -l 1 -r 48000 > /dev/null speaker-test -c 2 -t sine -l 1 -r 44100 > /dev/null done A "crash" means, in this respect that the chip loses some of its settings, malfunctions and often it results in NACKs on I2C commands. I've been trying to properly fix this, but it just won't fit in the framework. The cause is that the DAPM starts the DAC and/or ADC cores while the clocks aren't running, and stops the clocks before shutting down the cores. There is the overall bug of the driver that starts and stops all the clocks in the aic32x4_set_bias_level in the wrong order - it should start them from source to sink, and stop them in the opposite direction, so the PLL must be the first to start and last to stop. Apparently this isn't really critical as I've never observed failure as a result of this. What I cannot fix is that changing the parameters (like clock frequency) must stop the DAC core. The DAPM framework just sets the BIAS to "ON" only once, and does not shut down until after a time out. Which is good. But if the next stream to play needs a different clock setting, the DAC must be stopped first, the code must wait until the DAC has powered down, and then the clocks can be stopped and altered. When all settings are done, the DAC can be restarted. Starting the DAC is the DAPM's task, it's this line that does the job: SND_SOC_DAPM_DAC("Left DAC", "Left Playback", AIC32X4_DACSETUP, 7, 0), I can detect the change in the hw_params, and on the first stream to play, this is called while still in STANDBY or lower levels. However, when the codec is already in ON bias level, how do I tell DAPM that I had to shut down the DAC in order to change the parameters? Just toggling the related bits will keep the DAC powered down. A routine to store and restore the power state is possible, but very ineffective. Especially since the "I must shutdown" conclusion can also be in the clock setting routine. That would result in multiple down-up cycles. -- Mike Looijmans

2 5

[alsa-devel] [PATCH v6 0/2] ASoC: Add SiRF I2S controller and hdmi card drivers
by RongJun Ying 28 Mar '14

28 Mar '14

From: Rongjun Ying <rongjun.ying(a)csr.com> This patchset adds CSR SiRFSoC sound drivers including: 4. The SiRF I2S controller driver 5. The SiRF hdmi card driver Rongjun Ying (2): ASoC: sirf: Add SiRF I2S driver ASoC: sirf: Add hdmi support .../devicetree/bindings/sound/sirf-i2s.txt | 27 ++ sound/soc/sirf/Kconfig | 11 + sound/soc/sirf/Makefile | 2 + sound/soc/sirf/sirf-i2s.c | 445 ++++++++++++++++++++ sound/soc/sirf/sirf-i2s.h | 93 ++++ 5 files changed, 578 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/sirf-i2s.txt create mode 100644 sound/soc/sirf/sirf-i2s.c create mode 100644 sound/soc/sirf/sirf-i2s.h -- 1.7.5.4

2 4