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

[alsa-devel] soc-dsp questions
by pl bossart 13 Jun '11

13 Jun '11

To prepare next week's ALSA-Asoc meeting, I reviewed Liam's dsp-upstream code, and I am a bit unclear on the 'no_host_mode' supported by some DAIs. Apparently these are regular ALSA PCM substreams, except that there are no data exchanges to/from the host. - If these substreams are known, an application can in theory open/close them. How would it know that no data is to be written/read? I would think additional changes are required in alsa-lib? - is this really important that such PCM devices be known in userspace? Or are they declared only so that ALSA controls are enabled for these streams? - along the same lines, how useful is the .pointer routine for such devices? Since no data will be provided by the host, is this really needed? I see it's only meaningful for the low-power playback mode, but I am unsure if the information provided would actually be used by anyone? - what is the meaning of the SND_SOC_DAI_LINK_OPT_HOST definition? It doesn't seem to be updated depending on which back-end is used, so it this really needed? Thanks -Pierre

5 10

[alsa-devel] Creative X-Fi Titanium HD ctxfi bugs 5378 5218 4868
by Harry Butterworth 11 Jun '11

11 Jun '11

Hello folks, I bought an X-Fi Titanium HD thinking it would work with the ctxfi driver but it is a new card and has a few differences from the earlier cards. Creative technical support have been quite helpful in answering my questions. This email is a heads-up to let you know that I'm doing some work on the driver. I'm not finished yet. In particular the PLL initialization still does not work reliably, the capture source selection is a bit broken and one of the ADC chips is being driven out-of-spec when the card is run at 192kHz. I have attached the current state of my changes which are enough to get the Titanium HD card working but the patch shouldn't be applied because my hack at the PLL code and a couple of other bits may break existing cards. I have been working against the ALSA 1.0.24 release so this is a patch against 1.0.24. I'm waiting for creative to answer my questions about the PLL initialization and correct setup for 196kHz operation. Once I get the answers I'll try to fix the issues and submit a cleaner patch. Comments on the current version are welcome. Harry

3 4

[alsa-devel] [PATCH] ALSA: HDA: Add jack detection for HDMI
by David Henningsson 09 Jun '11

09 Jun '11

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer. I considered making additional SND_JACK_* constants for HDMI and Displayport instead of going with SND_JACK_VIDEOOUT, but it didn't seem worth the additions, and breakage of compiling with old kernels, etc. Let me know if you think otherwise and I'll prepare a second patch for that. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

7 33

[alsa-devel] [RFC PATCH] Add combined clock support to Atmel SoC audio
by Ryan Mallon 07 Jun '11

07 Jun '11

