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

[alsa-devel] [RFC PATCH 0/3] If an IRQ is a GPIO, request and configure it
by Stephen Warren 02 Sep '11

02 Sep '11

In http://www.spinics.net/lists/linux-tegra/msg01731.html, Mark Brown pointed out that it was a little silly forcing every board or driver to gpio_request() a GPIO that is later converted to an IRQ, and passed to request_irq. The first patch in this series instead makes the core IRQ code perform these calls when appropriate, to avoid duplicating it everywhere. However, this change has the potential for significant regressions; at least some drivers are already calling gpio_request for GPIOs that are also used as IRQs. This then causes the gpio_request inside the core IRQ code to fail, which causes functional regressions. I'm not sure how wide- spread this issue is, but in testing on NVIDIA Tegra, I found two instances that needed to be fixed. Perhaps a failure of gpio_request in the core IRQ code should trigger a WARN rather than returning an error, to give a grace period for conversion of other code? Stephen Warren (3): irq: If an IRQ is a GPIO, request and configure it mmc: tegra: Don't gpio_request GPIOs used as IRQs. ASoC: jack_add_gpios: Don't gpio_request GPIOs used as IRQs. drivers/mmc/host/sdhci-tegra.c | 8 -------- kernel/irq/manage.c | 25 +++++++++++++++++++++++-- sound/soc/soc-jack.c | 13 +------------ 3 files changed, 24 insertions(+), 22 deletions(-)

5 20

Re: [alsa-devel] [RFC 0/5] compress: add compress data API to ALSA kernel
by Mark Brown 02 Sep '11

02 Sep '11

On Fri, Sep 02, 2011 at 09:04:42AM -0500, Pierre-Louis Bossart wrote: > Not yet. I wanted to have more visibility into alsa-lib use for > Android before doing into changes there. > Let's talk about it at LPC. FWIW and the benefit of the list alsa-lib won't fly for adoption by Google as part of the standard Android system unless it gets relicensed, though obviously other people are happily using it in production and there's systems other than Android out there. tinyalsa is probably the way forward for Google.

1 0

Re: [alsa-devel] [PATCH] ASoC: Add missing platform_device_put in raumfeld_audio_init error path
by Girdwood, Liam 02 Sep '11

02 Sep '11

On 2 September 2011 14:47, Axel Lin <axel.lin(a)gmail.com> wrote: > Signed-off-by: Axel Lin <axel.lin(a)gmail.com> > --- > sound/soc/pxa/raumfeld.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/sound/soc/pxa/raumfeld.c b/sound/soc/pxa/raumfeld.c > index 1a591f1..b899a3b 100644 > --- a/sound/soc/pxa/raumfeld.c > +++ b/sound/soc/pxa/raumfeld.c > @@ -306,8 +306,10 @@ static int __init raumfeld_audio_init(void) > &snd_soc_raumfeld_connector); > > ret = platform_device_add(raumfeld_audio_device); > - if (ret < 0) > + if (ret < 0) { > + platform_device_put(raumfeld_audio_device); > return ret; > + } > > raumfeld_enable_audio(true); > return 0; > -- > 1.7.4.1 > Acked-by: Liam Girdwood <lrg(a)ti.com>

1 0

[alsa-devel] submitting patch: specify destination kernel version(s)
by Torsten Schenk 02 Sep '11

02 Sep '11

Hi, I'm currently preparing a patch for the kernel, I want it to be included from 3.0 on, but not in versions before. I once got a hint to put Cc: stable(a)kernel.org but that seems not to do the trick. How could it be achieved, that the patch only appears in 3.0 (and later)? Greets, Torsten

4 3

Re: [alsa-devel] [OctDev] Updated ALSA and a new JACK package for playing and recording audio
by Fredrik Lingvall 02 Sep '11

02 Sep '11

