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

[alsa-devel] [PATCH] Re: Calling omap_pcm_prepare() results in BUG() on OMAP1
by Janusz Krzysztofik 21 Oct '09

21 Oct '09

I'm resending, this time CCing Mark as I should. Janusz ----------------------- Wednesday 21 October 2009 09:16:37 Jarkko Nikula napisał(a): > Hi > > On Wed, 21 Oct 2009 05:11:06 +0200 > > Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> wrote: > > Hi, > > After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c, > > omap_pcm_prepare() unconditionally calls: > > > > omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > > > AFAICS, current implementation of those two functions found in > > arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1 > > at all, so they both end with BUG() on that machine. That seems to result > > in ASoC being completely unusable, at least on my OMAP5910 based Amstrad > > Delta. > > Thanks for reporting the issue. Nobody didn't realize when those calls > were added that indeed they will end up to BUG() in > arch/arm/plat-omap/dma.c on OMAP1. > > > Is calling BUG() for OMAP1 from those functions intentional? > > > > If not intentional, can those be corrected by simply putting break; > > before defalut:? > > I'd let it on as it is as it will point out immediately invalid > argument for OMAP1 and those functions do not have return value. > > > If intentional, can those function calls be conditionally omited, at > > least for OMAP1510, in sound/soc/omap/omap-pcm.c? > > Yep, just put cpu_class_is_omap1() test in sound/soc/omap/omap-pcm.c > since we should not try to set unsupported burst size for OMAP1. Here you are. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c 2009-10-21 12:33:45.000000000 +0200 @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_p else omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ); + if (cpu_class_is_omap1()) + return 0; + omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16);

2 1

[alsa-devel] [PATCH] ASoC: tlv320dac33: typo fix in the header
by Peter Ujfalusi 21 Oct '09

21 Oct '09

Fix the definition of DAC33_LTM field, the LTM bits in FIFO_IRQ_MODE_B register are starting at bit 6. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- sound/soc/codecs/tlv320dac33.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/tlv320dac33.h b/sound/soc/codecs/tlv320dac33.h index 0fedd70..eb8ae07 100644 --- a/sound/soc/codecs/tlv320dac33.h +++ b/sound/soc/codecs/tlv320dac33.h @@ -186,7 +186,7 @@ #define DAC33_NSM(x) (x << 0) #define DAC33_PSM(x) (x << 2) #define DAC33_ATM(x) (x << 4) -#define DAC33_LTM(x) (x << 4) +#define DAC33_LTM(x) (x << 6) /* DAC33_DAC_CTRL_A (0x2C) */ #define DAC33_DACRATE(x) (x << 0) -- 1.6.5.1

2 1

[alsa-devel] [PATCH] ASoC: Amstrad Delta minor cleanups
by Janusz Krzysztofik 21 Oct '09

21 Oct '09

