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

Re: [alsa-devel] [PATCH] ASoC: rt5631: first commit
by Mark Brown 04 Sep '11

04 Sep '11

On Thu, Sep 01, 2011 at 08:21:14PM +0800, johnnyhsu(a)realtek.com wrote: > Subject: [PATCH] ASoC: rt5631: first commit "Add driver for..." or something. > +static int rt5631_volatile_register(struct snd_soc_codec *codec, > + unsigned int reg) > +{ > + switch (reg) { > + case RT5631_VENDOR_ID: > + case RT5631_VENDOR_ID1: > + case RT5631_VENDOR_ID2: > + return 0; > + default: > + return 1; > + } > +} This looks to be exactly the wrong way round - the only registers we can cache are the ID registers. > +/* MIC Boost Volume */ > +static const char *rt5631_mic_boost[] = {"Bypass", "+20db", "+24db", "+30db", > + "+35db", "+40db", "+44db", "+50db", "+52db"}; TLV for volume information. > + rt5631->bclk_rate = snd_soc_params_to_bclk(params); > + if (rt5631->bclk_rate < 0) { > + dev_err(codec->dev, "Unsupported BCLK rate: %d\n", > + rt5631->bclk_rate); > + return rt5631->bclk_rate; > + } The error message here is inacurate, there was an error obtaining the BCLK rate rather than a problem supporting it. > +static int rt5631_codec_set_dai_pll(struct snd_soc_dai *codec_dai, int pll_id, > + int source, unsigned int freq_in, unsigned int freq_out) > +{ > + struct snd_soc_codec *codec = codec_dai->codec; > + struct rt5631_priv *rt5631 = snd_soc_codec_get_drvdata(codec); > + int i, ret = -EINVAL; > + > + dev_dbg(codec->dev, "enter %s\n", __func__); > + > + if (!freq_in || !freq_out) { > + dev_dbg(codec->dev, "PLL disabled\n"); > + return -EINVAL; > + } This shouldn't be an error condition, disabling the PLL is a perfectly normal thing to do. > + if (rt5631->master) { > + for (i = 0; i < ARRAY_SIZE(codec_master_pll_div); i++) > + if (freq_in == codec_master_pll_div[i].pll_in && Since the PLL configuration depends on the master/slave configuration you should either warn or reconfigure if the PLL is set up and the user changes master/slave configuration. > +/** > + * rt5631_index_reg_show - sysfs file for dumping index registers of 2nd layer > + */ > +static ssize_t rt5631_index_reg_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ No, use the standard facilities. Please don't ignore review comments, it's not helpful.

1 0

Re: [alsa-devel] [PATCH] ASoC: sn95031: Fix the logic to find free channel
by Mark Brown 04 Sep '11

04 Sep '11

On Sat, Sep 03, 2011 at 01:41:47PM +0800, Axel Lin wrote: > In the case of no free channel available, > current implementation returns 0 instead of negative errno. > > This patch fixes the logic to return -EINVAL if no free channel available. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] ASoC: codecs: Remove unused mutex
by Mark Brown 04 Sep '11

04 Sep '11

On Sun, Sep 04, 2011 at 10:48:09PM +0800, Axel Lin wrote: > 2011/9/4 Mark Brown <broonie(a)opensource.wolfsonmicro.com>: > > This has already been done for wm9090, can you resubmit with just the > > alc5623 change please? > Ok. A new patch "ASoC: alc5623: Remove unused mutex" is on the way. Thanks. The patch has been sitting there for a little while but it's not on kernel.org due to the lockdown after the compromise - until we can start pushing updates again there's a risk of overlaps like this.

1 0

[alsa-devel] [3.1-rc4] sound regression on Realtek ALC260
by Alessandro Guido 04 Sep '11

04 Sep '11

With 3.1-rc4 Skype makes very unpleasant noises when playing event sounds or voice. Sometimes a reboot may be able to fix it, but with with 3.0 it always worked fine. Some new warnings are shown in dmesg for 3.1-rc4 related to alsa: hda-intel: Invalid position buffer, using LPIB read method instead. hda-intel: Invalid position buffer, using LPIB read method instead. hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. I'm attaching the output of alsa-info utility.

1 0

Re: [alsa-devel] [PATCH] ASoC: codecs: Remove unused mutex
by Mark Brown 04 Sep '11

04 Sep '11

On Sun, Sep 04, 2011 at 08:52:31PM +0800, Axel Lin wrote: > Signed-off-by: Axel Lin <axel.lin(a)gmail.com> > Cc: Arnaud Patard <arnaud.patard(a)rtp-net.org> > Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > --- > sound/soc/codecs/alc5623.c | 2 -- > sound/soc/codecs/wm9090.c | 2 -- This has already been done for wm9090, can you resubmit with just the alc5623 change please?

1 0

Re: [alsa-devel] [PATCH] ASoC: sn95031: Fix the logic to find free channel
by Girdwood, Liam 03 Sep '11

03 Sep '11

