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

[alsa-devel] [RFC] [PATCH 1/3] ASoC: Add support for Conexant CX20442-11 voice modem codec
by Janusz Krzysztofik 28 Jul '09

28 Jul '09

This patch adds support for Conexant CX20442-11 voice modem codec, suitable for use by the ASoC board driver for Amstrad E3 (Delta) videophone. Related sound card driver will follow. Created and tested against linux-2.6.31-rc3. Applies and works with linux-omap-2.6 commit 7c5cb7862d32cb344be7831d466535d5255e35ac as well. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- This codec is an optional part of the Conexant SmartV three chip modem design. As such, documentation for its proprietary digital audio interface is not available. However, on Amstrad Delta board, thanks to Mark Underwood who created an initial, omap-alsa based sound driver a few years ago[1], the codec has been discovered to be accessible not only from the modem side, but also over the OMAP McBSP based CPU DAI. Thus, the driver can be used by any sound card that can access the codec DAI directly. The DAI configuration parameters (sample rate and format, number of channels) has been selected out empirically for best user experience. The codec analogue interface consists of two pairs of analogue I/O pins: speakerphone interface or telephone handset/headset interface. Furthermore, it seams to provide two operation modes for speakerphone I/O: standard and advanced, with automatic gain control and echo cancelation. Even if the codec control interface is unknown and not available, all those interfaces and modes can be selected over the modem chip using V.253 commands. The driver is able to issue necessary commands over a suitable hw_write function if provided by a sound card driver. Otherwise, the codec can be controlled over the modem from userspace while inactive. Even if nothig is known about the codec internal power management capabilities, DAPM widgets has been used to model the codec audio map. Automatically performed powering up/down of those virtual widgets results in corresponding V.253 commands being issued. Some driver features/oddities may be board specific, but I have no way to verify that with any board other than Amstrad Delta. [1] http://www.earth.li/pipermail/e3-hacking/2006-April/000481.html --- linux-2.6.31-rc1/sound/soc/codecs/Kconfig.orig 2009-07-04 16:40:00.000000000 +0200 +++ linux-2.6.31-rc1/sound/soc/codecs/Kconfig 2009-07-22 01:01:08.000000000 +0200 @@ -17,6 +17,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_AK4104 if SPI_MASTER select SND_SOC_AK4535 if I2C select SND_SOC_CS4270 if I2C + select SND_SOC_CX20442 select SND_SOC_PCM3008 select SND_SOC_SPDIF select SND_SOC_SSM2602 if I2C @@ -86,6 +87,9 @@ config SND_SOC_CS4270_VD33_ERRATA bool depends on SND_SOC_CS4270 +config SND_SOC_CX20442 + tristate + config SND_SOC_L3 tristate --- linux-2.6.31-rc1/sound/soc/codecs/Makefile.orig 2009-07-04 16:40:00.000000000 +0200 +++ linux-2.6.31-rc1/sound/soc/codecs/Makefile 2009-07-22 01:01:08.000000000 +0200 @@ -4,6 +4,7 @@ snd-soc-ad73311-objs := ad73311.o snd-soc-ak4104-objs := ak4104.o snd-soc-ak4535-objs := ak4535.o snd-soc-cs4270-objs := cs4270.o +snd-soc-cx20442-objs := cx20442.o snd-soc-l3-objs := l3.o snd-soc-pcm3008-objs := pcm3008.o snd-soc-spdif-objs := spdif_transciever.o @@ -41,6 +42,7 @@ obj-$(CONFIG_SND_SOC_AD73311) += snd-soc obj-$(CONFIG_SND_SOC_AK4104) += snd-soc-ak4104.o obj-$(CONFIG_SND_SOC_AK4535) += snd-soc-ak4535.o obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o +obj-$(CONFIG_SND_SOC_CX20442) += snd-soc-cx20442.o obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o obj-$(CONFIG_SND_SOC_PCM3008) += snd-soc-pcm3008.o obj-$(CONFIG_SND_SOC_SPDIF) += snd-soc-spdif.o --- /dev/null 2009-06-24 10:33:03.437003511 +0200 +++ linux-2.6.31-rc1/sound/soc/codecs/cx20442.h 2009-07-22 01:01:08.000000000 +0200 @@ -0,0 +1,19 @@ +/* + * cx20442.h -- audio driver for CX20442 + * + * Copyright 2009 Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ + +#ifndef _CX20442_CODEC_H +#define _CX20442_CODEC_H + +extern struct snd_soc_dai cx20442_dai; +extern struct snd_soc_codec_device cx20442_codec_dev; + +#endif --- /dev/null 2009-06-24 10:33:03.437003511 +0200 +++ linux-2.6.31-rc1/sound/soc/codecs/cx20442.c 2009-07-22 01:01:08.000000000 +0200 @@ -0,0 +1,395 @@ +/* + * cx20442.c -- CX20442 ALSA Soc Audio driver + * + * Copyright 2009 Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> + * + * Initially based on sound/soc/codecs/wm8400.c + * Copyright 2008, 2009 Wolfson Microelectronics PLC. + * Author: Mark Brown <broonie(a)opensource.wolfsonmicro.com> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include <sound/core.h> +#include <sound/initval.h> +#include <sound/soc-dapm.h> + +#include "cx20442.h" + + +struct cx20442_priv { + struct snd_soc_codec codec; + u8 reg_cache[1]; +}; + +#define CX20442_PM 0x0 + +#define CX20442_TELIN 0 +#define CX20442_TELOUT 1 +#define CX20442_MIC 2 +#define CX20442_SPKOUT 3 +#define CX20442_AGC 4 + +static const struct snd_soc_dapm_widget cx20442_dapm_widgets[] = { + SND_SOC_DAPM_OUTPUT("TELOUT"), + SND_SOC_DAPM_OUTPUT("SPKOUT"), + SND_SOC_DAPM_OUTPUT("AGCOUT"), + + SND_SOC_DAPM_MIXER("SPKOUT Mixer", SND_SOC_NOPM, 0, 0, NULL, 0), + + SND_SOC_DAPM_PGA("TELOUT Amp", CX20442_PM, CX20442_TELOUT, 0, NULL, 0), + SND_SOC_DAPM_PGA("SPKOUT Amp", CX20442_PM, CX20442_SPKOUT, 0, NULL, 0), + SND_SOC_DAPM_PGA("SPKOUT AGC", CX20442_PM, CX20442_AGC, 0, NULL, 0), + + SND_SOC_DAPM_DAC("DAC", "Playback", SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_ADC("ADC", "Capture", SND_SOC_NOPM, 0, 0), + + SND_SOC_DAPM_MIXER("Input Mixer", SND_SOC_NOPM, 0, 0, NULL, 0), + + SND_SOC_DAPM_MICBIAS("TELIN Bias", CX20442_PM, CX20442_TELIN, 0), + SND_SOC_DAPM_MICBIAS("MIC Bias", CX20442_PM, CX20442_MIC, 0), + + SND_SOC_DAPM_PGA("MIC AGC", CX20442_PM, CX20442_AGC, 0, NULL, 0), + + SND_SOC_DAPM_INPUT("TELIN"), + SND_SOC_DAPM_INPUT("MIC"), + SND_SOC_DAPM_INPUT("AGCIN"), +}; + +static const struct snd_soc_dapm_route cx20442_audio_map[] = { + {"TELOUT", NULL, "TELOUT Amp"}, + + {"SPKOUT", NULL, "SPKOUT Mixer"}, + {"SPKOUT Mixer", NULL, "SPKOUT Amp"}, + + {"TELOUT Amp", NULL, "DAC"}, + {"SPKOUT Amp", NULL, "DAC"}, + + {"SPKOUT Mixer", NULL, "SPKOUT AGC"}, + {"SPKOUT AGC", NULL, "AGCIN"}, + + {"AGCOUT", NULL, "MIC AGC"}, + {"MIC AGC", NULL, "MIC"}, + + {"MIC Bias", NULL, "MIC"}, + {"Input Mixer", NULL, "MIC Bias"}, + + {"TELIN Bias", NULL, "TELIN"}, + {"Input Mixer", NULL, "TELIN Bias"}, + + {"ADC", NULL, "Input Mixer"}, +}; + +static int cx20442_add_widgets(struct snd_soc_codec *codec) +{ + snd_soc_dapm_new_controls(codec, cx20442_dapm_widgets, + ARRAY_SIZE(cx20442_dapm_widgets)); + + snd_soc_dapm_add_routes(codec, cx20442_audio_map, + ARRAY_SIZE(cx20442_audio_map)); + + snd_soc_dapm_new_widgets(codec); + return 0; +} + +static unsigned int cx20442_read_reg_cache(struct snd_soc_codec *codec, + unsigned int reg) +{ + u8 *reg_cache = codec->reg_cache; + + if (reg >= codec->reg_cache_size) + return -EINVAL; + + return reg_cache[reg]; +} + +enum v253_vls { + V253_VLS_NONE = 0, + V253_VLS_T, + V253_VLS_L, + V253_VLS_LT, + V253_VLS_S, + V253_VLS_ST, + V253_VLS_M, + V253_VLS_MST, + V253_VLS_S1, + V253_VLS_S1T, + V253_VLS_MS1T, + V253_VLS_M1, + V253_VLS_M1ST, + V253_VLS_M1S1T, + V253_VLS_H, + V253_VLS_HT, + V253_VLS_MS, + V253_VLS_MS1, + V253_VLS_M1S, + V253_VLS_M1S1, + V253_VLS_TEST, +}; + +static int cx20442_pm_to_v253_vls(u8 value) +{ + switch(value & ~(1 << CX20442_AGC)) { + case 0: + return V253_VLS_T; + case (1 << CX20442_SPKOUT): + return V253_VLS_S1; + case (1 << CX20442_MIC): + return V253_VLS_M1; + case (1 << CX20442_SPKOUT) | (1 << CX20442_MIC): + return V253_VLS_M1S1; + case (1 << CX20442_TELOUT): + case (1 << CX20442_TELIN): + case (1 << CX20442_TELOUT) | (1 << CX20442_TELIN): + return V253_VLS_L; + case (1 << CX20442_TELOUT) | (1 << CX20442_MIC): + return V253_VLS_NONE; + } + return -EINVAL; +} +static int cx20442_pm_to_v253_vsp(u8 value) +{ + switch(value & ~(1 << CX20442_AGC)) { + case (1 << CX20442_SPKOUT): + case (1 << CX20442_MIC): + case (1 << CX20442_SPKOUT) | (1 << CX20442_MIC): + return (bool)(value & (1 << CX20442_AGC)); + } + return (value & (1 << CX20442_AGC)) ? -EINVAL : 0; +} + +static int cx20442_write(struct snd_soc_codec *codec, unsigned int reg, + unsigned int value) +{ + u8 *reg_cache = codec->reg_cache; + int vls, vsp, old, len; + char buf[18]; + + if (reg >= codec->reg_cache_size) + return -EINVAL; + + if (!codec->hw_write || !codec->control_data) + return -EIO; + + old = reg_cache[reg]; + reg_cache[reg] = value; + + vls = cx20442_pm_to_v253_vls(value); + if (vls < 0) + return vls; + + vsp = cx20442_pm_to_v253_vsp(value); + if (vsp < 0 ) + return vsp; + + if ((vls == V253_VLS_T) || + (vls == cx20442_pm_to_v253_vls(old))) { + if (vsp == cx20442_pm_to_v253_vsp(old)) + return 0; + len = snprintf(buf, ARRAY_SIZE(buf), "at+vsp=%d\r", vsp); + } else if (vsp == cx20442_pm_to_v253_vsp(old)) + len = snprintf(buf, ARRAY_SIZE(buf), "at+vls=%d\r", vls); + else + len = snprintf(buf, ARRAY_SIZE(buf), + "at+vls=%d;+vsp=%d\r", vls, vsp); + + if (unlikely(len > (ARRAY_SIZE(buf) - 1))) + return -ENOMEM; + + if (codec->hw_write(codec->control_data, buf, len) != len) + return -EIO; + + return 0; +} + +struct snd_soc_dai cx20442_dai = { + .name = "CX20442", + .playback = { + .stream_name = "Playback", + .channels_min = 1, + .channels_max = 1, + .rates = SNDRV_PCM_RATE_8000, + .formats = SNDRV_PCM_FMTBIT_S16_LE, + }, + .capture = { + .stream_name = "Capture", + .channels_min = 1, + .channels_max = 1, + .rates = SNDRV_PCM_RATE_8000, + .formats = SNDRV_PCM_FMTBIT_S16_LE, + }, +}; +EXPORT_SYMBOL_GPL(cx20442_dai); + +static struct snd_soc_codec *cx20442_codec; + +static int cx20442_codec_probe(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec; + int ret; + + if(!cx20442_codec) { + dev_err(&pdev->dev, "cx20442 not yet discovered\n"); + return -ENODEV; + } + codec = cx20442_codec; + + socdev->card->codec = codec; + + /* register pcms */ + ret = snd_soc_new_pcms(socdev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1); + if (ret < 0) { + dev_err(&pdev->dev, "failed to create pcms\n"); + goto pcm_err; + } + + cx20442_add_widgets(codec); + + ret = snd_soc_init_card(socdev); + if (ret < 0) { + dev_err(&pdev->dev, "failed to register card\n"); + goto card_err; + } + + return ret; + +card_err: + snd_soc_free_pcms(socdev); + snd_soc_dapm_free(socdev); +pcm_err: + return ret; +} + +/* power down chip */ +static int cx20442_codec_remove(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + + snd_soc_free_pcms(socdev); + snd_soc_dapm_free(socdev); + + return 0; +} + +struct snd_soc_codec_device cx20442_codec_dev = { + .probe = cx20442_codec_probe, + .remove = cx20442_codec_remove, +}; +EXPORT_SYMBOL_GPL(cx20442_codec_dev); + +static int cx20442_register(struct cx20442_priv *cx20442) +{ + struct snd_soc_codec *codec = &cx20442->codec; + int ret; + + mutex_init(&codec->mutex); + INIT_LIST_HEAD(&codec->dapm_widgets); + INIT_LIST_HEAD(&codec->dapm_paths); + + codec->name = "CX20442"; + codec->owner = THIS_MODULE; + codec->private_data = cx20442; + + codec->dai = &cx20442_dai; + codec->num_dai = 1; + + codec->reg_cache = &cx20442->reg_cache; + codec->reg_cache_size = ARRAY_SIZE(cx20442->reg_cache); + codec->read = cx20442_read_reg_cache; + codec->write = cx20442_write; + + codec->bias_level = SND_SOC_BIAS_OFF; + + cx20442_dai.dev = codec->dev; + + cx20442_codec = codec; + + ret = snd_soc_register_codec(codec); + if (ret != 0) { + //dev_err(&dev->dev, "Failed to register codec: %d\n", ret); + goto err; + } + + ret = snd_soc_register_dai(&cx20442_dai); + if (ret != 0) { + //dev_err(&dev->dev, "Failed to register DAI: %d\n", ret); + goto err_codec; + } + + return 0; + +err_codec: + snd_soc_unregister_codec(codec); +err: + cx20442_codec = NULL; + kfree(cx20442); + return ret; +} + +static void cx20442_unregister(struct cx20442_priv *cx20442) +{ + snd_soc_unregister_dai(&cx20442_dai); + snd_soc_unregister_codec(&cx20442->codec); + + cx20442_codec = NULL; + kfree(cx20442); +} + +static int cx20442_platform_probe(struct platform_device *pdev) +{ + struct cx20442_priv *cx20442; + struct snd_soc_codec *codec; + + cx20442 = kzalloc(sizeof(struct cx20442_priv), GFP_KERNEL); + if (cx20442 == NULL) + return -ENOMEM; + + codec = &cx20442->codec; + + codec->control_data = NULL; + codec->hw_write = NULL; + codec->pop_time = 0; + + codec->dev = &pdev->dev; + platform_set_drvdata(pdev, cx20442); + + return cx20442_register(cx20442); +} + +static int __exit cx20442_platform_remove(struct platform_device *pdev) +{ + struct cx20442_priv *cx20442 = platform_get_drvdata(pdev); + + cx20442_unregister(cx20442); + return 0; +} + +static struct platform_driver cx20442_platform_driver = { + .driver = { + .name = "cx20442", + .owner = THIS_MODULE, + }, + .probe = cx20442_platform_probe, + .remove = __exit_p(cx20442_platform_remove), +}; + +static int __init cx20442_init(void) +{ + return platform_driver_register(&cx20442_platform_driver); +} +module_init(cx20442_init); + +static void __exit cx20442_exit(void) +{ + platform_driver_unregister(&cx20442_platform_driver); +} +module_exit(cx20442_exit); + +MODULE_DESCRIPTION("ASoC CX20442-11 voice modem codec driver"); +MODULE_AUTHOR("Janusz Krzysztofik"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:cx20442-codec");