The following patch is one that has been floating around in various forms in our own internal trees for a while. The Atmel SSC peripheral has seperate TX and RX clocks which use separate pins from the the micro. TF (frame) and TK (clock) for transmit and RF and RK for receive. Not all codecs have separate frame and bit clocks for transmit and receive so we want to be able to do both playback and capture using a single set of pins. This patch introduces a combined clock mode for the Atmel SSC peripheral. Which allows playback and capture to use a single set of pins. Currently combined clock is only supported on the TF/TK pins (some incomplete support exists for using RF/RK). I have tested this patch on our AT91SAM9G45 + TLV320AIC26 platform. Playback and capture work individually. Simultaneous playback and capture have been tested by connecting a loopback cable on the linein and lineout jacks and then doing: arecord -c 2 -f S16_LE -r 44100 > recording.wav & aplay 500hz_sine.wav This patch is posted as RFC since the approach is incomplete and a bit hackish. I am mostly interested in knowing if this is a sensible approach, and could be cleaned up for mainline inclusion, or if there is a better way to do this. Signed-off-by: Ryan Mallon <ryan(a)bluewatersys.com> --- diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c index 5d230ce..ee00172 100644 --- a/sound/soc/atmel/atmel_ssc_dai.c +++ b/sound/soc/atmel/atmel_ssc_dai.c @@ -43,6 +43,7 @@ #include <sound/soc.h> #include <mach/hardware.h> +#include <asm/atomic.h> #include "atmel-pcm.h" #include "atmel_ssc_dai.h" @@ -246,7 +247,18 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream, dma_params = ssc_p->dma_params[dir]; if (dma_params != NULL) { - ssc_writel(ssc_p->ssc->regs, CR, dma_params->mask->ssc_disable); + if (ssc_p->combined_clock) { + /* + * When using a combined clock we only disable the + * clock once all substreams have completed + */ + if (atomic_dec_and_test(&ssc_p->substreams_running)) + ssc_writel(ssc_p->ssc->regs, CR, + dma_params->mask->ssc_disable); + } else { + ssc_writel(ssc_p->ssc->regs, CR, + dma_params->mask->ssc_disable); + } pr_debug("atmel_ssc_shutdown: %s disabled SSC_SR=0x%08x\n", (dir ? "receive" : "transmit"), ssc_readl(ssc_p->ssc->regs, SR)); @@ -328,6 +340,21 @@ static int atmel_ssc_set_dai_clkdiv(struct snd_soc_dai *cpu_dai, return 0; } +void atmel_ssc_setup_combined_clock(struct atmel_ssc_info *ssc_p, + int combined_clock) +{ + int i; + + ssc_p->combined_clock = combined_clock; + for (i = 0; i < ARRAY_SIZE(ssc_dma_params); i++) { + if (ssc_p->combined_clock == ATMEL_SSC_CLOCK_TX_ON_RX) + ssc_dma_params[i][0].mask->ssc_enable |= SSC_BIT(CR_RXEN); + else if (ssc_p->combined_clock == ATMEL_SSC_CLOCK_RX_ON_TX) + ssc_dma_params[i][1].mask->ssc_enable |= SSC_BIT(CR_TXEN); + } +} +EXPORT_SYMBOL(atmel_ssc_setup_combined_clock); + /* * Configure the SSC. */ @@ -548,6 +575,34 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream, ssc_p->daifmt); return -EINVAL; } + + if (ssc_p->combined_clock == ATMEL_SSC_CLOCK_RX_ON_TX) { + /* RX clock is always running */ + rcmr &= ~SSC_BF(RCMR_CKO, 0x7); + rcmr |= SSC_BF(RCMR_CKO, SSC_CKO_CONTINUOUS); + + /* TX clock is always running */ + tcmr &= ~SSC_BF(TCMR_CKO, 0x7); + tcmr |= SSC_BF(TCMR_CKO, SSC_CKO_CONTINUOUS); + + /* RX clock is sourced from TK pin */ + rcmr &= ~SSC_BF(RCMR_CKS, 0x7); + rcmr |= SSC_BF(RCMR_CKS, SSC_CKS_CLOCK); + + /* Start RX on TX start */ + rcmr &= ~SSC_BF(RCMR_START, 0xf); + rcmr |= SSC_BF(RCMR_START, SSC_START_TX_RX); + + if (dir == 1) { + /* + * Set the TX clock period to the RX clock period + * FIXME - Is this okay if we are already doing TX? + */ + tcmr &= 0x00ffffff; + tcmr |= rcmr & 0xff000000; + } + } + pr_debug("atmel_ssc_hw_params: " "RCMR=%08x RFMR=%08x TCMR=%08x TFMR=%08x\n", rcmr, rfmr, tcmr, tfmr); @@ -581,6 +636,9 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream, return ret; } + if (ssc_p->combined_clock) + atomic_set(&ssc_p->substreams_running, 0); + ssc_p->initialized = 1; } @@ -616,6 +674,21 @@ static int atmel_ssc_prepare(struct snd_pcm_substream *substream, ssc_writel(ssc_p->ssc->regs, CR, dma_params->mask->ssc_enable); + if (ssc_p->combined_clock) { + atomic_inc(&ssc_p->substreams_running); + + if (ssc_p->combined_clock == ATMEL_SSC_CLOCK_RX_ON_TX && + dir == 1) { + /* + * Jump start the dma for capture by loading the + * transmit holding register with a dummy value. + */ + pr_debug("Jump starting SSC RX DMA\n"); + if (!(ssc_readl(ssc_p->ssc->regs, SR) & (1 << 16))) + ssc_writel(ssc_p->ssc->regs, THR, 0); + } + } + pr_debug("%s enabled SSC_SR=0x%08x\n", dir ? "receive" : "transmit", ssc_readl(ssc_p->ssc->regs, SR)); diff --git a/sound/soc/atmel/atmel_ssc_dai.h b/sound/soc/atmel/atmel_ssc_dai.h index 5d4f0f9..6b20ee6 100644 --- a/sound/soc/atmel/atmel_ssc_dai.h +++ b/sound/soc/atmel/atmel_ssc_dai.h @@ -102,6 +102,8 @@ struct atmel_ssc_state { u32 ssc_imr; }; +#define ATMEL_SSC_CLOCK_RX_ON_TX 1 +#define ATMEL_SSC_CLOCK_TX_ON_RX 2 struct atmel_ssc_info { char *name; @@ -115,8 +117,14 @@ struct atmel_ssc_info { unsigned short rcmr_period; struct atmel_pcm_dma_params *dma_params[2]; struct atmel_ssc_state ssc_state; + + /* For combined clocks */ + int combined_clock; + atomic_t substreams_running; }; int atmel_ssc_set_audio(int ssc); +extern void atmel_ssc_setup_combined_clock(struct atmel_ssc_info *ssc_p, + int combined_clock); #endif /* _AT91_SSC_DAI_H */

