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

[alsa-devel] [PATCHv2 0/4] ASoC: multi-component - Samsung S3C Platform
by Seungwhan Youn 17 Jul '10

17 Jul '10

Hi, This is a second version of patch series adding support for multi component model on Samsung S3C Platform. This patch series can be apply upon "ASoC: multi-component - Fix S3C compile error" in the first patch of V1 that already applied by Liam. Changes since V1: - Support for GPIO, DMA and SFR settings pull from platform device resource. - Modify description of add WM9713 platform device on smdk board. The following patch series contains: [PATCHv2 1/4] ASoC: S3C64XX: Move GPIO settings to platform [PATCHv2 2/4] ASoC: S3C64XX: Move DMA settings to platform [PATCHv2 3/4] ASoC: multi-component - S3C - Get original functionality [PATCHv2 4/4] ASoC: multi-component - S3C - Add WM9713 platform device Thanks, Claude

3 7

[alsa-devel] [PATCH] asoc: multi-component: mpc8610: fix typo in mpc8610_hpcd_data
by Timur Tabi 17 Jul '10

17 Jul '10

The dma_id[] variable in struct mpc8610_hpcd_data is a zero-length array, when it should be of length 2. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- Liam, please squash this into your repository. sound/soc/fsl/mpc8610_hpcd.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c index 81ab639..8665cc2 100644 --- a/sound/soc/fsl/mpc8610_hpcd.c +++ b/sound/soc/fsl/mpc8610_hpcd.c @@ -37,7 +37,7 @@ struct mpc8610_hpcd_data { unsigned int cpu_clk_direction; unsigned int clk_frequency; unsigned int ssi_id; /* 0 = SSI1, 1 = SSI2, etc */ - unsigned int dma_id[0]; /* 0 = DMA1, 1 = DMA2, etc */ + unsigned int dma_id[2]; /* 0 = DMA1, 1 = DMA2, etc */ unsigned int dma_channel_id[2]; /* 0 = ch 0, 1 = ch 1, etc*/ char dai_name[32]; }; -- 1.7.0.1

3 2

