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

[alsa-devel] [RESEND][PATCH 1/4] pxa2xx-i2s: Proper initialization
by Karl Beldan 12 May '09

12 May '09

Reset FIFO logic and registers, and make sure REC and RPL functions along with FIFO service are disabled at probe. Signed-off-by: Karl Beldan <karl.beldan(a)mobile-devices.fr> --- sound/soc/pxa/pxa2xx-i2s.c | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index 2f4b6e4..450fca6 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -346,6 +346,19 @@ static int pxa2xx_i2s_probe(struct platform_device *dev) if (ret != 0) clk_put(clk_i2s); + /* + * PXA Developer's Manual: + * If SACR0[ENB] is toggled in the middle of a normal operation, + * the SACR0[RST] bit must also be set and cleared to reset all + * I2S controller registers. + */ + SACR0 = SACR0_RST; + SACR0 = 0; + /* Make sure RPL and REC are disabled */ + SACR1 = SACR1_DRPL | SACR1_DREC; + /* Along with FIFO servicing */ + SAIMR &= ~(SAIMR_RFS | SAIMR_TFS); + return ret; } -- 1.6.3.rc1.34.g0be9b -- Karl Beldan

2 1

[alsa-devel] Master vs. Front/Rear/LFE/... elements
by Lennart Poettering 12 May '09

12 May '09

Heya! Some cards expose 'Master' volume sliders. Others expose seperate (stereo) sliders for 'Front', 'Rear' and so on. I have trouble dealing with them properly in PulseAudio: First of all, on some cards 'Master' seems not to have any effect on the actual analog output, only 'Front' and friends do. Is this a bug or intended behaviour? Can I assume that 'Master' and 'Front' are always independant? Secondly, I have trouble supporting the 'Front'/'Rear'/'Side'/... elements properly, since they split up the surround channels into seperate elements. Now, this is confusing in many ways, even for "amixer" which will then show channels such as "Rear Front Left" and so on, which obviously make no sense. snd_mixer_selem_has_playback_channel() just returns bogus data for these cases. Why are those elements seperate anyway? Why aren't they combined into a single multi-channel event? Looking at the APIs I get the idea that the problem appears to be that elements can only control all channels the same are all independantly which doesn't really match 1:1 on my multichannel sound cards. However, wouldn't it be possible to use the 'index' value of a selem_id for this? I.e. have a series of controls by the same name but different indexes which would then implement snd_mixer_selem_has_playback_channel() correctly? i.e. foo,0 would do front-left/right, foo,1 would do rear, foo,2 would do lfe, and so? I have no clue how this implemented internally, so not sure how feasible this might be. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

7 16

[alsa-devel] 2.6.29 Vs 2.6.30
by Harsha, Priya 12 May '09

12 May '09

Hi, I was developing a driver on 2.6.29 and it was playing using aplay properly but when I moved to 2.6.30, same code base is giving me underrun messages. What is the changes with respect to this in 2.6.30? Primarily, why do underrun messages come and how does driver need to handle it? Any clue will be of great help. Thanks, Harsha

1 0

[alsa-devel] ASoC updates for 2.6.31
by Mark Brown 12 May '09

12 May '09

The following changes since commit bec4c99e8637b5b8bd4b0513eacb51da25885e3b: Mark Brown (1): ASoC: Fix file patterns for PXA sound drivers are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.31 Joonyoung Shim (1): ASoC: TWL4030: change DAPM for analog microphone selection Mark Brown (3): ASoC: Fix up CODEC DAI formats for big endian CPUs ASoC: Enforce symmetric rates for PXA2xx I2S Merge branch 'for-2.6.30' into for-2.6.31 Mike Rapoport (3): ASoC: soc-core: fix crash when removing not instantiated card pxa2xx-ac97: fix reset gpio mode setting ASoC: em-x270: make the driver support also eXeda and CM-X300 machines Roel Kluin (1): ASoC: remove driver_data direct access of struct device Sergey Lapin (1): ASoC: AFEB9260 driver sound/arm/pxa2xx-ac97-lib.c | 2 +- sound/soc/atmel/Kconfig | 8 ++ sound/soc/atmel/Makefile | 1 + sound/soc/atmel/snd-soc-afeb9260.c | 203 ++++++++++++++++++++++++++++++++++++ sound/soc/codecs/twl4030.c | 52 ++++------ sound/soc/codecs/wm8400.c | 4 +- sound/soc/codecs/wm8731.c | 4 +- sound/soc/codecs/wm8753.c | 4 +- sound/soc/pxa/Kconfig | 4 +- sound/soc/pxa/em-x270.c | 9 +- sound/soc/pxa/pxa2xx-i2s.c | 1 + sound/soc/soc-core.c | 43 ++++++++ 12 files changed, 289 insertions(+), 46 deletions(-) create mode 100644 sound/soc/atmel/snd-soc-afeb9260.c

