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

[alsa-devel] [patch] ALSA: asihpi: a couple array out of bounds issues
by Dan Carpenter 13 Sep '13

13 Sep '13

These ->put() functions are called from snd_ctl_elem_write() with user supplied data. snd_asihpi_tuner_band_put() is missing a limit check and the check in snd_asihpi_clksrc_put() can underflow. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/pci/asihpi/asihpi.c b/sound/pci/asihpi/asihpi.c index dc632cd..5f2acd3 100644 --- a/sound/pci/asihpi/asihpi.c +++ b/sound/pci/asihpi/asihpi.c @@ -1913,6 +1913,7 @@ static int snd_asihpi_tuner_band_put(struct snd_kcontrol *kcontrol, struct snd_card_asihpi *asihpi = snd_kcontrol_chip(kcontrol); */ u32 h_control = kcontrol->private_value; + unsigned int idx; u16 band; u16 tuner_bands[HPI_TUNER_BAND_LAST]; u32 num_bands = 0; @@ -1920,7 +1921,10 @@ static int snd_asihpi_tuner_band_put(struct snd_kcontrol *kcontrol, num_bands = asihpi_tuner_band_query(kcontrol, tuner_bands, HPI_TUNER_BAND_LAST); - band = tuner_bands[ucontrol->value.enumerated.item[0]]; + idx = ucontrol->value.enumerated.item[0]; + if (idx >= ARRAY_SIZE(tuner_bands)) + idx = ARRAY_SIZE(tuner_bands) - 1; + band = tuner_bands[idx]; hpi_handle_error(hpi_tuner_set_band(h_control, band)); return 1; @@ -2383,7 +2387,8 @@ static int snd_asihpi_clksrc_put(struct snd_kcontrol *kcontrol, struct snd_card_asihpi *asihpi = (struct snd_card_asihpi *)(kcontrol->private_data); struct clk_cache *clkcache = &asihpi->cc; - int change, item; + unsigned int item; + int change; u32 h_control = kcontrol->private_value; change = 1;

2 1

[alsa-devel] [PATCH 1/2] ASoC: fsl_ssi: Staticize local symbols
by Sachin Kamat 13 Sep '13

13 Sep '13

Local symbols used only in this file are made static. Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- sound/soc/fsl/fsl_ssi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index c6b7439..4973be7 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -748,7 +748,7 @@ static void fsl_ssi_ac97_init(void) fsl_ssi_setup(fsl_ac97_data); } -void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg, +static void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg, unsigned short val) { struct ccsr_ssi *ssi = fsl_ac97_data->ssi; @@ -770,7 +770,7 @@ void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg, udelay(100); } -unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97, +static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { struct ccsr_ssi *ssi = fsl_ac97_data->ssi; -- 1.7.9.5

2 3

[alsa-devel] [PATCH] ASoC: SAMSUNG: Allow mono in i2s driver
by Charles Keepax 13 Sep '13

13 Sep '13

Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- I can't see any reason to not allow mono playback in the i2s driver and indeed it seems to work well on our test system here. However, I am fairly unfamilar with the code in this part of the tree so apologies if I am missing some constraint. Thanks, Charles sound/soc/samsung/i2s.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 959c702..70d08d7 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -991,7 +991,7 @@ static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec) i2s->i2s_dai_drv.ops = &samsung_i2s_dai_ops; i2s->i2s_dai_drv.suspend = i2s_suspend; i2s->i2s_dai_drv.resume = i2s_resume; - i2s->i2s_dai_drv.playback.channels_min = 2; + i2s->i2s_dai_drv.playback.channels_min = 1; i2s->i2s_dai_drv.playback.channels_max = 2; i2s->i2s_dai_drv.playback.rates = SAMSUNG_I2S_RATES; i2s->i2s_dai_drv.playback.formats = SAMSUNG_I2S_FMTS; -- 1.7.2.5

2 1

[alsa-devel] USB Audio/ALSA
by Rajaram R 13 Sep '13

13 Sep '13

Hi I am trying to bring up Android Accessory Audio in my Samsung Grand mobile.. I am using a Linux PC for the same. The mobile re-enumerates in AOA mode with an Audio interface. But when I play song, I see nothing on the bus. I can see an AOA audio device entry in /proc/asound/cards. The mobile runs Android JB The error i see when I play is "Sorry this player does not support this type of audio file android" . I also tried a Note 2 & tab 2 with JB, i dont see the error , but still i dont see anything on the bus.. Nexus is working fine in the same setup. Also logcat shows information as below. When i search net i understand some problem with ALSA/Android handshake AudioTrack: obtainBuffer timed out (is the CPU pegged?).......some address............ AudioTrack: obtainBuffer timed out (is the CPU pegged?).......some address............ AudioTrack: obtainBuffer timed out (is the CPU pegged?).......some address............ AudioTrack: obtainBuffer timed out (is the CPU pegged?).......some address............ Looking forward for some support

4 5

[alsa-devel] [PATCH 1/2] snd-ac97-codec: Add ID for TI TLV320AIC27 codec
by Ondrej Zary 12 Sep '13

12 Sep '13

Add 0x54584e03 ID for TI TLV320AIC27 AC'97 codec according to datasheet: http://www.ti.com/lit/ds/slas253a/slas253a.pdf The weird thing is that the chip is physically marked 320AD91. Signed-off-by: Ondrej Zary <linux(a)rainbow-software.org> --- sound/pci/ac97/ac97_codec.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/pci/ac97/ac97_codec.c b/sound/pci/ac97/ac97_codec.c index 445ca48..bf578ba2 100644 --- a/sound/pci/ac97/ac97_codec.c +++ b/sound/pci/ac97/ac97_codec.c @@ -175,6 +175,7 @@ static const struct ac97_codec_id snd_ac97_codec_ids[] = { { 0x54524106, 0xffffffff, "TR28026", NULL, NULL }, { 0x54524108, 0xffffffff, "TR28028", patch_tritech_tr28028, NULL }, // added by xin jin [07/09/99] { 0x54524123, 0xffffffff, "TR28602", NULL, NULL }, // only guess --jk [TR28023 = eMicro EM28023 (new CT1297)] +{ 0x54584e03, 0xffffffff, "TLV320AIC27", NULL, NULL }, { 0x54584e20, 0xffffffff, "TLC320AD9xC", NULL, NULL }, { 0x56494161, 0xffffffff, "VIA1612A", NULL, NULL }, // modified ICE1232 with S/PDIF { 0x56494170, 0xffffffff, "VIA1617A", patch_vt1617a, NULL }, // modified VT1616 with S/PDIF -- Ondrej Zary

1 1

Re: [alsa-devel] linux-next: Tree for Sep 12 (sound/soc/)
by Randy Dunlap 12 Sep '13

12 Sep '13

On 09/11/13 21:34, Stephen Rothwell wrote: > Hi all, > > Please do not add any code for v3.13 to your linux-next included branches > until after v3.12-rc1 is released. > > Changes since 20130911: > on i386: when CONFIG_REGMAP_I2C=m and CONFIG_SND_SOC=y sound/built-in.o: In function `snd_soc_codec_set_cache_io': (.text+0x2dbb5): undefined reference to `regmap_init_i2c' Full randconfig file is attached. -- ~Randy

1 0

[alsa-devel] Hello
by Michael Jordan 12 Sep '13

12 Sep '13

Hello Gururaja, If I am trying to ask some questions about the alsa system, do I need to copy somebody directly to get a response? I have posted about 4 questions on the group in the last few months, and I have not even gotten a slap on the hand. The reason I am contacting you is you have mentioned working on the TLV320AIC3X which is the chip used on the OMAPL138 board that we have. I am attempting to write a driver for a PCM3168A which we have already constructed a board for, and plugs into the 100 pin audio expander connecter. I have the basic draft of a driver, but everything in the code seems to be fairly strongly coded for the DA850 boards to use the TLV320AIC. I can prevent it loading, and my module will load, but things are not "connecting" internally. I assumed that I would need to make some changes in the arch/arm/mach-davinci/board-da850-evm.c. However what I am running into is chasing me up a trail that eventually has me modifying mach-types.h and creating a whole new board configuration. I said ok, so I copied board-da850-evm.c to board-da850-evm-mod.c which made it necessary for me to begin modifying some Kconfig's, etc., and I still cannot get the kernel to compile with the new kernel driver. I just need to know, am I heading down the wrong path with this? I have a pcm3168a.c and pcm3168a.h which have a basic structure for the new codec, but I cannot figure out how to get the system to actually use it because it basically appears that the TLV320AIC3X is "hard-wired" into the system. Help please, Michael

2 1

[alsa-devel] Fwd: Lynx HiLo USB DAC issues
by Radoslaw Szkodzinski 12 Sep '13

12 Sep '13

Hello, I'm now an owner of a Lynx Hilo USB DAC/ADC. It is supposedly USB Audio Class 2 compatible, but it does require an advanced driver on both Windows and Mac OS X. The device has a complex UAC2 mixer and extra features. It enumerates fine, but there's some problem with the clock selector and sink parameters. I've attached lsusb -vvv and dmesg output. Apparently bNrInPins is invalid for the clock selector for some reason. After adding an extra log of that variable, I get: [49574.136478] __uac_clock_find_source(): selector reported illegal value, id 40, ret 6, pins 1 This can actually be correct if the current clock source is not supported via USB. HiLo has a separate clock source variant for USB. I think that in this case, the clock shouldn't be rejected as invalid, instead switched to the available source if possible. During initialization, there can be any kind of garbage present in the selector. Thanks for any help, -- Radosław Szkodziński

2 5

[alsa-devel] [PATCH] ASoC: wm8903: disable IRQs during BIAS_OFF
by Stephen Warren 11 Sep '13

11 Sep '13

From: Stephen Warren <swarren(a)nvidia.com> If the WM8903 IRQ is triggered after the device is suspended, or before it is resumed, the underlying I2C bus that the WM8903 is attached to may not be available. This may cause the IRQ handler to emit the following error: wm8903 0-001a: Failed to read IRQ status: -16 ... or perhaps even cause a failure inside the I2C driver. To prevent this, explicitly mask all interrupt sources when entering BIAS_OFF. Also, modify the IRQ handler to immediately return if the device is in BIAS_OFF, so that shared interrupt lines don't cause a similar problem. This requires that WM8903 interrupts be disabled to avoid interrupt storms. During resume (actually, the transition back to BIAS_STANDBY), restore the desired IRQ mask. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/codecs/wm8903.c | 38 ++++++++++++++++++++++++++++---------- 1 file changed, 28 insertions(+), 10 deletions(-) diff --git a/sound/soc/codecs/wm8903.c b/sound/soc/codecs/wm8903.c index eebcb1d..e847bbe 100644 --- a/sound/soc/codecs/wm8903.c +++ b/sound/soc/codecs/wm8903.c @@ -1091,6 +1091,22 @@ static const struct snd_soc_dapm_route wm8903_intercon[] = { { "Right Line Output PGA", NULL, "Charge Pump" }, }; +static void wm8903_setup_mic_det_irqs(struct snd_soc_codec *codec) +{ + struct wm8903_priv *wm8903 = snd_soc_codec_get_drvdata(codec); + int irq_mask = WM8903_MICDET_EINT | WM8903_MICSHRT_EINT; + + /* Enable interrupts we've got a report configured for */ + if (wm8903->mic_det) + irq_mask &= ~WM8903_MICDET_EINT; + if (wm8903->mic_short) + irq_mask &= ~WM8903_MICSHRT_EINT; + + snd_soc_update_bits(codec, WM8903_INTERRUPT_STATUS_1_MASK, + WM8903_MICDET_EINT | WM8903_MICSHRT_EINT, + irq_mask); +} + static int wm8903_set_bias_level(struct snd_soc_codec *codec, enum snd_soc_bias_level level) { @@ -1169,6 +1185,8 @@ static int wm8903_set_bias_level(struct snd_soc_codec *codec, WM8903_CP_DYN_V, WM8903_CP_DYN_FREQ | WM8903_CP_DYN_V); + + wm8903_setup_mic_det_irqs(codec); } snd_soc_update_bits(codec, WM8903_VMID_CONTROL_0, @@ -1177,6 +1195,8 @@ static int wm8903_set_bias_level(struct snd_soc_codec *codec, break; case SND_SOC_BIAS_OFF: + snd_soc_write(codec, WM8903_INTERRUPT_STATUS_1_MASK, 0xffff); + snd_soc_update_bits(codec, WM8903_BIAS_CONTROL_0, WM8903_BIAS_ENA, 0); @@ -1600,7 +1620,6 @@ int wm8903_mic_detect(struct snd_soc_codec *codec, struct snd_soc_jack *jack, int det, int shrt) { struct wm8903_priv *wm8903 = snd_soc_codec_get_drvdata(codec); - int irq_mask = WM8903_MICDET_EINT | WM8903_MICSHRT_EINT; dev_dbg(codec->dev, "Enabling microphone detection: %x %x\n", det, shrt); @@ -1610,15 +1629,7 @@ int wm8903_mic_detect(struct snd_soc_codec *codec, struct snd_soc_jack *jack, wm8903->mic_det = det; wm8903->mic_short = shrt; - /* Enable interrupts we've got a report configured for */ - if (det) - irq_mask &= ~WM8903_MICDET_EINT; - if (shrt) - irq_mask &= ~WM8903_MICSHRT_EINT; - - snd_soc_update_bits(codec, WM8903_INTERRUPT_STATUS_1_MASK, - WM8903_MICDET_EINT | WM8903_MICSHRT_EINT, - irq_mask); + wm8903_setup_mic_det_irqs(codec); if (det || shrt) { /* Enable mic detection, this may not have been set through @@ -1642,6 +1653,13 @@ static irqreturn_t wm8903_irq(int irq, void *data) int mic_report, ret; unsigned int int_val, mask, int_pol; + /* + * During suspend, a shared IRQ may be triggered by some other device. + * If so, just ignore it; WM8903 shouldn't be generating interrupts. + */ + if (wm8903->codec->dapm.bias_level == SND_SOC_BIAS_OFF) + return IRQ_NONE; + ret = regmap_read(wm8903->regmap, WM8903_INTERRUPT_STATUS_1_MASK, &mask); if (ret != 0) { -- 1.8.1.5

2 3

Re: [alsa-devel] alsa crash with “ ALSA sound/usb/urb.c:179 cannot submit urb (err = -27)” on imx6q sabrelite
by Daniel Mack 11 Sep '13

11 Sep '13

On 11.09.2013 14:53, Ankit Agarwal wrote: > > On Sun, Sep 8, 2013 at 8:27 PM, Daniel Mack <zonque(a)gmail.com > <mailto:zonque@gmail.com>> wrote: > > On 02.09.2013 12:51, Ankit Agarwal wrote: > > I am using alsa pcm player to listen to audio. The alsa pcm > crashes with > > the error: ALSA sound/usb/urb.c:179 cannot submit urb (err = -27). > I am > > able to hear the data initially but when other transaction begins > on HID > > report endpoint, alsa crashes with the mentioned error. > > -27 == -EFBIG, which seems to relate to a scheduling problem on the bus, > and hence probably rather to a host controller bug than an issue with > snd-usb. > > > I am working on imx6q board with linux kernel-3.0.35. I am using Apple > > device to get the digital audio. > > Please try with a more recent kernel, and see if you can find the > location where EFBIG is initially reported. > > > I have found that EFBIG is being reported by ehci-host controller. It is > coming from file ehci-sched.c under iso_stream_schedule() function. The > error is thrown when the controller tries to schedule the urb too far > into the future, ie, there is overflow of the scheduled URBs. I might be > happening because the URBs are not scheduled properly. Ok. What about trying a newer kernel? The issue might be fixed already. In any case, this does not seem related to snd-usb, so I copied the usb list. Daniel

2 1