Re: [alsa-devel] [PlanetCCRMA] [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
by Niels Mayer 17 Jul '10

17 Jul '10

On Fri, Jul 16, 2010 at 5:27 AM, Geoff King <gsking1(a)gmail.com> wrote: > Niels, Thank you for taking the time to work on improving Envy24Ctl. > I tried your patch for the peaks and it seemed to work fine for me. I > can't comment on the code (as I'm much more musician than programmer), > but had no problem patching and installing. Looking forward to trying > this new patch and whatever else you come up with. Geoff Geoff -- thank you for trying out the patch! (And, OT, thanks for working w/ Rui to help fix http://sourceforge.net/tracker/?func=detail&atid=733076&aid=3021645&group_i… :: "help fix qtractor crash on bus changing/configuration (3021645)" -- Envy24 and multichannel qtractor users, yes, it's time for a "svn up" ). FYI, to try out the new levelmeters "easy", if you're running Fedora x86_64, use the "envy24control" binary directly, or drop the levelmeters.c file into your build: http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.tgz ( for details http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.README ) ........ On a completely different "note" the envy 24 manual ( http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf ) has interesting info on the envy24 digital mixer that I've snapshotted: Diagram: http://nielsmayer.com/npm/envy24mixer-architecture.png Note the way it truncates in the mixer: the more inputs you "mix" at once, the fewer bits each input source gets, and it's not clear what kind of dither, or it's a straight truncate of 24... ultimately the envy24 seems oriented towards producing a 16 bit, and not 24 bit master (which makes sense given that the chip is well over a decade old and HD audio production for "prosumer" was rare): .......... 4.5.5 Multi-Track Digital Monitoring The Envy24 integrates a 36-bit resolution digital hardware mixer. The width of the data path is strictly to ensure that during processing of all the channels, under any condition, no resolution is lost. The dynamic range of the end user system will be limited by the range of the physical output devices used. In order to maintain identical gain to the input stream (i.e. 0dB), the resulting 24-bit is not msb-aligned to the 36-bit. The overflow bits correspond to the analog distortion due to saturation. The user would need to reduce the overall attenuation of the inputs to avoid clipping. Insertion of the digital mixer adds only a single sample cycle delay with respect to the original data. This extremely low latency all digital mixer provides monitoring functionality and can replace a traditional external analog input mixer. There are 20 independent audio data streams to mix and control the volume. ... .............. --Niels http://nielsmayer.com

1 0

[alsa-devel] [PATCH 15/15] sound/soc: imx: check kzalloc() result and fix memory leak
by Kulikov Vasiliy 16 Jul '10

16 Jul '10

If kzalloc() fails we must exit with -ENOMEM. Also we must free allocated runtime->private_data on error as it would be lost on next call to snd_imx_open(). Signed-off-by: Kulikov Vasiliy <segooon(a)gmail.com> --- sound/soc/imx/imx-pcm-fiq.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/sound/soc/imx/imx-pcm-fiq.c b/sound/soc/imx/imx-pcm-fiq.c index 6b518e0..b2bf272 100644 --- a/sound/soc/imx/imx-pcm-fiq.c +++ b/sound/soc/imx/imx-pcm-fiq.c @@ -192,6 +192,8 @@ static int snd_imx_open(struct snd_pcm_substream *substream) int ret; iprtd = kzalloc(sizeof(*iprtd), GFP_KERNEL); + if (iprtd == NULL) + return -ENOMEM; runtime->private_data = iprtd; iprtd->substream = substream; @@ -202,8 +204,10 @@ static int snd_imx_open(struct snd_pcm_substream *substream) ret = snd_pcm_hw_constraint_integer(substream->runtime, SNDRV_PCM_HW_PARAM_PERIODS); - if (ret < 0) + if (ret < 0) { + kfree(iprtd); return ret; + } snd_soc_set_runtime_hwparams(substream, &snd_imx_hardware); return 0; -- 1.7.0.4

1 0

[alsa-devel] [PATCH 14/15] sound/soc: imx: check kzalloc() result and fix memory leak
by Kulikov Vasiliy 16 Jul '10

16 Jul '10

If kzalloc() fails we must exit with -ENOMEM. Also we must free allocated runtime->private_data on error as it would be lost on next call to snd_imx_open(). Signed-off-by: Kulikov Vasiliy <segooon(a)gmail.com> --- sound/soc/imx/imx-pcm-dma-mx2.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/sound/soc/imx/imx-pcm-dma-mx2.c b/sound/soc/imx/imx-pcm-dma-mx2.c index 05f19c9..0a595da 100644 --- a/sound/soc/imx/imx-pcm-dma-mx2.c +++ b/sound/soc/imx/imx-pcm-dma-mx2.c @@ -292,12 +292,16 @@ static int snd_imx_open(struct snd_pcm_substream *substream) int ret; iprtd = kzalloc(sizeof(*iprtd), GFP_KERNEL); + if (iprtd == NULL) + return -ENOMEM; runtime->private_data = iprtd; ret = snd_pcm_hw_constraint_integer(substream->runtime, SNDRV_PCM_HW_PARAM_PERIODS); - if (ret < 0) + if (ret < 0) { + kfree(iprtd); return ret; + } snd_soc_set_runtime_hwparams(substream, &snd_imx_hardware); return 0; -- 1.7.0.4

1 0

[alsa-devel] [PATCH] twl6040: fix wrong kfree in twl6040_remove and twl6040_codec_remove
by Axel Lin 16 Jul '10

16 Jul '10

Memory allocation part: We allocate a memory in twl6040_codec_probe(): priv = kzalloc(sizeof(struct twl6040_data), GFP_KERNEL); twl6040_codec = codec = &priv->codec; Memory release part: In twl6040_codec_remove() we should kfree(priv) instead of kfree(twl6040_codec). In twl6040_remove(), no need and should not kfree(codec). Signed-off-by: Axel Lin <axel.lin(a)gmail.com> --- sound/soc/codecs/twl6040.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/twl6040.c b/sound/soc/codecs/twl6040.c index af36346..9d4a85f 100644 --- a/sound/soc/codecs/twl6040.c +++ b/sound/soc/codecs/twl6040.c @@ -1068,7 +1068,6 @@ static int twl6040_remove(struct platform_device *pdev) twl6040_set_bias_level(codec, SND_SOC_BIAS_OFF); snd_soc_free_pcms(socdev); snd_soc_dapm_free(socdev); - kfree(codec); return 0; } @@ -1214,7 +1213,7 @@ static int __devexit twl6040_codec_remove(struct platform_device *pdev) snd_soc_unregister_dai(&twl6040_dai); snd_soc_unregister_codec(twl6040_codec); - kfree(twl6040_codec); + kfree(priv); twl6040_codec = NULL; return 0; -- 1.5.4.3