2 8

[alsa-devel] Using Alsa for AD1981b on 9263
by Shilpa Kedar Walvekar 28 Jul '09

28 Jul '09

Hi, I am using AT91SAM9263 evaluation kit with AD1981b codec. I want to use alsa to play and record audio on this kit. I tried to install the alsa library, alsa-oss, alsa-util. Alsa driver was part of kernel (2.6.27). I did, ./configure && make && make install for library, oss and util. Now when I try to do aplay -l following happens: aplay: device_list:223: no soundcards found... Don't know what is happening. Am I missing any step? What else should be done? Please help me asap. Regards, --Shilpa.

2 1

Re: [alsa-devel] get two mono channel from stereo line
by Clemens Ladisch 28 Jul '09

28 Jul '09

arif setiawan wrote: > It worked now. thank you. Apparently we changed something in your > plugin sample. Sorry, that was my error; I wrote a wrong number for the right dshare plugin. > The ipc_key for dshare in both left and right is supposed to be same > right?, also for dsnoop. Yes; the two processes that are to share the device use this to communicate with each other. Best regards, Clemens

1 0

Re: [alsa-devel] HDA Intel IDT 92HD71B7X - HP Pavilion DV7-1299EF - Subwoofer not Working
by Wael Nasreddine (a.k.a eMxyzptlk) 27 Jul '09