1 0

[alsa-devel] ALSA for SoC audio support full duplex problem
by jinjin xu 12 May '09

12 May '09

Dear All. I use 2.6.21.5-cfs-v19 on S3C6410(arm),use wm8987 sound card(i2s interface) It is not use in full duplex. I grep and diff the drivers ens1370.c: snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &snd_ensoniq_playback1_ops); snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &snd_ensoniq_capture_ops); soc-core.c: if (playback) { snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &soc_pcm_ops); } if (capture) { snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &soc_pcm_ops); } ens1370.c use two different fops for playback and record(I test it in Vmware,It can run on full duplex) soc-core.c use the same fops for playback and record It that the problem ? So how to fix it for support full duplex? Thanks!

2 1

Re: [alsa-devel] [PATCH 1/1] hdsp: allow firmware loading from inside the kernel
by Takashi Iwai 12 May '09

12 May '09

At Tue, 12 May 2009 09:41:36 +0200, Raphaël Doursenaud wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Takashi Iwai a écrit : > > At Tue, 12 May 2009 09:25:27 +0200, > > Raphaël Doursenaud wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Takashi Iwai a écrit : > >>> At Tue, 12 May 2009 09:05:19 +0200, > >>> Raphaël Doursenaud wrote: > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>> Hash: SHA1 > >>>> > >>>> Takashi Iwai a écrit : > >>>>> At Tue, 12 May 2009 08:47:29 +0200, > >>>>> Raphaël Doursenaud wrote: > >>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>> Hash: SHA1 > >>>>>> > >>>>>> Takashi Iwai a écrit : > >>>>>>> At Tue, 12 May 2009 08:16:08 +0200, > >>>>>>> Raphaël Doursenaud wrote: > >>>>>>>> From: Raphaël Doursenaud <rdoursenaud(a)free.fr> > >>>>>>>> > >>>>>>>> Allow the use of the FIRMWARE_IN_KERNEL option with hdsp cards and > >>>>>>>> in-kernel driver. > >>>>>>> Did it really work without problems? > >>>>>>> > >>>>>>> > >>>>>>> Takashi > >>>>>> Tested over the weekend with two multifaces in my DAW. > >>>>>> Got no problem. > >>>>> Interesting. > >>>>> Did you build the firmware file into the kernel, or not? > >>>>> > >>>>> > >>>>> Takashi > >>>> Yes I built all hdsp fimware files (multiface_firmware.bin > >>>> multiface_firmware_rev11.bin digiface_firmware.bin > >>>> digiface_firmware_rev11.bin) into the kernel. > >>>> It's the aim of this patch. > >>> Well, the problem I'm concerned is that the driver can be compiled > >>> in even if you have no built-in firmware. And there is no restriction > >>> or dependency check in Kconfig, so far. > >>> > >>> Could you test how the kernel behaves without the built-in firmware? > >>> Does it hang or give any critical error? > >>> > >>> > >>> thanks, > >>> > >>> Takashi > >> Could you be more specific? > >> I'm not sure to understand why it could be a problem. > >> Do you think that if I set FIRMWARE_IN_KERNEL without compiling the > >> firmware(s) in-kernel the request_firmware() will not resolve and cause > >> an error? > > > > Yes, exactly. > > request_firmware() shall fail in that case likely after a long > > time-out (unless you have the firmware files in initrd) because there > > is really no file / data available at the time it's called. > > And I'm not sure whether this could lead to a fatal operation error. > > > > > > Takashi > AFAIK this is handled in the code (from line 5080) and should lead to > "Hammerfall-DSP: couldn't get firmware from userspace. try using hdsploader" Yep, a fallback mechanism is found in hdsp driver itself. But the driver probe hangs for too long time, and I'm just worried about its influence on the whole kernel boot-up. > I'm building a kernel to test that case. Thanks. Takashi