2 2

[alsa-devel] ASoC: Davinci Voice codec compliant to arago kernel for dm365
by Raffaele Recalcati 16 Jul '10

16 Jul '10

Hi Miguel, I've used successfully the patches below on top of 2.6.34 Kevin Hilman kernel for davinci http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git Now I need to backport your patches to arago kernel http://arago-project.org/git/projects/linux-davinci.git that means 2.6.32-rc1 I use able adapt your patches to it, but I guess that there are many changes from 2.6.32-rc1 to 2.6.34 ... Can you tell me what is the best thing to do? I'm afraid you'll tell me that I need to rewrite completely your patches to be really compliant to 2.6.32-rc1. Here you are a not working log: aplay tone1KHzMono_8000.wav Playing WAVE 'tone1KHzMono_8000.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono davinci_pcm_prepare - 203 davinci_pcm_enqueue_dma - 77: period=2000,dma_offset=0,dma_pos=-2044854272 davinci_pcm: audio_set_dma_params_play channel = 79 dma_ptr = 861e0000 period_size=7d0 davinci_pcm_enqueue_dma - 84: data_type=0 davinci_pcm_enqueue_dma - 77: period=2000,dma_offset=2000,dma_pos=-2044852272 davinci_pcm: audio_set_dma_params_play channel = 79 dma_ptr = 861e07d0 period_size=7d0 davinci_pcm_enqueue_dma - 84: data_type=0 aplay: pcm_write:1528: write error: Input/output error Thanks, Raffaele --------------- Author: Miguel Aguilar <miguel.aguilar(a)ridgerun.com> Date: Thu Mar 11 09:32:21 2010 -0600 MFD: DaVinci Voice Codec This is the MFD driver for the DaVinci Voice codec, it has two clients: * Voice codec interface * Voice codec CQ93VC Signed-off-by: Miguel Aguilar <miguel.aguilar(a)ridgerun.com> Acked-by: Samuel Ortiz <sameo(a)linux.intel.com> Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> commit 94a532f7156582ec7459f21baa4de6665773974a Author: Miguel Aguilar <miguel.aguilar(a)ridgerun.com> Date: Thu Mar 11 09:32:59 2010 -0600 ASoC: DaVinci: CQ93VC Voice Codec Currently the DM365 is the only SoC that includes this Voice Codec. Signed-off-by: Miguel Aguilar <miguel.aguilar(a)ridgerun.com> Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> commit 80a6609eeb0995732318c7ab672767e39a111f3b Author: Miguel Aguilar <miguel.aguilar(a)ridgerun.com> Date: Thu Mar 11 09:32:42 2010 -0600 ASoC: DaVinci: Voice Codec Interface This patch adds the support for the interface needed by the DaVinci Voice Codec CQ93VC. Signed-off-by: Miguel Aguilar <miguel.aguilar(a)ridgerun.com> Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> -- www.opensurf.it

1 0

[alsa-devel] HPI version 4.04.01
by linux＠audioscience.com 16 Jul '10

16 Jul '10

HPI stable driver 4.04.01 has just been released. Only very minor patches since the last beta version. Please also update alsa-firmware/asihpi with firmware from http://audioscience.com/internet/download/drivers/released/v4/04/01/asihpi-…

3 6

[alsa-devel] Accessing snd_soc_read/snd_soc_write directly for diagnostics
by Mike Crowe 16 Jul '10

16 Jul '10

Hi folks, I know this is a strange request, however, for diagnostic purposes in our embedded system, we would like to talk directly to the codec registers of our sound chip, bypassing alsa. I have the driver compiled into the kernel (not loaded as a module). Is it possible to create a program which can talk to the snd_soc_read and snd_soc_write functions directly? I'm not sure if this is an option, but if it is, I'd appreciate a pointer to something similar to use as a guide. TIA Mike

2 2

