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

[alsa-devel] [PATCH] ALSA: usb: Work around CM6631 sample rate change bug
by Torstein Hegge 05 Mar '13

05 Mar '13

The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sampling frequency while the interface is active. Reset the interface after setting the sampling frequency, to ensure that the sample rate set by snd_usb_init_sample_rate() is used. Otherwise, the device will try to use the sample rate of the previous file, causing distorted sound on sample rate changes. Signed-off-by: Torstein Hegge <hegge(a)resisty.net> --- sound/usb/pcm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index d82e378..01978a6 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -710,6 +710,16 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream) subs->need_setup_ep = false; } + /* Some devices doesn't respond to sample rate changes while the + * interface is active. */ + switch (subs->stream->chip->usb_id) { + case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */ + case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */ + usb_set_interface(subs->dev, subs->cur_audiofmt->iface, + subs->cur_audiofmt->altset_idx); + break; + } + /* some unit conversions in runtime */ subs->data_endpoint->maxframesize = bytes_to_frames(runtime, subs->data_endpoint->maxpacksize); -- 1.7.10.4

4 11

Re: [alsa-devel] common way for hardware metering and monitoring between kernel/user land
by Clemens Ladisch 05 Mar '13

05 Mar '13

Takashi Sakamoto wrote: > Now i'm working in kernel land to support Echo's Fireworks (TM) devices > with better integration. > [...] > Well, now I need your advice about common ways for hardware metering and > monitoring between kernel land and user land. For almost all FireWire audio devices, it would not be possible to create ALSA mixer controls that would allow to control the device in a sensible way with a generic mixer application like alsamixer. (Things like matrix mixers, or meters integrated with corresponding volume sliders.) Therefore, custom mixer applications are required. Because devices typically have most of their customizations in the way in which they handle (mixer) controls, the FFADO guys and me have agreed that the kernel driver handles only stuff required for audio streaming; all other controls are accessed *only* from user space by going directly through /dev/fw* (or through a hwdep device if the kernel driver and userspace tools need to share a communication channel). So for now, there's no integration needed in the kernel driver. (I won't have time to test your driver before the next weekend.) Regards, Clemens

1 0

[alsa-devel] ASoC: no-pcm (backend) error propagation
by Frkuska, Joshua 05 Mar '13

05 Mar '13

Hello, I am working off of the 3.5.7 branch of the kernel using a frontend-backend approach for my driver. No additional patches have been added for ASoC/ALSA from the 3.5.7 kernel branch. My question relates to the way the no-pcm (backend) propagates errors to the front end. My FE(frontend) consists of a cpu-dai, a pcm platform driver, and a dummy-codec. My BE(backend) consists of another cpu-dai, a non-pcm platform driver, and a real codec. The non-pcm operates with the dmaengine but just in an autonomous fashion external to the PCM's knowledge. I have the pcm-platform driver passing data to the FE cpu-dai and the backend platform then takes the data from the frontend's cpu-dai and passes it on to the BE cpu-dai, which then configures the codec-dai to get output. In the frontend if/whenever there is an underrun error in the cpu-dai, I can directly call snd_pcm_stop to stop the stream and report the error state. I can do this because the substream->ops have properly been defined in the frontend pcm. However, in the backend, the substream->ops never get initialized and rightfully so since there isn't a valid pcm for the backend. My question is, what is the correct/any way to let the frontend PCM stream know that an underrun has occurred in the backend? Is there a mechanism to handle this in ASoC? Looking through the code, I cannot find such a mechanism. I have a feeling that there should be something like snd_soc_pcm_stop to check to see if we are in a FE/BE configuration and act accordingly to stop the FE PCM stream and report errors. Again, perhaps such a mechanism exists and if so any help would be appreciated. Thanks for your time and any comments/suggestions, Joshua

4 10

[alsa-devel] am335x: mcasp in DIT mode
by Yegor Yefremov 05 Mar '13

05 Mar '13