27 Jul '09

I still got no solution for this problem, guys please HELP!! I removed completely Windows, and I can't even enjoy music nor a movie!! On Thu, Jun 11, 2009 at 8:31 PM, Wael Nasreddine (a.k.a eMxyzptlk) < mla(a)nasreddine.com> wrote: > Yes it does mute the speakers once I plug in headphones.. > > > On Thu, Jun 11, 2009 at 8:12 PM, Gustavo Vieira <gustavo(a)sagui.org> wrote: > >> Em Dom, 2009-06-07 às 16:57 +0200, Wael Nasreddine (a.k.a eMxyzptlk) >> escreveu: >> > Last night I bought myself a new laptop, the HP Pavilion DV7-1299EF. >> > >> >> Sorry for hijacking your thread, but does this laptop mute the speaker >> if you plug in the headphones? >> >> I'm experiencing problems with jack sensing in a Pavilion DV4 with the >> same codec and what to know if this problem is general to the codec or >> specific to my model. >> >> Abraços, >> Gustavo >> >> >> > > > -- > Wael Nasreddine > > Blog : http://wael.nasreddine.com > E-mail : wael.nasreddine(a)gmail.com > gTalk : wael.nasreddine(a)gmail.com > Tel : +33.6.32.94.70.13 > Skype : eMxyzptlk > Twitter : @eMxyzptlk > > Sabayon Linux Chief Development Officer - http://www.sabayonlinux.org > > PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2 > > .: An infinite number of monkeys typing into GNU emacs, > would never make a good program. (L. Torvalds 1995) :. > > -- Wael Nasreddine Blog : http://wael.nasreddine.com E-mail : wael.nasreddine(a)gmail.com gTalk : wael.nasreddine(a)gmail.com Tel : +33.6.32.94.70.13 Skype : eMxyzptlk Twitter : @eMxyzptlk Sabayon Linux Chief Development Officer - http://www.sabayonlinux.org PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2 .: An infinite number of monkeys typing into GNU emacs, would never make a good program. (L. Torvalds 1995) :.

