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

[alsa-devel] Rane SL2/3/4 driver?
by Be 01 Apr '15

01 Apr '15

Hi, I recently published the first version of Crossfade GNU/Linux, a distro for DJing from USB drives on any PC (see http://mixxx.org/forums/viewtopic.php?f=1&t=7031 for details). I just tried it on my friend's Macbook which he uses with a Rane SL4 USB sound card. I realized there is no Linux driver for the current line of sound cards sold for digital vinyl emulation with Serato DJ. These are the Rane SL2, SL3, and SL4 (http://serato.com/hardware/all/mixers-interfaces ; the Denon DS1 was also recently announced but not available yet: http://serato.com/latest/blog/17973/announcing-denon-ds1 ). They range from 4 in/4 out to 10 in/10 out and all have phono preamps built in. There appears to be support for the old and discontinued Rane SL1, which used USB 1.1, but the SL2/3/4 use USB 2.0. Has anyone thought about writing a driver for these?

1 1

[alsa-devel] [RESEND PATCH] MAINTAINERS: change the Atmel audio alsa driver entry
by Nicolas Ferre 31 Mar '15

31 Mar '15

I take over the the maintainship of Atmel alsa drivers from Voice. Thanks for your work! Signed-off-by: Nicolas Ferre <nicolas.ferre(a)atmel.com> Acked-by: Bo Shen <voice.shen(a)atmel.com> Cc: Mark Brown <broonie(a)kernel.org> --- Hi Mark, Here is the MAINTAINERS' change that I sent to the wrong address. Can you please take it with your tree? Thanks, bye. MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 6cb40f8736ee..a915bb124fe7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1762,7 +1762,7 @@ S: Supported F: drivers/tty/serial/atmel_serial.c ATMEL Audio ALSA driver -M: Bo Shen <voice.shen(a)atmel.com> +M: Nicolas Ferre <nicolas.ferre(a)atmel.com> L: alsa-devel(a)alsa-project.org (moderated for non-subscribers) S: Supported F: sound/soc/atmel -- 2.1.3

2 1

[alsa-devel] [PATCH 1/4] ASoC: fsi: reorder code to make a forward declaration superfluous
by Uwe Kleine-König 31 Mar '15

31 Mar '15

Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> --- sound/soc/sh/fsi.c | 69 +++++++++++++++++++++++++++--------------------------- 1 file changed, 34 insertions(+), 35 deletions(-) diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c index b87b22e88e43..dab6aa661a22 100644 --- a/sound/soc/sh/fsi.c +++ b/sound/soc/sh/fsi.c @@ -1876,7 +1876,40 @@ static void fsi_handler_init(struct fsi_priv *fsi, } } -static struct of_device_id fsi_of_match[]; +static struct fsi_core fsi1_core = { + .ver = 1, + + /* Interrupt */ + .int_st = INT_ST, + .iemsk = IEMSK, + .imsk = IMSK, +}; + +static struct fsi_core fsi2_core = { + .ver = 2, + + /* Interrupt */ + .int_st = CPU_INT_ST, + .iemsk = CPU_IEMSK, + .imsk = CPU_IMSK, + .a_mclk = A_MST_CTLR, + .b_mclk = B_MST_CTLR, +}; + +static struct of_device_id fsi_of_match[] = { + { .compatible = "renesas,sh_fsi", .data = &fsi1_core}, + { .compatible = "renesas,sh_fsi2", .data = &fsi2_core}, + {}, +}; +MODULE_DEVICE_TABLE(of, fsi_of_match); + +static struct platform_device_id fsi_id_table[] = { + { "sh_fsi", (kernel_ulong_t)&fsi1_core }, + { "sh_fsi2", (kernel_ulong_t)&fsi2_core }, + {}, +}; +MODULE_DEVICE_TABLE(platform, fsi_id_table); + static int fsi_probe(struct platform_device *pdev) { struct fsi_master *master; @@ -2072,40 +2105,6 @@ static struct dev_pm_ops fsi_pm_ops = { .resume = fsi_resume, }; -static struct fsi_core fsi1_core = { - .ver = 1, - - /* Interrupt */ - .int_st = INT_ST, - .iemsk = IEMSK, - .imsk = IMSK, -}; - -static struct fsi_core fsi2_core = { - .ver = 2, - - /* Interrupt */ - .int_st = CPU_INT_ST, - .iemsk = CPU_IEMSK, - .imsk = CPU_IMSK, - .a_mclk = A_MST_CTLR, - .b_mclk = B_MST_CTLR, -}; - -static struct of_device_id fsi_of_match[] = { - { .compatible = "renesas,sh_fsi", .data = &fsi1_core}, - { .compatible = "renesas,sh_fsi2", .data = &fsi2_core}, - {}, -}; -MODULE_DEVICE_TABLE(of, fsi_of_match); - -static struct platform_device_id fsi_id_table[] = { - { "sh_fsi", (kernel_ulong_t)&fsi1_core }, - { "sh_fsi2", (kernel_ulong_t)&fsi2_core }, - {}, -}; -MODULE_DEVICE_TABLE(platform, fsi_id_table); - static struct platform_driver fsi_driver = { .driver = { .name = "fsi-pcm-audio", -- 2.1.4

2 6

[alsa-devel] [PATCH] ASoC: pcm512x: Do not redefine DIV_ROUND_CLOSEST_ULL
by Fabio Estevam 31 Mar '15

31 Mar '15

From: Fabio Estevam <fabio.estevam(a)freescale.com> DIV_ROUND_CLOSEST_ULL is already defined at <linux/kernel.h>, so use the definition from this header file rather than re-defining it locally. This fixes the following build warning: sound/soc/codecs/pcm512x.c:34:0: warning: "DIV_ROUND_CLOSEST_ULL" redefined [enabled by default] In file included from include/linux/list.h:8:0, from include/linux/module.h:9, from sound/soc/codecs/pcm512x.c:19: include/linux/kernel.h:110:0: note: this is the location of the previous definition Reported-by: Olof's autobuilder <build(a)lixom.net> Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- sound/soc/codecs/pcm512x.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c index 5a30fdd..e12764d 100644 --- a/sound/soc/codecs/pcm512x.c +++ b/sound/soc/codecs/pcm512x.c @@ -18,6 +18,7 @@ #include <linux/init.h> #include <linux/module.h> #include <linux/clk.h> +#include <linux/kernel.h> #include <linux/pm_runtime.h> #include <linux/regmap.h> #include <linux/regulator/consumer.h> @@ -31,8 +32,6 @@ #define DIV_ROUND_DOWN_ULL(ll, d) \ ({ unsigned long long _tmp = (ll); do_div(_tmp, d); _tmp; }) -#define DIV_ROUND_CLOSEST_ULL(ll, d) \ - ({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; }) #define PCM512x_NUM_SUPPLIES 3 static const char * const pcm512x_supply_names[PCM512x_NUM_SUPPLIES] = { -- 1.9.1

2 1

Re: [alsa-devel] [PATCH 2/2] ASoC: add core audio driver for Broadcom Cygnus SOC.
by Mark Brown 31 Mar '15

31 Mar '15

On Mon, Mar 30, 2015 at 08:16:24PM -0700, Scott Branden wrote: The CC list for this patch is pretty wide - please look at who you're sending this to and try to send to only relevant people (for example I'm not sure the Raspberry Pi people need to review this). People working upstream get a lot of mail so it's helpful to avoid filling their inboxes with random irrelevant stuff. > sound/soc/bcm/Kconfig | 11 + > sound/soc/bcm/Makefile | 5 +- > sound/soc/bcm/cygnus-pcm.c | 918 +++++++++++++++++++++++++ > sound/soc/bcm/cygnus-pcm.h | 45 ++ > sound/soc/bcm/cygnus-ssp.c | 1613 ++++++++++++++++++++++++++++++++++++++++++++ > sound/soc/bcm/cygnus-ssp.h | 84 +++ > 6 files changed, 2675 insertions(+), 1 deletion(-) Send the DMA and DAI drivers as separate patches please, it makes review easier. > +config SND_SOC_CYGNUS > + tristate "SoC platform audio for Broadcom Cygnus chips" > + depends on ARCH_BCM_CYGNUS || COMPILE_TEST > + default ARCH_BCM_CYGNUS Remove the default setting here - we don't do this for other drivers, we shouldn't do it here. > +/* > + * PERIOD_BYTES_MIN is the number of bytes to at which the interrupt will tick. > + * This number should be a multiple of 256 > + */ > +#define PERIOD_BYTES_MIN 0x100 This sounds like it's a setting rather than actually the minimum? > +static const struct snd_pcm_hardware cygnus_pcm_hw = { > + .info = SNDRV_PCM_INFO_MMAP | > + SNDRV_PCM_INFO_MMAP_VALID | > + SNDRV_PCM_INFO_INTERLEAVED, The DMA controller is integrated into the IP? > +static int enable_count; This looks bogus - why is this a global variable not part of the device struct and if it does need to be global why does it need no locking? > + if (aio->portnum == 0) > + *p_rbuf = RINGBUF_REG_PLAYBACK(0); > + else if (aio->portnum == 1) > + *p_rbuf = RINGBUF_REG_PLAYBACK(2); > + else if (aio->portnum == 2) > + *p_rbuf = RINGBUF_REG_PLAYBACK(4); > + else if (aio->portnum == 3) > + *p_rbuf = RINGBUF_REG_PLAYBACK(6); /*SPDIF */ > + else > + status = -EINVAL; This looks like a switch statement, there are many places in the code where you're writing switch statements as chains of ifs. > +static void ringbuf_inc(void __iomem *audio_io, bool is_playback, > + const struct ringbuf_regs *p_rbuf) > +{ > + u32 regval, endval, active_ptr; > + > + if (is_playback) > + active_ptr = p_rbuf->wraddr; > + else > + active_ptr = p_rbuf->rdaddr; > + > + endval = readl(audio_io + p_rbuf->endaddr); > + regval = readl(audio_io + active_ptr); > + regval = regval + p_rbuf->period_bytes; > + if (regval > endval) > + regval -= p_rbuf->buf_size; > + > + writel(regval, audio_io + active_ptr); > +} So it looks like we're getting an interrupt per period and we have to manually advance to the next one? > +static irqreturn_t cygnus_dma_irq(int irq, void *data) > +{ > + u32 r5_status; > + struct cygnus_audio *cygaud; > + > + cygaud = (struct cygnus_audio *)data; If you need to cast away from void something is very wrong. > + /* > + * R5 status bits Description > + * 0 ESR0 (playback FIFO interrupt) > + * 1 ESR1 (playback rbuf interrupt) > + * 2 ESR2 (capture rbuf interrupt) > + * 3 ESR3 (Freemark play. interrupt) > + * 4 ESR4 (Fullmark capt. interrupt) > + */ > + r5_status = readl(cygaud->audio + INTH_R5F_STATUS_OFFSET); > + > + /* If playback interrupt happened */ > + if (ANY_PLAYBACK_IRQ & r5_status) > + handle_playback_irq(cygaud); > + > + /* If capture interrupt happened */ > + if (ANY_CAPTURE_IRQ & r5_status) > + handle_capture_irq(cygaud); > + > + /* > + * clear r5 interrupts after servicing them to avoid overwriting > + * esr_status > + */ > + writel(r5_status, cygaud->audio + INTH_R5F_CLEAR_OFFSET); This feels racy especially given that we seem to need every interrupt delivering. What if another period happens during the servicing? I don't understand what "overwriting esr_status" means here. > + return IRQ_HANDLED; If neither playback nor capture interrupts were flagged we should return IRQ_NONE. > +/* > + * This code is identical to what is done by the framework, when we do not > + * supply a 'copy' function. Having our own copy hook in place allows for > + * us to easily add some diagnotics when needed. > + */ > +int cygnus_pcm_copy(struct snd_pcm_substream *substream, int channel, > + snd_pcm_uframes_t pos, > + void __user *buf, snd_pcm_uframes_t count) This is obviously not suitable for mainline - "let's just cut'n'paste the shared code in case we want to add diagnostics in future" does not scale, you can always add local diagnostics in the core code. > +}; > +/* Blank line between these two please. Missing blanks between bits of code seem to be a common issue in this driver. > +static int audio_ssp_in_enable(struct cygnus_aio_port *aio, bool enable) > +{ > + u32 value; > + > + if (enable) { > + } else { Why not just write two functions? > +static int audio_ssp_source_bitres(struct cygnus_aio_port *aio, unsigned bits) > +{ > + u32 mask = 0x1f; > + u32 value = 0; > + > + if ((bits == 8) || (bits == 16) || (bits == 32)) { > + value = readl(aio->audio + aio->regs.bf_sourcech_cfg); > + value &= ~(mask << BF_SRC_CFGX_BIT_RES); > + > + /* 32 bit mode is coded as 0 */ > + if ((bits == 8) || (bits == 16)) > + value |= (bits << BF_SRC_CFGX_BIT_RES); > + > + writel(value, aio->audio + aio->regs.bf_sourcech_cfg); > + return 0; > + } > + > + pr_err("Bit resolution not supported %d\n", bits); > + return -EINVAL; dev_err() (this applies throughout the driver). It's not clear why this is a function and not just written as a single statement in the one place that it's used (there are multiple calls but they're all together and could just be inlined). > + if (!aio->bitrate) { > + pr_err("%s Use .set_clkdiv() to set bitrate\n", __func__); > + return -EINVAL; > + } This seems bogus - why are we enforcing the use of set_clkdiv()? Can't we figure out something esneible? > + switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) { > + /* Set the SSP up as slave */ > + case SND_SOC_DAIFMT_CBM_CFM: The comments here look odd due to the indentation and really aren't adding much anyway. > + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) { > + case SND_SOC_DAIFMT_RIGHT_J: > + case SND_SOC_DAIFMT_LEFT_J: > + return -EINVAL; These are just eaten by the default case. > + case SND_SOC_DAIFMT_DSP_A: > + case SND_SOC_DAIFMT_DSP_B: > + ssp_newcfg |= BIT(I2S_OUT_CFGX_TDM_MODE); > + > + /* DSP_A = data after FS, DSP_B = data during FS */ > + if (SND_SOC_DAIFMT_DSP_A) > + ssp_newcfg |= BIT(I2S_OUT_CFGX_DATA_ALIGNMENT); That if statement isn't doing what was intended... > + } else { > + > + switch (cmd) { > + case SNDRV_PCM_TRIGGER_START: > + audio_ssp_in_enable(aio, 1); > + break; > + > + case SNDRV_PCM_TRIGGER_STOP: > + audio_ssp_in_enable(aio, 0); > + break; > + } We can just ignore other triggers? It's not clear why this is different to the playback case. > +int cygnus_ssp_get_mode(struct snd_soc_dai *cpu_dai) > +{ > + struct cygnus_aio_port *aio = cygnus_dai_get_portinfo(cpu_dai); > + > + return aio->mode; > +} > +EXPORT_SYMBOL(cygnus_ssp_get_mode); What is this for, it's setting off alarm bells? Note also that ASoC is _GPL() only. > +static const struct snd_kcontrol_new pll_tweak_controls[] = { > + SOC_SINGLE_EXT("PLL Tweak", 0, 0, PLL_NDIV_FRACT_MAX, 0, > + pll_tweak_get, pll_tweak_put), > +}; Whatever this control is doing it should be a separate patch (as I think we discussed in person a ELC?), it's clearly something that's unusual and is likely to block the rest of the code as a result. At a high level this needs at least some documentation. > +int cygnus_ssp_add_pll_tweak_controls(struct snd_soc_pcm_runtime *rtd) > +{ > + struct snd_soc_dai *cpu_dai = rtd->cpu_dai; > + > + return snd_soc_add_dai_controls(cpu_dai, > + pll_tweak_controls, > + ARRAY_SIZE(pll_tweak_controls)); > +} > +EXPORT_SYMBOL(cygnus_ssp_add_pll_tweak_controls); Again, why is this being exported and why is it not _GPL? If the driver is adding controls I'd expect it to just add its controls itself. > +static int cygnus_ssp_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct device_node *child_node; > + struct resource *res = pdev->resource; > + struct cygnus_audio *cygaud; > + int err = -EINVAL; > + int node_count; > + int active_port_count; > + > + if (!of_match_device(cygnus_ssp_of_match, dev)) { > + dev_err(dev, "Failed to find ssp controller\n"); > + return -ENODEV; > + } This error message is misleading - you mean to say that the driver got loaded for a device it doesn't understand. > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + cygaud->audio = devm_ioremap_resource(dev, res); > + if (IS_ERR(cygaud->audio)) { > + dev_err(dev, "audio_io ioremap failed\n"); > + return PTR_ERR(cygaud->audio); devm_ioremap_resource() will complain for you, and in general you should be printing error codes. > + node_count = 0; This doesn't seem to be needed? > + node_count = of_get_child_count(pdev->dev.of_node); > + if ((node_count < 1) || (node_count > CYGNUS_MAX_PORTS)) { > + dev_err(dev, "Incorrct number of child nodes\n"); > + return -EINVAL; Spelling mistake there and it would be helpful to the user to tell them what we parsed.

1 0

Re: [alsa-devel] [pulseaudio-discuss] Can't get Pulseadio to playback stream on Raspbian with HifiBerry DAC+
by Raymond Yau 31 Mar '15

31 Mar '15

2015-3-30 上午12:22 於 "David Martinez" <david(a)sojournmusic.net> 寫道： > > Label says PiFi DAC+. v2.0 > > I'll need to look up how to apply the patch. I'm not familiar with how to do it. This look like driver bug since capabilities should be pvolume instead of volume if your sound card are half duplex Simple mixer control 'PCM',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 215 Front Left: 172 [80%] Front Right: 172 [80%] Simple mixer control 'Playback',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 1 Front Left: 0 [0%] [-6.00dB] Front Right: 0 [0%] [-6.00dB] Simple mixer control 'Playback Boost',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 1 Front Left: 0 [0%] [0.00dB] Front Right: 0 [0%] [0.00dB] > >> >> > >> > I'll check HiFiBerry's site and see if I can get it. >> > >> >> https://www.hifiberry.com/dacplus/ >> >> What is the label on the black DAC chip ? >> >> Aplay/Arecord output >> !!-------------------- >> >> APLAY >> >> **** List of PLAYBACK Hardware Devices **** >> card 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC HiFi pcm512x-hifi-0 [] >> Subdevices: 1/1 >> Subdevice #0: subdevice #0 >> >> ARECORD >> >> **** List of CAPTURE Hardware Devices **** >> >> Seem half duplex >> >>

1 1

[alsa-devel] [RFC v2][PATCH 00/11] digi00x: new driver for Digidesign 002/003 family
by Takashi Sakamoto 31 Mar '15

31 Mar '15

This patchset is revised version of my previous set. [alsa-devel] [RFC][PATCH 00/11] digi00x: new driver for Digidesign 002/003 family http://mailman.alsa-project.org/pipermail/alsa-devel/2015-March/089141.html Improvements from the previous set: * improve double-oh-three (DOT) application * extend hwdep interface for asynchronous messaging * limit sampling rate for PCM substream when clock source is external or any PCM substreams are running * support s16 samples for PCM playback In this time, I test PCM functionality with my test programs. As a result, I can confirm that S/PDIF and ADAT output from my Digi 002 Rack includes expected PCM samples as my programs generates. I think we can judge the implementation of DOT is proper for Digi 002 rack. Currently, several issues remains: * The port for MIDI machine control message is not tested yet, because 002/003 console model are required. * When allocates 2 or more channel numbers for the device, after 15 to 20 seconds from playbacking, any PCM samples causes noisy sound. Then, all of LED on the front panel light. The streaming still continues correctly. * The actual effects of external clock source is not clear. When set the clock source is somewhat external, even if stopping the clock source, the device continues to sound PCM samples against my expectation. * The meaning of asynchronous messages is unknown. This patchset adds a functionality to receive it in userspace. You can test it with updated libhinawa sample script. https://github.com/takaswie/libhinawa Well, I'll stop my work for this driver in this developing period (for Linux 4.0), because this work is not in my original plan. I hope any users test this driver and report the result till Linux 4.2 merge window. If not, this driver will not be merged into upstream, naturally. I prepare for DKMS package to test this patchset. Please use it if needed. https://github.com/takaswie/snd-firewire-improve Takashi Sakamoto (11): ALSA: digi00x: add skeleton for Digi 002/003 device driver ALSA: digi00x: add streaming functionality ALSA: digi00x: add proc node for clock status ALSA: digi00x: add PCM functionality ALSA: digi00x: add MIDI functionality ALSA: digi00x: add hwdep interface ALSA: digi00x: support unknown asynchronous message ALSA: digi00x: support MIDI ports for device control ALSA: firewire-lib: allows to implement external MIDI callback function ALSA: digi00x: improve MIDI capture/playback ALSA: digi00x: apply double-oh-three algorithm to multiplex PCM samples include/uapi/sound/asound.h | 3 +- include/uapi/sound/firewire.h | 8 + sound/firewire/Kconfig | 10 + sound/firewire/Makefile | 1 + sound/firewire/amdtp.c | 30 ++- sound/firewire/amdtp.h | 5 + sound/firewire/digi00x/Makefile | 3 + sound/firewire/digi00x/digi00x-hwdep.c | 200 +++++++++++++++ sound/firewire/digi00x/digi00x-midi.c | 199 +++++++++++++++ sound/firewire/digi00x/digi00x-pcm.c | 344 +++++++++++++++++++++++++ sound/firewire/digi00x/digi00x-proc.c | 86 +++++++ sound/firewire/digi00x/digi00x-protocol.c | 406 ++++++++++++++++++++++++++++++ sound/firewire/digi00x/digi00x-stream.c | 393 +++++++++++++++++++++++++++++ sound/firewire/digi00x/digi00x.c | 179 +++++++++++++ sound/firewire/digi00x/digi00x.h | 167 ++++++++++++ 15 files changed, 2026 insertions(+), 8 deletions(-) create mode 100644 sound/firewire/digi00x/Makefile create mode 100644 sound/firewire/digi00x/digi00x-hwdep.c create mode 100644 sound/firewire/digi00x/digi00x-midi.c create mode 100644 sound/firewire/digi00x/digi00x-pcm.c create mode 100644 sound/firewire/digi00x/digi00x-proc.c create mode 100644 sound/firewire/digi00x/digi00x-protocol.c create mode 100644 sound/firewire/digi00x/digi00x-stream.c create mode 100644 sound/firewire/digi00x/digi00x.c create mode 100644 sound/firewire/digi00x/digi00x.h -- 2.1.0

2 14

Re: [alsa-devel] [PATCH 00/25] treewide: Use bool function return values of true/false not 1/0
by Joe Perches 31 Mar '15

31 Mar '15

On Mon, 2015-03-30 at 17:07 -0700, Casey Schaufler wrote: > On 3/30/2015 4:45 PM, Joe Perches wrote: > > Joe Perches (25): > > arm: Use bool function return values of true/false not 1/0 [etc...] > Why, and why these in particular? bool functions are probably better returning bool values instead of 1 and 0. Especially when the functions intermix returning returning 1/0 and true/false. (there are only a couple of those though) These are all the remaining instances in the kernel tree.

1 0

Re: [alsa-devel] Realtek ALC662 issues - Intel DG41CN
by Raymond Yau 31 Mar '15

31 Mar '15

> > > Well, I was just trying different modes. The last one was ASUS-MODE1. Before this I tried the "laptop" mode and the "generic" one, both of which did not work. > > What do you suggest? You don't need any model since the pin defaults of your Intel DG41CN are correct unless you want to use CD audio in connector !!Sysfs Files !!----------- /sys/class/sound/hwC0D0/init_pin_configs: 0x14 0x01014010 0x15 0x411111f0 0x16 0x411111f0 0x18 0x01a19840 0x19 0x02a19c50 0x1a 0x0181304f 0x1b 0x02214c20 0x1c 0x593301f0 0x1d 0x4004c601 0x1e 0x01441130 Node 0x1c [Pin Complex] wcaps 0x400001: Stereo Pincap 0x00000020: IN Pin Default 0x593301f0: [N/A] CD at Int ATAPI Conn = ATAPI, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN http://www.intel.com/support/motherboards/desktop/dg41cn/sb/CS-031343.htm You should check the front audio panel of your computer chassis if jack state of headphone is alway plugged http://www.intel.com/support/motherboards/desktop/sb/cs-015851.htm http://fedoraproject.org/wiki/How_to_debug_PulseAudio_problems You have to provide pulseaudio verbose log Default setting support multi channels but NO headphone playback volume control http://www.intel.com/support/motherboards/desktop/sb/CS-034198.htm You can disable multi channels by using early patching and hint multi_io=0 to get back the headphone playback volume control - multi_io (bool): try probing multi-I/O config (e.g. shared line-in/surround, mic/clfe jacks) https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/Documenta… >> >> > I have recently installed Fedora 21 Mate on my desktop which runs on >> Intel DG41CN motherboard with Realtek ALC662 Audio. Prior to this I >> was running Linux Mint. It was working all fine then, I may have fixed >> it when I had installed Mint two years ago but I do not remember what >> was done then. I also run Windows 7 on the same machine and there is >> no problem with the audio. >> >> > So the problem I have is that there is no sound from my speakers. A >> few times, there is a little "choppy" sound but thats it. When I put >> the headphones on, the sound is there. >> >> > I must also mention that I also installed Ubuntu Mate on it and faced >> the same problem. >> >> > I have run the Alsa diagnostic tool and the output is uploaded here: >> http://www.alsa-project.org/db/?f=1f6dd98e26f68e890258fa2fe5eb08ee343c5c13 >> >> >I will really appreciate any help. I am stuck bad here.. >> >> Any reason to use asus-mode1 ? >> >> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/p… >> >> Seem asus-mode1 is a broken pin fixup since node 0x21 is not any pin complex >> >> Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono >> >> + [ALC662_FIXUP_ASUS_MODE1] = { >> + .type = ALC_FIXUP_PINS, >> + .v.pins = (const struct alc_pincfg[]) { >> + { 0x14, 0x99130110 }, /* speaker */ >> + { 0x18, 0x01a19c20 }, /* mic */ >> + { 0x19, 0x99a3092f }, /* int-mic */ >> + { 0x21, 0x0121401f }, /* HP out */ >> + { } >> + }, >> + .chained = true, >> + .chain_id = ALC662_FIXUP_SKU_IGNORE >> + }, >> >> Line out is muted when headphone jack is plugged >> >> control.30 { >> iface CARD >> name 'Front Headphone Jack' >> value true >> comment { >> access read >> type BOOLEAN >> count 1 >> } >> } >> >> Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out >> Control: name="Speaker Playback Switch", index=0, device=0 >> ControlAmp: chs=3, dir=Out, idx=0, ofs=0 >> Control: name="Speaker Phantom Jack", index=0, device=0 >> Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 >> Amp-Out vals: [0x80 0x80] >> Pincap 0x0001003c: IN OUT HP EAPD Detect >> EAPD 0x2: EAPD >> Pin Default 0x01014010: [Jack] Line Out at Ext Rear >> Conn = 1/8, Color = Green >> DefAssociation = 0x1, Sequence = 0x0 >> Pin-ctls: 0x00: >> Unsolicited: tag=00, enabled=0 >> Connection: 1 >> 0x0c > >

1 0

Re: [alsa-devel] Realtek ALC662 issues - Intel DG41CN
by Raymond Yau 30 Mar '15

30 Mar '15

> I have recently installed Fedora 21 Mate on my desktop which runs on Intel DG41CN motherboard with Realtek ALC662 Audio. Prior to this I was running Linux Mint. It was working all fine then, I may have fixed it when I had installed Mint two years ago but I do not remember what was done then. I also run Windows 7 on the same machine and there is no problem with the audio. > So the problem I have is that there is no sound from my speakers. A few times, there is a little "choppy" sound but thats it. When I put the headphones on, the sound is there. > I must also mention that I also installed Ubuntu Mate on it and faced the same problem. > I have run the Alsa diagnostic tool and the output is uploaded here: http://www.alsa-project.org/db/?f=1f6dd98e26f68e890258fa2fe5eb08ee343c5c13 >I will really appreciate any help. I am stuck bad here.. Any reason to use asus-mode1 ? https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/p… Seem asus-mode1 is a broken pin fixup since node 0x21 is not any pin complex Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono + [ALC662_FIXUP_ASUS_MODE1] = { + .type = ALC_FIXUP_PINS, + .v.pins = (const struct alc_pincfg[]) { + { 0x14, 0x99130110 }, /* speaker */ + { 0x18, 0x01a19c20 }, /* mic */ + { 0x19, 0x99a3092f }, /* int-mic */ + { 0x21, 0x0121401f }, /* HP out */ + { } + }, + .chained = true, + .chain_id = ALC662_FIXUP_SKU_IGNORE + }, Line out is muted when headphone jack is plugged control.30 { iface CARD name 'Front Headphone Jack' value true comment { access read type BOOLEAN count 1 } } Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Phantom Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0001003c: IN OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x01014010: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Connection: 1 0x0c

1 0