2 3

[alsa-devel] ASoC updates for 2.6.30
by Mark Brown 12 May '09

12 May '09

The following changes since commit 97a775c49c7e1b47b016a492463486a5b86da479: Jinyoung Park (1): ASoC: Fix errors in WM8990 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30 Mike Rapoport (2): ASoC: soc-core: fix crash when removing not instantiated card pxa2xx-ac97: fix reset gpio mode setting sound/arm/pxa2xx-ac97-lib.c | 2 +- sound/soc/soc-core.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletions(-)

2 1

[alsa-devel] [PATCH] ASoC: TWL4030: change DAPMs for analog microphone selection
by Joonyoung Shim 12 May '09

12 May '09

The mixer DAPM is suitable than the mux DAPM for the analog microphone registers(0x05, 0x06) because each bit for path is switchable. Signed-off-by: Joonyoung Shim <jy0922.shim(a)samsung.com> --- sound/soc/codecs/twl4030.c | 52 ++++++++++++++++--------------------------- 1 files changed, 19 insertions(+), 33 deletions(-) diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c index e23c20c..a7875c2 100644 --- a/sound/soc/codecs/twl4030.c +++ b/sound/soc/codecs/twl4030.c @@ -397,36 +397,18 @@ static const struct snd_kcontrol_new twl4030_dapm_handsfreer_control = SOC_DAPM_ENUM("Route", twl4030_handsfreer_enum); /* Left analog microphone selection */ -static const char *twl4030_analoglmic_texts[] = - {"Off", "Main mic", "Headset mic", "AUXL", "Carkit mic"}; - -static const unsigned int twl4030_analoglmic_values[] = - {0x0, 0x1, 0x2, 0x4, 0x8}; - -static const struct soc_enum twl4030_analoglmic_enum = - SOC_VALUE_ENUM_SINGLE(TWL4030_REG_ANAMICL, 0, 0xf, - ARRAY_SIZE(twl4030_analoglmic_texts), - twl4030_analoglmic_texts, - twl4030_analoglmic_values); - -static const struct snd_kcontrol_new twl4030_dapm_analoglmic_control = -SOC_DAPM_VALUE_ENUM("Route", twl4030_analoglmic_enum); +static const struct snd_kcontrol_new twl4030_dapm_analoglmic_controls[] = { + SOC_DAPM_SINGLE("Main mic", TWL4030_REG_ANAMICL, 0, 1, 0), + SOC_DAPM_SINGLE("Headset mic", TWL4030_REG_ANAMICL, 1, 1, 0), + SOC_DAPM_SINGLE("AUXL", TWL4030_REG_ANAMICL, 2, 1, 0), + SOC_DAPM_SINGLE("Carkit mic", TWL4030_REG_ANAMICL, 3, 1, 0), +}; /* Right analog microphone selection */ -static const char *twl4030_analogrmic_texts[] = - {"Off", "Sub mic", "AUXR"}; - -static const unsigned int twl4030_analogrmic_values[] = - {0x0, 0x1, 0x4}; - -static const struct soc_enum twl4030_analogrmic_enum = - SOC_VALUE_ENUM_SINGLE(TWL4030_REG_ANAMICR, 0, 0x5, - ARRAY_SIZE(twl4030_analogrmic_texts), - twl4030_analogrmic_texts, - twl4030_analogrmic_values); - -static const struct snd_kcontrol_new twl4030_dapm_analogrmic_control = -SOC_DAPM_VALUE_ENUM("Route", twl4030_analogrmic_enum); +static const struct snd_kcontrol_new twl4030_dapm_analogrmic_controls[] = { + SOC_DAPM_SINGLE("Sub mic", TWL4030_REG_ANAMICR, 0, 1, 0), + SOC_DAPM_SINGLE("AUXR", TWL4030_REG_ANAMICR, 1, 1, 0), +}; /* TX1 L/R Analog/Digital microphone selection */ static const char *twl4030_micpathtx1_texts[] = @@ -1034,11 +1016,15 @@ static const struct snd_soc_dapm_widget twl4030_dapm_widgets[] = { SND_SOC_DAPM_POST_PMU|SND_SOC_DAPM_POST_PMD| SND_SOC_DAPM_POST_REG), - /* Analog input muxes with switch for the capture amplifiers */ - SND_SOC_DAPM_VALUE_MUX("Analog Left Capture Route", - TWL4030_REG_ANAMICL, 4, 0, &twl4030_dapm_analoglmic_control), - SND_SOC_DAPM_VALUE_MUX("Analog Right Capture Route", - TWL4030_REG_ANAMICR, 4, 0, &twl4030_dapm_analogrmic_control), + /* Analog input mixers for the capture amplifiers */ + SND_SOC_DAPM_MIXER("Analog Left Capture Route", + TWL4030_REG_ANAMICL, 4, 0, + &twl4030_dapm_analoglmic_controls[0], + ARRAY_SIZE(twl4030_dapm_analoglmic_controls)), + SND_SOC_DAPM_MIXER("Analog Right Capture Route", + TWL4030_REG_ANAMICR, 4, 0, + &twl4030_dapm_analogrmic_controls[0], + ARRAY_SIZE(twl4030_dapm_analogrmic_controls)), SND_SOC_DAPM_PGA("ADC Physical Left", TWL4030_REG_AVADC_CTL, 3, 0, NULL, 0), -- 1.6.0.4