3 6

[alsa-devel] [PATCH] ASoC: Update omap/ams-delta for TTY API change
by Janusz Krzysztofik 06 Jun '11

06 Jun '11

Following the receive_buf() change to return the number of bytes received, the cx20442 CODEC driver was updated to report that we accepted all the data that was offered to us. Do the same with the corresponding Amstrad Delta sound card level wrapper function, which is actually registered as the tty line discipline callback instead of the the CODEC function, which it then calls. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- sound/soc/omap/ams-delta.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- git/sound/soc/omap/ams-delta.c.orig 2011-04-09 00:39:54.000000000 +0200 +++ git/sound/soc/omap/ams-delta.c 2011-05-12 18:50:33.000000000 +0200 @@ -331,7 +331,7 @@ static int cx81801_hangup(struct tty_str } /* Line discipline .recieve_buf() */ -static void cx81801_receive(struct tty_struct *tty, +static unsigned int cx81801_receive(struct tty_struct *tty, const unsigned char *cp, char *fp, int count) { struct snd_soc_codec *codec = tty->disc_data; @@ -347,7 +347,7 @@ static void cx81801_receive(struct tty_s /* Initialize timer used for config pulse generation */ setup_timer(&cx81801_timer, cx81801_timeout, 0); - v253_ops.receive_buf(tty, cp, fp, count); + ret = v253_ops.receive_buf(tty, cp, fp, count); /* Link hook switch to DAPM pins */ ret = snd_soc_jack_add_pins(&ams_delta_hook_switch, @@ -358,10 +358,10 @@ static void cx81801_receive(struct tty_s "Failed to link hook switch to DAPM pins, " "will continue with hook switch unlinked.\n"); - return; + return count; } - v253_ops.receive_buf(tty, cp, fp, count); + ret = v253_ops.receive_buf(tty, cp, fp, count); for (c = &cp[count - 1]; c >= cp; c--) { if (*c != '\r') @@ -381,6 +381,7 @@ static void cx81801_receive(struct tty_s AMS_DELTA_LATCH2_MODEM_CODEC); break; } + return count; } /* Line discipline .write_wakeup() */

4 10

[alsa-devel] AudioArduino - an ALSA soundcard driver for FTDI-based Arduinos
by sdaau 04 Jun '11

04 Jun '11

Hi all, (cross-posting to alsa-devel(a)alsa-project.org and gmane.linux.usb.general/linux-usb(a)vger.kernel.org; apologies if it's inappropriate) I'd just like to inform that the AudioArduino project has been posted online: http://imi.aau.dk/~sd/phd/index.php?title=AudioArduino It contains links to open-source Arduino microcontroller code, and corresponding ALSA driver source code - which can demonstrate mono, full-duplex, 8-bit / 44.1 kHz soundcard operation on an FTDI-based Arduino. There is also a related post on the (new) Arduino Forum: http://arduino.cc/forum/index.php/topic,62582.0.html The driver essentially represents an ALSA extension to ftdi-sio (which is why I thought it would be relevant to both alsa-devel, and linux-usb). Many thanks to the community for critical help, like in: ftdi_sio, and usb_serial->interface->dev->driver_data being null http://comments.gmane.org/gmane.linux.usb.general/30455 Help with dummy.c (where/how to write?) http://comments.gmane.org/gmane.linux.alsa.devel/74487 Looking forward to any feedback regarding this project, Cheers!

3 5

[alsa-devel] Need general idea how to architect driver for multi-codec board
by Caleb Crome 04 Jun '11

04 Jun '11

Hello All, I'm building a board with multiple TLV320AIC33 codecs on board, and I don't know how I should architect the interface. The board is set up to use TDM (16 channels on 1 TDM PORT), it has 16 input and 16 output channels, all bonded together -- the hardware does not allow different codecs to run at different speeds. The board also includes several other widgets, like an I2C mux (to address all 8 stereo codecs), a couple of power amplifiers, and a limited number of ways the audio can be routed in or out. My question is this: I'm not sure how to architect the driver: 1) Simply instantiate multiple TLV320IAC33 codec drivers, as the AIC33 driver is already written. This seems like it won't work because I'd end up with multiple user-space 'cards', yet I want the card to appear as a single 16-channel sound card. Also, when you start one PCM interface for one codec, they would all start automatically, which I imagine the linux system wouldn't get. Also, the PCM interface needs to be configured differently for each codec (the TDM offset must be 0, 16, 32, 48, etc. bits). 2) rewrite the AIC33 driver to include all 8 codecs, including all the mixer controls for each codec. This is going to get REALLY big and ugly in the user space mixer control -- there will be a zillion controls, most of which are not really useful for this board. 3) rewrite the AIC33 driver to include all 8 codecs, but pare down the mixer controls to just the ones that I care about. If the card changes later, add in the changes to the driver. I don't have any huge desire to get the driver into the mainstream kernel (though I would not be upset if it was popular enough to warrant that), it's just not a priority. Any thoughts would be most welcome. Thanks, -Caleb

2 10

Re: [alsa-devel] [PATCH] cm6206: turn off de-emphasis in s/pdif (fwd)
by Eric Lammerts 03 Jun '11

03 Jun '11

Hi, I submitted this a while ago but nothing happened. Could you apply this patch? I rediffed against the current git. thanks, Eric ---------- Forwarded message ---------- Date: Sun, 21 Nov 2010 20:23:11 -0500 (EST) From: Eric Lammerts <alsa-devel(a)lists.lammerts.org> To: Clemens Ladisch <clemens(a)ladisch.de> Cc: Dan Allongo <gongo2k1(a)gmail.com>, alsa-devel(a)alsa-project.org Subject: Re: [alsa-devel] [PATCH] cm6206: turn off de-emphasis in s/pdif On Thu, 18 Nov 2010, Clemens Ladisch wrote: > Thanks. Please provide a Signed-off-by tag as described in > Documentation/SubmittingPatches. CM6206: Turn off de-emphasis channel status bit in S/PDIF output. Signed-off-by: Eric Lammerts <eric(a)lammerts.org> diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index 355759b..e006d3c 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -387,7 +387,7 @@ static int snd_usb_cm106_boot_quirk(struct usb_device *dev) static int snd_usb_cm6206_boot_quirk(struct usb_device *dev) { int err, reg; - int val[] = {0x200c, 0x3000, 0xf800, 0x143f, 0x0000, 0x3000}; + int val[] = {0x2004, 0x3000, 0xf800, 0x143f, 0x0000, 0x3000}; for (reg = 0; reg < ARRAY_SIZE(val); reg++) { err = snd_usb_cm106_write_int_reg(dev, reg, val[reg]);

2 1

Re: [alsa-devel] [PATCH] thinkpad-acpi: Enable microphone mute LED
by Andrew Lutomirski 03 Jun '11

03 Jun '11

On Fri, May 27, 2011 at 12:48 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > On Fri, May 27, 2011 at 12:39:10PM -0400, Andrew Lutomirski wrote: > >> I don't have docs so I don't really know. But the mute LED does not >> appear to be controllable from the LED interface and when mute is lit >> there's no sound regardless of what ALSA thinks. When I light the >> micmute light, I can still record sound just fine. >> >> The mic mute button does nothing on Windows unless the special driver >> is installed, and that driver seems to mute the Windows mixer, so I >> think there's nothing special other than a little userspace helper >> going on. > > Hm. That makes things kind of tricky. While it's easy to just expose the > LED, really we want to do it in such a way that userspace knows which > LEDs it should be toggling while setting the microphone mute. One thought: call the thing laptop::micmute and teach userspace to look for an led with that name. Do any of the ALSA or PulseAudio people have any preferences? --Andy

3 2

[alsa-devel] [alsa-lib] Possible bug in function 'snd_ctl_hw_open', file control_hw.c
by alex dot baldacchino dot alsasub at gmail dot com 03 Jun '11

03 Jun '11

Hello, I've noticed at some point function snd_ctl_hw_open() calls snd_ctl_new() to allocate memory for variable snd_ctl_t *ctl; then it tries to handle an error condition, but, regardless of such an error, memory locations pointed by ctl are accessed and filled in (eventually with invalid data, since the error causes 'fd' to be closed and 'hw' to be freed). Since ctl could point a random area in case of allocation failure, perhaps the function should return if such an error occurs and avoid dereferencing it. An easy fix would be the following, unless I'm missing something. ------------------------------------------------------ control_hw.patch -------------------------------------------------------------- --- old/src/control/control_hw.c 2011-05-31 14:20:12.975999400 +0200 +++ new/src/control/control_hw.c 2011-05-31 14:21:35.559999388 +0200 @@ -414,6 +414,7 @@ if (err < 0) { close(fd); free(hw); + return err; } ctl->ops = &snd_ctl_hw_ops; ctl->private_data = hw;

2 1