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

[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

Re: [alsa-devel] [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard
by Wu Fengguang 20 Oct '09

20 Oct '09

David, Sorry for the long delay! On Thu, Oct 15, 2009 at 01:40:53AM +0800, David Härdeman wrote: > On Wed, Oct 14, 2009 at 10:00:44AM +0800, Wu Fengguang wrote: > >On Wed, Oct 14, 2009 at 09:54:55AM +0800, Zhenyu Wang wrote: > >> On 2009.10.11 23:45:13 +0200, David Härdeman wrote: > >>> > >>> a) > >>> > >>> Channel mapping seems funky. I have a 5.1 speaker setup (though the > >>> receiver supports 7.1) and using "speaker-test -c 6" or "speaker-test > >>> -c8" with the hdmi output will generate output to the different speakers > >>> but not the intended ones. Speakers are connected correctly though > >>> (since the channels are correct if I use passthrough to send a raw AC3 > >>> stream through either the S/PDIF or HDMI connector). This only occurs > >>> when using HDMI. > > > >This is known problem. The G45 HDMI codec does not support channel > >mapping, so the mapping must be handled in user space. Future Intel > >HDMI codecs may add support for this feature. > > Two questions (and sorry if the questions show my lack of understanding > of how this is supposed to work): > > i) Can't the driver at least provide reasonable defaults? If playing a > six channel audio, it seems reasonable that the user would like the > tracks to play to the speakers conforming to a 5.1 setup? The problem is, ALSA and HDMI each has their default channel mapping, which unfortunately disagree. All the driver could do is to tell hardware about the required remapping info. And G45 seem to just ignore this info. > ii) Is there any documentation somewhere on how this mapping is supposed > to be performed in user space? I think Shane has provided a good example for you in another email :) Here are more descriptions for the route plugin: Plugin: Route & Volume This plugin converts channels and applies volume during the conversion. The format and rate must match for both of them. pcm.name { type route # Route & Volume conversion PCM slave STR # Slave name # or slave { # Slave definition pcm STR # Slave PCM name # or pcm { } # Slave PCM definition [format STR] # Slave format [channels INT] # Slave channels } ttable { # Transfer table (bi-dimensional compound of cchannels * schannels numbers) CCHANNEL { SCHANNEL REAL # route value (0.0 - 1.0) } } } > >>> b) > >>> > >>> Each time a new audio starts playing, there seems to be a 50/50 chance > >>> of complete silence, meaning that for each track change while listening > >>> to music (for example), the entire track will either play or stay > >>> silent. > >>> > >>> This only happens when using HDMI, not S/PDIF. The problem occurs with > >>> both MythTV's music player and when watching a movie with Xine. > > > >Complete silence for how much time? > > For the entire duration of the particular movie/audio track/video > clip/whatever. > > So for instance, if I'm playing a list of tracks using MythTV, each > particular track will either play completely *or* there will be complete > silence for the duration of the track. > > Same goes for showing a movie or a video clip with mplayer or > xine...either the audio will work for the entire duration of the > movie/clip or there will be complete silence for the duration of the > clip. > > This can be "fixed" by just stopping mplayer/xine/whatever and starting > the program again with the same media until it works, but it's pretty > annoying. > > My uneducated guess is that there's some kind of content negotiation > going on at the beginning of each new media playback. On the front of > the receiver there is a LCD display which shows info on the current > audio setup (number of speakers, type of audio, etc), and it flickers > briefly at the start of each new track/video/etc before it shows the > correct situation for the current media...perhaps there is some problem > with this negotiation. I actually have a DG45FC box and have not run into this problem for all the HDMI monitors I have. What's your monitor model? Did the kernel emit some error messages? What if you change display modes with xrandr? > I got some feedback from another user on alsa-user (CC:ed): > http://article.gmane.org/gmane.linux.alsa.user/33393 > > And he had similar but not identical problems (2 second silence at the > beginning of tracks, but not silence for the entire duration of a It's <= 0.5 second silence from my experience. Shane wrote: : This is odd I've never had this happen. I do get a half : second of track skip between tracks so track transitions : sound pretty terrible but complete silence, perhaps a : developer will know what this is about. I wonder if the : skip between tracks and the silence problems are related. : IE, is the hardware reset on device open doing more harm : than good? HDMI codec/sink seem to take some time to response to the output enable and new infoframe, so there are some delay. I've moved the HDMI output enable command to module load time, this helps. The infoframe is in theory created in run time based on the format of _each_ new audio stream, so infoframe transmission has to be started/stopped for each track.. > track), so perhaps different receivers react in different ways to > something unexpected in the HDMI stream? Definitely. HDMI monitors are smart devices and can behave slightly different. I've also experienced some weird HDMI monitor behaviors. Thanks, Fengguang

1 0