2 1

[alsa-devel] my driver can't reproduce continuously
by Kuninori Morimoto 27 Jul '09

27 Jul '09

Hi Now I'm creating sound driver. But can't reproduce continuously. So, I would like to ask. I use module of SH to play sound. Player is aplay, sound data is wav file. Q1) When I play sound, aplay said underrun!!! (at least 0.000 ms long) underrun!!! (at least 0.000 ms long) underrun!!! (at least 0.000 ms long) underrun!!! (at least 0.000 ms long) I checked source of aplay, but can not understand about snd_pcm_status_get_state. why snd_pcm_status_get_state return SND_PCM_STATE_XRUN ? What should my driver do (or where should I check) ? Q2) The reason that it can not reproduce continuously seems soc-core.c :: soc_pcm_trigger timing. Call timing of soc_pcm_trigger is slow. What should my driver do to make call timing more fast ? Best regards -- Kuninori Morimoto

3 11

[alsa-devel] get two mono channel from stereo line
by arif setiawan 27 Jul '09

27 Jul '09

Thank you. It works as we expected, however we found that we can't run two lines (left-capture - left-playback) and (right-capture - right-playback) simulatenously. The error message is : ALSA lib pcm_dshare.c:706:(snd_pcm_dshare_open) unable to open slave cannot open output audio device right: Device or resource busy Is there any workaround for this?