On 3 September 2011 06:41, Axel Lin <axel.lin(a)gmail.com> wrote: > In the case of no free channel available, > current implementation returns 0 instead of negative errno. > > This patch fixes the logic to return -EINVAL if no free channel available. > > Signed-off-by: Axel Lin <axel.lin(a)gmail.com> > --- > sound/soc/codecs/sn95031.c | 8 +++----- > 1 files changed, 3 insertions(+), 5 deletions(-) > > diff --git a/sound/soc/codecs/sn95031.c b/sound/soc/codecs/sn95031.c > index 84ffdeb..b4f1cb4 100644 > --- a/sound/soc/codecs/sn95031.c > +++ b/sound/soc/codecs/sn95031.c > @@ -79,7 +79,7 @@ static void configure_adc(struct snd_soc_codec > *sn95031_codec, int val) > */ > static int find_free_channel(struct snd_soc_codec *sn95031_codec) > { > - int ret = 0, i, value; > + int i, value; > > /* check whether ADC is enabled */ > value = snd_soc_read(sn95031_codec, SN95031_ADC1CNTL1); > @@ -91,12 +91,10 @@ static int find_free_channel(struct snd_soc_codec > *sn95031_codec) > for (i = 0; i < SN95031_ADC_CHANLS_MAX; i++) { > value = snd_soc_read(sn95031_codec, > SN95031_ADC_CHNL_START_ADDR + i); > - if (value & SN95031_STOPBIT_MASK) { > - ret = i; > + if (value & SN95031_STOPBIT_MASK) > break; > - } > } > - return (ret > SN95031_ADC_LOOP_MAX) ? (-EINVAL) : ret; > + return (i == SN95031_ADC_CHANLS_MAX) ? (-EINVAL) : i; > } > > /* Initialize the ADC for reading micbias values. Can sleep. */ > -- > 1.7.4.1 > > > > Acked-by: Liam Girdwood <lrg(a)ti.com> Btw, this should be posted to alsa-devel.

2 1

[alsa-devel] Lost dB volumes on USB headset between 2.6.38 and 3.0
by David Henningsson 03 Sep '11

03 Sep '11

Hmm, I and Colin Guthrie have found a regression between kernels 2.6.38 and 3.0. When running "amixer -D hw:handset" for this device under 2.6.38, the attached file is returned. Under 3.0, the dB information is missing. This can't be intentional, can it? -- David Henningsson http://launchpad.net/~diwic

5 13

[alsa-devel] A debug version of the ALSA lib?
by Olivier Guillion - Myriad 02 Sep '11

02 Sep '11

Hi, I have a problem with the ALSA library. Calling snd_device_name_hint() crashes sometimes, and I can't understand why. It might be due to a previous memory corruption in my program, a problem with my sound card driver, or a bug in the library, I don't know. I tried to debug it in assembler, and found that the library is browsing a list of devices, gets the pointer to each device name, and in the 2nd device, I get the four letters "Play" instead of a valid pointer. To be able to go further, I'd need a debug version of the ALSA library, including variable names and source lines, which could let me find more easily what goes wrong and when. Is it possible to build such a library from the alsa-lib-1.0.24.1 sources? Or should I download and install another specific package? Thank you, Olivier

6 15

Re: [alsa-devel] Can ALSA invoke a Callback ?
by Clemens Ladisch 02 Sep '11

02 Sep '11

Ru Vuott wrote: > hData = OPEN "/dev/snd/midiC2D0" for READ Watch > > Do you think this solution could interfere and give problems to ALSA ? Yes; this opens the device exclusively. The ALSA sequencer would be able to allow multiple applications. > The rest of my program (for sending midi event, etcetera) continue to use ALSA. How are you using ALSA from Gambas? Is there some ALSA module that could be extended to ALSA watches? Regards, Clemens

1 0

[alsa-devel] [RFC PATCH 0/3] If an IRQ is a GPIO, request and configure it
by Stephen Warren 02 Sep '11

02 Sep '11

In http://www.spinics.net/lists/linux-tegra/msg01731.html, Mark Brown pointed out that it was a little silly forcing every board or driver to gpio_request() a GPIO that is later converted to an IRQ, and passed to request_irq. The first patch in this series instead makes the core IRQ code perform these calls when appropriate, to avoid duplicating it everywhere. However, this change has the potential for significant regressions; at least some drivers are already calling gpio_request for GPIOs that are also used as IRQs. This then causes the gpio_request inside the core IRQ code to fail, which causes functional regressions. I'm not sure how wide- spread this issue is, but in testing on NVIDIA Tegra, I found two instances that needed to be fixed. Perhaps a failure of gpio_request in the core IRQ code should trigger a WARN rather than returning an error, to give a grace period for conversion of other code? Stephen Warren (3): irq: If an IRQ is a GPIO, request and configure it mmc: tegra: Don't gpio_request GPIOs used as IRQs. ASoC: jack_add_gpios: Don't gpio_request GPIOs used as IRQs. drivers/mmc/host/sdhci-tegra.c | 8 -------- kernel/irq/manage.c | 25 +++++++++++++++++++++++-- sound/soc/soc-jack.c | 13 +------------ 3 files changed, 24 insertions(+), 22 deletions(-)

5 20