I've solved the problem with DIT/SPDIF mode (see the issue description here: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/247447/870030.aspx). In davinci_mcasp_hw_params() the DIT or I2S params will be set in the beginning. DIT mode configures the DAVINCI_MCASP_TXMASK_REG and DAVINCI_MCASP_TXFMT_REG. And here comes the problem: at the end of davinci_mcasp_hw_params() the davinci_config_channel_size() will touch the same registers again and thus overwrite the settings necessary for DIT. After I commented this routine I got the sound over S/PDIF and sii9022a HDMI transmitter and I could see the proper bits appearing on my oscilloscope. What were the best way to solve this problem? 1. execute davinci_config_channel_size() only if not in DIT mode? 2. for DIT only change the DAVINCI_MCASP_TXMASK_REG according to channel width? 3. execute if (dev->op_mode == DAVINCI_MCASP_DIT_MODE) davinci_hw_dit_param(dev); else davinci_hw_param(dev, substream->stream); after davinci_config_channel_size() Yegor

3 11

[alsa-devel] [PATCH v2] ALSA: usb: Work around CM6631 sample rate change bug
by Torstein Hegge 05 Mar '13

05 Mar '13

The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sample rate while the interface is active. Reset the interface after setting the sampling frequency on sample rate changes, to ensure that the sample rate set by snd_usb_init_sample_rate() is used. Otherwise, the device will try to use the sample rate of the previous stream, causing distorted sound on sample rate changes. Signed-off-by: Torstein Hegge <hegge(a)resisty.net> --- sound/usb/clock.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/sound/usb/clock.c b/sound/usb/clock.c index 5e634a2..d12a9c4 100644 --- a/sound/usb/clock.c +++ b/sound/usb/clock.c @@ -255,6 +255,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, unsigned char data[4]; int err, crate; int clock = snd_usb_clock_find_source(chip, fmt->clock); + unsigned int previous_rate; if (clock < 0) return clock; @@ -266,6 +267,18 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, return -ENXIO; } + if ((err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), UAC2_CS_CUR, + USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_IN, + UAC2_CS_CONTROL_SAM_FREQ << 8, + snd_usb_ctrl_intf(chip) | (clock << 8), + data, sizeof(data))) < 0) { + snd_printk(KERN_WARNING "%d:%d:%d: cannot get freq (v2)\n", + dev->devnum, iface, fmt->altsetting); + return err; + } + + previous_rate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); + data[0] = rate; data[1] = rate >> 8; data[2] = rate >> 16; @@ -294,6 +307,18 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, if (crate != rate) snd_printd(KERN_WARNING "current rate %d is different from the runtime rate %d\n", crate, rate); + /* Some devices doesn't respond to sample rate changes while the + * interface is active. */ + if (crate != previous_rate) { + switch (chip->usb_id) { + case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB */ + case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */ + usb_set_interface(dev, iface, 0); + usb_set_interface(dev, iface, fmt->altsetting); + break; + } + } + return 0; } -- 1.7.10.4

2 2

[alsa-devel] HDA Beep Device for Asus EeeBox EB1501P
by Harald Becker 05 Mar '13

05 Mar '13

Hi, I own an Asus EeeBox EB1501P with an ALC662 codec and had no HDA mixer channel for the speaker beep device. After digging somewhat in the kernel source I found that I only need to add a single line in the beep_white_list in patch_realtek.c. May be this entry can be included in the mainstream drivers: SND_PCI_QUIRK(0x1043, 0x8376, "EeePC", 1), After recompiling the driver with this entry, the mixer device for the beep channel appears and the digital beep sound is emitted on the connected speakers. ... with one problem: If I use echo -e "\a" in a shell or run the beep command utility the sound appears only on second and following invocations. Whenever the frequency changes with the beep command the first invocation stays silent or just produce some click due to ALSA driver power saving. On all further invocations with same frequency the requested tone is generated on external speakers. There is no difference in behavior if the commands are called in a terminal emulator or directly on a virtual text console. Does this happen only on my machine or is this a known problem? Is there anything I can do to fix this behavior? The kernel I used for testing is 3.8.0 from Gentoo Sources. Feel free to ask for any information you may need for debugging. Thx for any help ahead Harald

2 5

Re: [alsa-devel] [PATCH 1/5 v7][RFC] ASoC: add snd_soc_register_cpu()
by Mark Brown 05 Mar '13

05 Mar '13