1 0

Re: [alsa-devel] Getting around initial sample loss with intel HDMI
by Takashi Iwai 27 Jul '09

27 Jul '09

At Sun, 26 Jul 2009 23:21:50 -0700, Shane W wrote: > > On Mon, Jul 27, 2009 at 08:07:40AM +0200, Takashi Iwai wrote: > > At Sun, 26 Jul 2009 10:32:10 -0700, > > Shane W wrote: > > > I did some digging in the drivers to try and find the > > > source of this problem. Note that I am really not familiar > > > with this stuff. It appears to be here: > > > hda_codec.c > > > void snd_hda_codec_setup_stream(...) > > > ... > > > snd_hda_codec_write(codec, nid, 0, > > > AC_VERB_SET_CHANNEL_STREAMID, > > > > > > Introducing a delay after this point fixes the issue but > > > it's around a full second so that's obviously not a > > > solution. Could we not cache the current format and only do > > > this when the format changes rather than on every device > > > open? > > > > The format itself is kept. But the stream tag and channel assignment > > are assigned dynamically at each open. Thus, this call has to be > > reset at each open, at least. > > > > > For testing, I tried doing this though and disabling > > > the set_streamid, 0 call in snd_codec_cleanup() but it > > > still missed those first samples. Is there somewhere else I > > > need to be looking? > > > > Does it happen without dmix, too? > > Yeah, with and without dmix it still misses the first bit. OK. I just thought of a possibility of dmix bug. Good to know that it's not :) > The only way it doesn't is if I have another program open > the device and sleep, then have the samples play. Actually, > an open isn't sufficient, it has to go and set the playback > parameters as well. It's logical since the stream and format ids are assigned dynamically first after the stream is set up. One another problem is that we currently call azx_stream_reset() in each prepare callback in hda_intel.c. This was newly added because keeping the format id without resetting caused some other serious errors. Maybe this can be optimized for specific hardwares, e.g. skipping the unneeded reset for HDMI/SPDIF. Takashi

1 0

Re: [alsa-devel] Getting around initial sample loss with intel HDMI
by Takashi Iwai 27 Jul '09

27 Jul '09

At Sun, 26 Jul 2009 10:32:10 -0700, Shane W wrote: > > On Sun, Jul 26, 2009 at 10:52:01AM +0200, Takashi Iwai wrote: > > > It's a known issue that Intel HDMI audio loses the first > > > half second or so of audio when opening the device. Using > > > the dmix interface, I've been able to get around that by > > > writing a quick app to hold the device open so the HDMI > > > stays live. However, with the recent asound.conf posted > > > here which uses the route plugin to fix the multichannel > > > order, I can't do that as dmix isn't in the picture. I'd > > > rather not use dmix anyway since it can bugger with the > > > sample rate so I am wondering if there's another way to get > > > around this. > > > > It's possible to combine with dmix. > > You set up dmix with 8 channels, put route plugin over it. > > This has a few problems. > > It doesn't seem to handle varying sample rates. IE if I > play a 96khz stream at 6 channels, sound is terrible. This is rather a problem of Nvidia HDMI codec driver... > Also, > streaming DTS or AC3 no longer works since the streams are > being upmixed to 6ch. This has to be sent anyway exclusively without dmix, so you'll need another PCM definition. > I did some digging in the drivers to try and find the > source of this problem. Note that I am really not familiar > with this stuff. It appears to be here: > hda_codec.c > void snd_hda_codec_setup_stream(...) > ... > snd_hda_codec_write(codec, nid, 0, > AC_VERB_SET_CHANNEL_STREAMID, > > Introducing a delay after this point fixes the issue but > it's around a full second so that's obviously not a > solution. Could we not cache the current format and only do > this when the format changes rather than on every device > open? The format itself is kept. But the stream tag and channel assignment are assigned dynamically at each open. Thus, this call has to be reset at each open, at least. > For testing, I tried doing this though and disabling > the set_streamid, 0 call in snd_codec_cleanup() but it > still missed those first samples. Is there somewhere else I > need to be looking? Does it happen without dmix, too? The reset part can be a bit more optimized. But, this is really a sensitive part, which can easily break the I/O status without knowing... Takashi

1 0

Re: [alsa-devel] Getting around initial sample loss with intel HDMI
by Takashi Iwai 26 Jul '09

26 Jul '09

At Sat, 25 Jul 2009 13:35:18 -0700, Shane W wrote: > > Hi, > > It's a known issue that Intel HDMI audio loses the first > half second or so of audio when opening the device. Using > the dmix interface, I've been able to get around that by > writing a quick app to hold the device open so the HDMI > stays live. However, with the recent asound.conf posted > here which uses the route plugin to fix the multichannel > order, I can't do that as dmix isn't in the picture. I'd > rather not use dmix anyway since it can bugger with the > sample rate so I am wondering if there's another way to get > around this. It's possible to combine with dmix. You set up dmix with 8 channels, put route plugin over it. Takashi

1 0

[alsa-devel] [snd_via82xx] EAGAIN on snd_pcm_prepare after EPIPE on mmap_commit
by rom1dep 25 Jul '09

25 Jul '09

Hello ! I am encountering some issues with pulseaudio : after some time and for no evident reason PA stops routing the sound. That's what I get with $pulseaudio -vvv : http://pastebin.mandriva.com/13648 (got from a 2.6.29.6_mdv kernel) running $pacmd list-sinks when stuck gives : http://pastebin.mandriva.com/13649 Our pulseaudio integrator Colin Guthrie concluded : "OK, so what is happening is that some alsa level problem is occurring (due to mmap). Pulse tries to recover from this but cannot. The alsa sink (and the whole card) is subsequently unloaded due to this fatal error." And now.. a quick paste from irc : "[00:44:20] <coling> Jul 22 14:04:29 <mezcalero> coling: driver issue i am pretty sure [00:44:20] <coling> Jul 22 14:04:33 <mezcalero> i saw that before once [00:44:20] <coling> Jul 22 14:04:55 <mezcalero> coling: i.e. EAGAIN on snd_pcm_prepare after EPIPE on mmap_commit [00:44:23] <coling> Jul 22 14:05:08 <mezcalero> coling: needs to be brought to attention of alsa folks i guess [00:44:30] <coling> That's what I was told." I'm now on 2.6.30 and I can reproduce that bug, then I'm bringing that to you ! :) Thanks !

3 4