Miguel, I have updated the alsa package now and I don't have any build issues on my machine: octave:3> pkg install aaudio-0.2.1.tar.gz warning: creating installation directory /usr/share/octave/packages octave:4> Check that the clock is set correctly on your machine (is ntp-client running?) Also, test to do a octave:4> pkg uninstall aaudio and then install aaudio again. You should have: octave:4> pkg list Package Name | Version | Installation directory --------------+---------+----------------------- aaudio *| 0.2.1 | /usr/share/octave/packages/aaudio-0.2.1 after installation. /Fredrik On 09/01/11 21:53, Miguel Bazdresch wrote: > On Thu, Sep 1, 2011 at 12:29 PM, Fredrik Lingvall <fl(a)ifi.uio.no> wrote: >> Ah, I forgot to remove that line from the Makefile. >> >> You can fix it by uncompressing the tar file, edit the Makefile in the src >> folder, remove all actrecord stuff, and recomress it again. I will fix this >> tomorrow. >> >> /Fredrik > Fredrik, > > After removing all references to actrecord, I got: > > octave:1> pkg install /home/miguel/Sources/aaudio-0.2.0.tar.gz > warning: load_path: > /home/miguel/octave/aaudio-0.2.0/i686-pc-linux-gnu-api-v45+: No such > file or directory > /home/miguel/octave/aaudio-0.2.0/i686-pc-linux-gnu-api-v45+/aplayrec.oct: > failed to load: > /home/miguel/octave/aaudio-0.2.0/i686-pc-linux-gnu-api-v45+/aplayrec.oct: > undefined symbol: snd_pcm_sw_params_set_start_threshold > error: called from `gen_doc_cache>create_cache' in file > /usr/share/octave/3.4.2/m/help/gen_doc_cache.m near line 93, column 17 > error: called from: > error: /usr/share/octave/3.4.2/m/pkg/pkg.m at line 832, column 5 > error: /usr/share/octave/3.4.2/m/pkg/pkg.m at line 361, column 9 > octave:1> > > If I try to run a command I get: > > octave:1> aplay > warning: load_path: > /home/miguel/octave/aaudio-0.2.0/i686-pc-linux-gnu-api-v45+: No such > file or directory > warning: timestamp on file > /home/miguel/octave/aaudio-0.2.0/i686-pc-linux-gnu-api-v45+/aplay.oct > is in the future > error: /home/miguel/octave/aaudio-0.2.0/i686-pc-linux-gnu-api-v45+/aplay.oct: > failed to load: > /home/miguel/octave/aaudio-0.2.0/i686-pc-linux-gnu-api-v45+/aplay.oct: > cannot open shared object file: No such file or directory > octave:1> > > Cheers, >

1 0

[alsa-devel] ASoC DSP and related status
by Stephen Warren 01 Sep '11

01 Sep '11

Liam, Mark, I was recently talking to our internal audio team, extolling the virtues of writing upstreamable drivers for Tegra's audio HW. One of the big unknowns here is how to represent the Tegra DAS and AHUB modules[1] in a standard fashion, and allowing configuration via kcontrols that influence DAPM routing, rather than open-coding and/or hard-coding such policy in the ASoC machine driver. So, my questions are: * What's the status of the ASoC DSP work. I see that some of the base infra-structure has been merged into ASoC's for-next branch, but I think that's just a small portion of the work. Do you have any kind of estimate for when the whole thing will be merged? I don't see recent updates to e.g. Liams' topic/dsp or topic/dsp-upstream branches. * Back in March in another DSP-related thread, Mark mentioned that the DSP rework was mainly about configuring stuff within a device, but that Mark was working on some code to support autonomous inter-device links. I assume that Tegra's DAS/AHUB would rely on the DSP work, not the stuff Mark mentioned? See the last few paragraphs of: http://mailman.alsa-project.org/pipermail/alsa-devel/2011-March/037776.html Related, Mark also mentioned something about representing the DAS/AHUB as codecs. I'm not sure if that was meant as a stop-gap solution before the DSP work was in place, or if that's part of supporting DAAS/AHUB within the DSP infra-structure. Thanks for any kind of information! Any information here will simply help us plan for when we might be able to switch from open-coding some of the more advanced Tegra audio support to more standardized solutions. [1] Here's a very quick overview of the relevant Tegra audio HW: DAS: Part of Tegra20. Tegra20 has Digital Audio controllers (DACs) i.e. I2S controllers. It also has Digital Audio Ports (DAPs). The Digital Audio Switch (DAS ) sits between. Each DAP selects its audio output from a particular DAC's or DAP's output. Each DAC selects its audio input from a particular DAP. DAP<-> DAP is supported, with one being the master the other the slave. Note that I2S configuration (channels, sample size, I2S vs. DSP etc) is configured in the DAC not the DAP. AHUB: Part of Tegra30. Tegra30 has an interconnect called the Audio HUB (AHUB). Various devices attach to this: FIFOs to send/receive audio to CPU memory using DMA, DAMs that receive n(2?) channels from the AHUB and mix/SRC them sending the result back to the AHUB, and finally various IO controllers such as I2S and SPDIF. The AHUB is I believe a full cross-bar. In this case, the I2S formatting is configured solely within the I2S controllers, not on the other side of the AHUB as is the case with the Tegra20 DAS. FIFOs also independently determine the number of channels/bit they send/ receive. There is some limited support for channel count and bitsize conversion at each attachment point to the AHUB. I2S<->I2S loopback may be supported in HW, at least in some cases. -- nvpublic

3 5

[alsa-devel] Have multiple opens removed on one device?
by Scott Jiang 01 Sep '11

01 Sep '11

Hi Mark and Takashi, In kernel 2.6.34 I can use aplay to play audio at the same time, alsa will mix the audio. Now the second open will return device busy. So it seems this feature has been removed. What's the proper approach for this operation at present? Thanks. Scott

3 4