On Mon, Mar 04, 2013 at 07:48:36PM +0000, Liam Girdwood wrote: > I think we probably have more in common between platforms and codecs now > than we have that is different (certainly, things were very different in > the past). But you are right, is it really worth the big churn..... Definitely, I'm just not sure that the existing platform object really captures the new bits or if it maps more onto DAIs.

1 0

[alsa-devel] [PATCH V2] ASoC: tegra: fix I2S bit count mask
by Stephen Warren 05 Mar '13

05 Mar '13

From: Stephen Warren <swarren(a)nvidia.com> This register field is 11 bits wide, not 15 bits wide. Given the way this value is currently, used, this patch has no practical effect. However, it's still best if the value is correct. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- v2: Apply fix to Tegra20 as well as Tegra30. --- sound/soc/tegra/tegra20_i2s.h | 2 +- sound/soc/tegra/tegra30_i2s.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/tegra/tegra20_i2s.h b/sound/soc/tegra/tegra20_i2s.h index c27069d..7299587 100644 --- a/sound/soc/tegra/tegra20_i2s.h +++ b/sound/soc/tegra/tegra20_i2s.h @@ -121,7 +121,7 @@ #define TEGRA20_I2S_TIMING_NON_SYM_ENABLE (1 << 12) #define TEGRA20_I2S_TIMING_CHANNEL_BIT_COUNT_SHIFT 0 -#define TEGRA20_I2S_TIMING_CHANNEL_BIT_COUNT_MASK_US 0x7fff +#define TEGRA20_I2S_TIMING_CHANNEL_BIT_COUNT_MASK_US 0x7ff #define TEGRA20_I2S_TIMING_CHANNEL_BIT_COUNT_MASK (TEGRA20_I2S_TIMING_CHANNEL_BIT_COUNT_MASK_US << TEGRA20_I2S_TIMING_CHANNEL_BIT_COUNT_SHIFT) /* Fields in TEGRA20_I2S_FIFO_SCR */ diff --git a/sound/soc/tegra/tegra30_i2s.h b/sound/soc/tegra/tegra30_i2s.h index 34dc47b..a294d94 100644 --- a/sound/soc/tegra/tegra30_i2s.h +++ b/sound/soc/tegra/tegra30_i2s.h @@ -110,7 +110,7 @@ #define TEGRA30_I2S_TIMING_NON_SYM_ENABLE (1 << 12) #define TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_SHIFT 0 -#define TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_MASK_US 0x7fff +#define TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_MASK_US 0x7ff #define TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_MASK (TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_MASK_US << TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_SHIFT) /* Fields in TEGRA30_I2S_OFFSET */ -- 1.7.10.4

2 1

[alsa-devel] [PATCH] ASoC: arizona: If we only have a clock to synchronise with make it REFCLK
by Mark Brown 05 Mar '13

05 Mar '13