Re: [alsa-devel] [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
by Niels Mayer 16 Jul '10

16 Jul '10

On Tue, Jul 13, 2010 at 3:46 PM, Tim E. Real <termtech(a)rogers.com> wrote: > But nothing was ever done about the slider markings. > Having them go from 0 to 164 is not really helpful. > It's not clear where the 0dB mark is. > At the very least a 0dB mark should be added. > Uh, do you feel like taking a stab at this? > IIRC it would be a bit tricky because you have to look up > the corresponding values in the IC data sheets, I think. This makes sense... I was thinking of a simple ruler with a 0dB label at 127 and a + dB label above and a - dB label below. Some thoughts on further usability improvements to envy24control: (1) In "alsamixer" the snd-ice1712-card's input levels are represented by (versus envy24control's value): 100% (163) -> ADC [dB gain: 18.00] 78% (127) -> ADC [dB gain: 0.00] 1% (001) -> ADC [dB gain: -63.00] 0% (000) -> ADC [dB gain: mute] Mixers like envy24control, kmix, alsamixergui, gst-mixer, etc, are a lot less useful than they could be because they just present sliders. At least envy24control gives numeric values, -- which is essential if you want to know stereo channels are balenced, or what unity-gain levels are for inputs. In "alsamixer", the snd-ice1712-card's output levels are represented by (versus envy24control value): 100% (127) -> DAC [dB gain: 0.00] 1% (001) -> DAC [dB gain: -63.00] 0% (000) -> DAC [dB gain: mute] As this is a separate issue from the meters, it makes sense to do the changes to the "Analog Volume" panel of envy24control as a separate patch. (2) The "0-96" sliders, feeding the digital mixer, need better labeling and mappings too: The "96" actually being "-96dB" and only valid for 16 bit depths. On the other hand, alsamixer is showing the 24 bit dB values, even when 16 bits are being used: 100% (0) -> H/W Multi [dB gain: 0.00, ...] 1% (95) -> H/W Multi [dB gain: -142.50,...] 0% (96) -> H/W Multi [dB gain: -144.00,...] Worse than the labelling, but associated -- the scaling: Right now the digital mixer's input sliders all have linear response -- which wastes the lower half of the slider and makes setting levels difficult because all the "action" is near the top. If you use an external MIDI controller for the mixer, you can use this existing option: -M, --midienhanced Use an enhanced mapping from midi controller to db slider However this does not apply to the GUI controller, which stays linear. Clearly the GUIs digital mixer controls also need a logarithmic scale (perhaps as default settings); matching that, each mixer input's meters also need to have their scale expressed "logarithmically" so as to provide, for example 50% of the display resolution for 0 to -20dB, and remaining 50% for -20dB to -96dB/-144dB. Alongside the numbers indicating the 0 to -96db L or R gain on each mixer input channel, I would also add the current peak value held in the meters in dB, which would be based on hardware metering level "0xFF" representing 0db, and hardware meter level "0x01" representing all but the last of the 9 MSB's being 0 (per http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf: "Peak data derived from the absolute value of 9 msb. 00h * min - FFh max volume. Reading the register resets the meter to 00h." Other missing features: (3) Due to the hardware metering employed by envy24control, the peak meters don't actually detect "clipping" ; rather, they just detect "full scale" as 255. Is there a hardware clipped indicator on the ice1712? It doesn't make sense to turn on a big red "clipped" light for 0dB output, so the current peak-meters are "subtle," and just indicate that a peak occurred at the given level... And color-code the peak towards red as it reaches 255. (4) The "IEC958 Input Status" isn't presented, even though it's available and working, e.g from the command-line,. with SPDIF input going to the Delta66 soundcard: ..... gnulem-176-~> amixer -c M66 cget numid=50,iface=MIXER,name='Delta IEC958 Input Status' numid=50,iface=MIXER,name='Delta IEC958 Input Status' ; type=BOOLEAN,access=r-------,values=1 : values=on ..... And without any SPDIF input: ..... gnulem-177-~> amixer -c M66 cget numid=50,iface=MIXER,name='Delta IEC958 Input Status' numid=50,iface=MIXER,name='Delta IEC958 Input Status' ; type=BOOLEAN,access=r-------,values=1 : values=off Perhaps this isn't available in envy24control because it has differing levels of support across envy24-based cards? I only have a Delta66's and a Terratec Dmx6Fire 24/96 for testing, and both support the SPDIF input status. -- Niels http://nielsmayer.com PS: ALSA tip of the day. To read ice1712's hardware level-meter values from the command line: "amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45" type=INTEGER,access=r-------,values=22,min=0,max=255,step=0 : values=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,198,255,198

1 0