Hi Mark, Here is a patch that corrects small omissions I have found in my code. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.32-rc5/sound/soc/omap/ams-delta.c.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/ams-delta.c 2009-10-21 03:33:17.000000000 +0200 @@ -40,7 +40,7 @@ /* Board specific DAPM widgets */ - const struct snd_soc_dapm_widget ams_delta_dapm_widgets[] = { +static const struct snd_soc_dapm_widget ams_delta_dapm_widgets[] = { /* Handset */ SND_SOC_DAPM_MIC("Mouthpiece", NULL), SND_SOC_DAPM_HP("Earpiece", NULL), @@ -81,7 +81,7 @@ static const char *ams_delta_audio_mode[ (1 << AMS_DELTA_SPEAKER)) #define AMS_DELTA_SPEAKERPHONE (AMS_DELTA_HANDSFREE | (1 << AMS_DELTA_AGC)) -unsigned short ams_delta_audio_mode_pins[] = { +static const unsigned short ams_delta_audio_mode_pins[] = { AMS_DELTA_MIXED, AMS_DELTA_HANDSET, AMS_DELTA_HANDSFREE,

2 1

[alsa-devel] question on snd_jack_report
by Harsha, Priya 21 Oct '09

21 Oct '09

When I call snd_jack_report with the status of the jack, from the user user space which parameter should I check in the sys/class/input/input2 to know if the jack is present or not? Thanks, Harsha.

2 1

[alsa-devel] Calling omap_pcm_prepare() results in BUG() on OMAP1
by Janusz Krzysztofik 21 Oct '09

21 Oct '09

Hi, After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c, omap_pcm_prepare() unconditionally calls: omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); AFAICS, current implementation of those two functions found in arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1 at all, so they both end with BUG() on that machine. That seems to result in ASoC being completely unusable, at least on my OMAP5910 based Amstrad Delta. Is calling BUG() for OMAP1 from those functions intentional? If not intentional, can those be corrected by simply putting break; before defalut:? If intentional, can those function calls be conditionally omited, at least for OMAP1510, in sound/soc/omap/omap-pcm.c? Thanks, Janusz

2 2

[alsa-devel] snd-hda-intel , changing the model option
by Colin Kincaid Williams 21 Oct '09

21 Oct '09

Hello, I'm trying to get my sound working and was wondering: Is there is a way to change the model option without restarting my computer? I tried editing the /etc/modprobe.d/alsa-base.conf file, and then restarting alsa with /etc/init.d/alsa-utils restart 0 , however I do not think the change is taking place. I used the alsa-info.sh script to determine if the change took place however it appears that the card has the same model name as when the machine booted. Best, Colin Williams

1 0

[alsa-devel] ASoC update for 2.6.33
by Mark Brown 20 Oct '09

20 Oct '09

The following changes since commit 3da8e6885ec2dea67321c904d721be90e00cd748: Mark Brown (1): Merge branch 'for-2.6.32' into for-2.6.33 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.33 Barry Song (1): ASoC: Fix possible codec_dai->ops NULL pointer problems Julia Lawall (1): ASoC: Move dereference after NULL test Manuel Lauss (2): ASoC: au1x: psc-ac97: verify correct codec register was read ASoC: au1x: psc-ac97: reorganize timeouts Mark Brown (1): Merge branch 'for-2.6.32' into for-2.6.33 Peter Ujfalusi (1): ASoC: TWL4030: Only update the needed bits in *set_dai_sysclk sound/soc/au1x/psc-ac97.c | 49 +++++++++++++++++++++++++++++-------------- sound/soc/codecs/twl4030.c | 22 ++++++++++--------- sound/soc/soc-core.c | 11 +++++++-- sound/soc/soc-jack.c | 3 +- 4 files changed, 55 insertions(+), 30 deletions(-)

1 0

[alsa-devel] dev_* output functions and ASoC codecs
by Mike Frysinger 20 Oct '09

20 Oct '09

am i doing something wrong or are the dev_* output functions kind of useless with ASoC codecs ? it seems like the error output is prefixed by the generic "soc-audio" but no info related to the exact codec is included. as an example, the typical behavior is for the machine driver to call platform_device_alloc("soc-audio", -1). this struct device is then passed down to the relevant subsystem driver register/probe (i2c/spi/etc...) to the codec driver. these functions typically then set the snd_soc_codec's dev member to the allocated platform device. which means the snd_soc_codec's name member isnt included in decoding. so now any dev_* output in the codec driver looks like: soc-audio soc-audio: some message if there are multiple codecs, things obviously fall apart quickly. the question is how to address this. werent there snd_* output funcs before ? or are those now deprecated/dead ? or perhaps we should encourage people to stop doing platform_device_alloc("soc-audio") and start doing platform_device_alloc(snd_soc_card.name) ? also, there seems to be a semi-common bug in the codec/machine drivers where they dont actually initialize the dev member. perhaps it's time to upgrade the snd_soc_register_codec() check from a KERN_WARNING to a BUG_ON() ? clearly the current warning isnt getting its message through ... -mike

3 11

Re: [alsa-devel] [patch] ALSA: VIA HDA: Add support for VT1818S
by Takashi Iwai 20 Oct '09

20 Oct '09

At Tue, 20 Oct 2009 13:18:04 +0800, lydiawang wrote: > > From: Lydia Wang <lydiawang(a)viatech.com.cn> > Subject: ALSA: VIA HDA: Add support for VT1818S. > > Add support for VT1818S codec, which is similiar with VT1708S. > > Signed-off-by: Lydia Wang <lydiawang(a)viatech.com.cn> Thanks for the patch. Unfortunately I currently have only a narrow internet access. I'll review and apply it after I back from the conferences in the next week. Takashi > --- > sound/pci/hda/patch_via.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > --- a/sound/pci/hda/patch_via.c > +++ b/sound/pci/hda/patch_via.c > @@ -41,6 +41,7 @@ > /* 2009-04-14 Lydai Wang Add support for VT1828S and VT2020 */ > /* 2009-07-08 Lydia Wang Add support for VT2002P */ > /* 2009-07-21 Lydia Wang Add support for VT1812 */ > +/* 2009-09-19 Lydia Wang Add support for VT1818S */ > /* */ > /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ > > @@ -195,6 +196,8 @@ > codec_type = VT2002P; > else if (dev_id == 0x0448) > codec_type = VT1812; > + else if (dev_id == 0x0440) > + codec_type = VT1708S; > else > codec_type = UNKNOWN; > return codec_type; > @@ -4130,11 +4133,17 @@ > spec->init_verbs[spec->num_iverbs++] = vt1708S_volume_init_verbs; > spec->init_verbs[spec->num_iverbs++] = vt1708S_uniwill_init_verbs; > > - spec->stream_name_analog = "VT1708S Analog"; > + if (codec->vendor_id == 0x11060440) > + spec->stream_name_analog = "VT1818S Analog"; > + else > + spec->stream_name_analog = "VT1708S Analog"; > spec->stream_analog_playback = &vt1708S_pcm_analog_playback; > spec->stream_analog_capture = &vt1708S_pcm_analog_capture; > > - spec->stream_name_digital = "VT1708S Digital"; > + if (codec->vendor_id == 0x11060440) > + spec->stream_name_digital = "VT1818S Digital"; > + else > + spec->stream_name_digital = "VT1708S Digital"; > spec->stream_digital_playback = &vt1708S_pcm_digital_playback; > > if (!spec->adc_nids && spec->input_mux) { > @@ -6231,6 +6240,8 @@ > { .id = 0x11060438, .name = "VT2002P", .patch = patch_vt2002P}, > { .id = 0x11064438, .name = "VT2002P", .patch = patch_vt2002P}, > { .id = 0x11060448, .name = "VT1812", .patch = patch_vt1812}, > + { .id = 0x11060440, .name = "VT1818S", > + .patch = patch_vt1708S}, > {} /* terminator */ > }; > >

1 0

[alsa-devel] alsa buffer underrun
by 邱昇譽 20 Oct '09

20 Oct '09

Dear Alsa developers: I enconter a problem about alsa buffer underrun, and have no idea how to solve it. It's great if you can spent a little of your spare time to read this. Thanks. Our CPU, (a arm processor running at 162Mhz) using I2S to communicate with codec. The i2s hardware is simply a FIFO which generates an interrupt when the FIFO data is below the programed watermark(and relevant bit in status register will be set), then we re-fill data into FIFO in interrupt handler the interrupt handler code fragment will like this static irqreturn_t dw_tdm_handler(int irq, void *data) { struct dw_tdm_dev *dev = (struct dw_tdm_dev *)data; struct platform_device *pdev = dev->pdev; struct snd_pcm_substream *substream = dev->substream; struct snd_pcm_runtime *runtime = substream->runtime; u16 *buf = (u16 *)runtime->dma_area; u32 status = dw_tdm_read_reg(TDM_INT_ STATUS); unsigned int bytes_remain = runtime->dma_bytes - dev->dma_pos; buf += dev->dma_pos / sizeof(u16); /* tx fifo is running low, reload new data for it */ if (status & TX_INT) { int i; unsigned int empty_banks = TX_EMPTY_BANKS(dw_tdm_read_reg(TDM_STATUS)); /* 2 FIFO lines each bank */ unsigned int bytes_to_write = empty_banks * 4; bytes_to_write = min(bytes_remain, bytes_to_write); dev_dbg(&pdev->dev, "dma_pos = %d\n", dev->dma_pos); dev_dbg(&pdev->dev, "hw_ptr = %d\n", frames_to_bytes(runtime, runtime->status->hw_ptr)); /* re-fill data, 1 sample contains 4 bytes */ for (i = 0; i < bytes_to_write / 4; i++) { dw_tdm_write_reg(TDM_TX_FIFO, *buf++); /* left channel */ dw_tdm_write_reg(TDM_TX_FIFO, *buf++); /* right channel */ } dev->dma_pos += bytes_to_write; if (bytes_remain == bytes_to_write) dev->dma_pos = 0; } /* rx fifo is running full, consume data from it */ if (status & RX_INT) { /* TODO */ } dev_dbg(&pdev->dev, "period elapsed\n"); snd_pcm_period_elapsed(substream); /* clear interupt status */ dw_tdm_write_reg(TDM_INT_CLR, status); return IRQ_HANDLED; } This runs into buffer underflow problem, when I use aplay to play a wav file, it seems user-space process doesn't accquire any cpu time, after out i2s h/w start to work(, and generate interrupts) output look like below: (strings in <> is my comments) # aplay /1.wav Playing WAVE '/1.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo snd_pcm_lib_write1: avail = 8160 <aplay start to fill buffer> snd_pcm_lib_write1: avail = 7904 snd_pcm_lib_write1: avail = 7648 snd_pcm_lib_write1: avail = 7392 snd_pcm_lib_write1: avail = 7136 snd_pcm_lib_write1: avail = 6880 snd_pcm_lib_write1: avail = 6624 snd_pcm_lib_write1: avail = 6368 snd_pcm_lib_write1: avail = 6112 snd_pcm_lib_write1: avail = 5856 snd_pcm_lib_write1: avail = 5600 snd_pcm_lib_write1: avail = 5344 snd_pcm_lib_write1: avail = 5088 snd_pcm_lib_write1: avail = 4832 snd_pcm_lib_write1: avail = 4576 snd_pcm_lib_write1: avail = 4320 snd_pcm_lib_write1: avail = 4064 snd_pcm_lib_write1: avail = 3808 snd_pcm_lib_write1: avail = 3552 snd_pcm_lib_write1: avail = 3296 snd_pcm_lib_write1: avail = 3040 snd_pcm_lib_write1: avail = 2784 snd_pcm_lib_write1: avail = 2528 snd_pcm_lib_write1: avail = 2272 snd_pcm_lib_write1: avail = 2016 snd_pcm_lib_write1: avail = 1760 snd_pcm_lib_write1: avail = 1504 snd_pcm_lib_write1: avail = 1248 snd_pcm_lib_write1: avail = 992 snd_pcm_lib_write1: avail = 736 snd_pcm_lib_write1: avail = 480 snd_pcm_lib_write1: avail = 224 snd_pcm_lib_write1: avail = 0 <write completed, trigger pcm stream> <i2s h/w start to work, and consume all the buffers, in this period, aplay has no chance to re-fill buffer, and underrun occurs> underrun!!! (at least 19.991 ms long) snd_pcm_lib_write1: avail = 8160 snd_pcm_lib_write1: avail = 8128 snd_pcm_lib_write1: avail = 7872 snd_pcm_lib_write1: avail = 7616 snd_pcm_lib_write1: avail = 7360 snd_pcm_lib_write1: avail = 7104 snd_pcm_lib_write1: avail = 6848 snd_pcm_lib_write1: avail = 6592 snd_pcm_lib_write1: avail = 6336 snd_pcm_lib_write1: avail = 6080 snd_pcm_lib_write1: avail = 5824 snd_pcm_lib_write1: avail = 5568 snd_pcm_lib_write1: avail = 5312 snd_pcm_lib_write1: avail = 5056 snd_pcm_lib_write1: avail = 4800 snd_pcm_lib_write1: avail = 4544 snd_pcm_lib_write1: avail = 4288 snd_pcm_lib_write1: avail = 4032 snd_pcm_lib_write1: avail = 3776 snd_pcm_lib_write1: avail = 3520 snd_pcm_lib_write1: avail = 3264 snd_pcm_lib_write1: avail = 3008 snd_pcm_lib_write1: avail = 2752 snd_pcm_lib_write1: avail = 2496 snd_pcm_lib_write1: avail = 2240 snd_pcm_lib_write1: avail = 1984 snd_pcm_lib_write1: avail = 1728 snd_pcm_lib_write1: avail = 1472 snd_pcm_lib_write1: avail = 1216 snd_pcm_lib_write1: avail = 960 snd_pcm_lib_write1: avail = 704 snd_pcm_lib_write1: avail = 448 snd_pcm_lib_write1: avail = 192 snd_pcm_lib_write1: avail = 0 underrun!!! (at least 18.479 ms long) Any ideas or suggestions?

1 0