If there is only one clock active the FLL should use REFCLK rather than SYNCCLK as the clock to synchronise with since REFCLK is always required. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.c | 76 ++++++++++++++++++++++---------------------- 1 file changed, 38 insertions(+), 38 deletions(-) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index e456cb4..0599ff8 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -1132,14 +1132,30 @@ static void arizona_enable_fll(struct arizona_fll *fll, struct arizona *arizona = fll->arizona; int ret; - regmap_update_bits(arizona->regmap, fll->base + 5, - ARIZONA_FLL1_OUTDIV_MASK, - ref->outdiv << ARIZONA_FLL1_OUTDIV_SHIFT); - - arizona_apply_fll(arizona, fll->base, ref, fll->ref_src); - if (fll->sync_src >= 0) - arizona_apply_fll(arizona, fll->base + 0x10, sync, + /* + * If we have both REFCLK and SYNCCLK then enable both, + * otherwise apply the SYNCCLK settings to REFCLK. + */ + if (fll->ref_src >= 0 && fll->ref_src != fll->sync_src) { + regmap_update_bits(arizona->regmap, fll->base + 5, + ARIZONA_FLL1_OUTDIV_MASK, + ref->outdiv << ARIZONA_FLL1_OUTDIV_SHIFT); + + arizona_apply_fll(arizona, fll->base, ref, fll->ref_src); + if (fll->sync_src >= 0) + arizona_apply_fll(arizona, fll->base + 0x10, sync, + fll->sync_src); + } else if (fll->sync_src >= 0) { + regmap_update_bits(arizona->regmap, fll->base + 5, + ARIZONA_FLL1_OUTDIV_MASK, + sync->outdiv << ARIZONA_FLL1_OUTDIV_SHIFT); + + arizona_apply_fll(arizona, fll->base, sync, fll->sync_src); + } else { + arizona_fll_err(fll, "No clocks provided\n"); + return; + } if (!arizona_is_enabled_fll(fll)) pm_runtime_get(arizona->dev); @@ -1149,7 +1165,8 @@ static void arizona_enable_fll(struct arizona_fll *fll, regmap_update_bits(arizona->regmap, fll->base + 1, ARIZONA_FLL1_ENA, ARIZONA_FLL1_ENA); - if (fll->sync_src >= 0) + if (fll->ref_src >= 0 && fll->sync_src >= 0 && + fll->ref_src != fll->sync_src) regmap_update_bits(arizona->regmap, fll->base + 0x11, ARIZONA_FLL1_SYNC_ENA, ARIZONA_FLL1_SYNC_ENA); @@ -1180,9 +1197,6 @@ int arizona_set_fll_refclk(struct arizona_fll *fll, int source, struct arizona_fll_cfg ref, sync; int ret; - if (source < 0) - return -EINVAL; - if (fll->ref_src == source && fll->ref_freq == Fref) return 0; @@ -1216,39 +1230,25 @@ int arizona_set_fll(struct arizona_fll *fll, int source, struct arizona_fll_cfg ref, sync; int ret; - if (fll->ref_src < 0 || fll->ref_src == source) { - if (fll->sync_src == ARIZONA_FLL_SRC_NONE && - fll->ref_src == source && fll->ref_freq == Fref && - fll->fout == Fout) - return 0; - - if (Fout) { - ret = arizona_calc_fll(fll, &ref, Fref, Fout); - if (ret != 0) - return ret; - } - - fll->sync_src = ARIZONA_FLL_SRC_NONE; - fll->ref_src = source; - fll->ref_freq = Fref; - } else { - if (fll->sync_src == source && - fll->sync_freq == Fref && fll->fout == Fout) - return 0; - - if (Fout) { - ret = arizona_calc_fll(fll, &ref, fll->ref_freq, Fout); - if (ret != 0) - return ret; + if (fll->sync_src == source && + fll->sync_freq == Fref && fll->fout == Fout) + return 0; - ret = arizona_calc_fll(fll, &sync, Fref, Fout); + if (Fout) { + if (fll->ref_src >= 0) { + ret = arizona_calc_fll(fll, &ref, fll->ref_freq, + Fout); if (ret != 0) return ret; } - fll->sync_src = source; - fll->sync_freq = Fref; + ret = arizona_calc_fll(fll, &sync, Fref, Fout); + if (ret != 0) + return ret; } + + fll->sync_src = source; + fll->sync_freq = Fref; fll->fout = Fout; if (Fout) { -- 1.7.10.4

1 0

[alsa-devel] [PATCH] ASoC: tegra: fix I2S bit count mask
by Stephen Warren 04 Mar '13

04 Mar '13

From: Stephen Warren <swarren(a)nvidia.com> This register field is 11 bits wide, not 15 bits wide. Given the way this value is currently, used, this patch has no practical effect. However, it's still best if the value is correct. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/tegra/tegra30_i2s.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/tegra/tegra30_i2s.h b/sound/soc/tegra/tegra30_i2s.h index 34dc47b..a294d94 100644 --- a/sound/soc/tegra/tegra30_i2s.h +++ b/sound/soc/tegra/tegra30_i2s.h @@ -110,7 +110,7 @@ #define TEGRA30_I2S_TIMING_NON_SYM_ENABLE (1 << 12) #define TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_SHIFT 0 -#define TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_MASK_US 0x7fff +#define TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_MASK_US 0x7ff #define TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_MASK (TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_MASK_US << TEGRA30_I2S_TIMING_CHANNEL_BIT_COUNT_SHIFT) /* Fields in TEGRA30_I2S_OFFSET */ -- 1.7.10.4

1 0