3 9

Re: [alsa-devel] [PATCH 1/1] hdsp: allow firmware loading from inside the kernel
by Takashi Iwai 12 May '09

12 May '09

At Tue, 12 May 2009 09:05:19 +0200, Raphaël Doursenaud wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Takashi Iwai a écrit : > > At Tue, 12 May 2009 08:47:29 +0200, > > Raphaël Doursenaud wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Takashi Iwai a écrit : > >>> At Tue, 12 May 2009 08:16:08 +0200, > >>> Raphaël Doursenaud wrote: > >>>> From: Raphaël Doursenaud <rdoursenaud(a)free.fr> > >>>> > >>>> Allow the use of the FIRMWARE_IN_KERNEL option with hdsp cards and > >>>> in-kernel driver. > >>> Did it really work without problems? > >>> > >>> > >>> Takashi > >> Tested over the weekend with two multifaces in my DAW. > >> Got no problem. > > > > Interesting. > > Did you build the firmware file into the kernel, or not? > > > > > > Takashi > Yes I built all hdsp fimware files (multiface_firmware.bin > multiface_firmware_rev11.bin digiface_firmware.bin > digiface_firmware_rev11.bin) into the kernel. > It's the aim of this patch. Well, the problem I'm concerned is that the driver can be compiled in even if you have no built-in firmware. And there is no restriction or dependency check in Kconfig, so far. Could you test how the kernel behaves without the built-in firmware? Does it hang or give any critical error? thanks, Takashi

2 3

[alsa-devel] Audio blank samples after some seconds of playing
by javier Martin 12 May '09

12 May '09

I have a .wav file which lasts about 2 minutes. I am playing it with aplay. It works fine, but after some seconds of playing, I hear two blanks suddenly. After that, it continues playing fine till the end of the file. I have tried to increment buffer size and period size but I don't see any difference. Possition of blank samples seems to be quite random, but it always happens near the beggining of the file. Can you please give me some tip for debugging this problem or an idea of what more can I try? Thank you.

1 0