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

[alsa-devel] Error patching file pcm_native.c
by Delusion's Master 20 Nov '24

20 Nov '24

Hi, first of all I apologize in case you receive multiple copies of this message, but I forgot to specify a subject in the original mail. I have a problem compiling the latest alsa driver snapshots. Specifically, it's a problem when patching pcm_native.c: [..] copying file alsa-kernel/core/info.c patching file info.c copying file alsa-kernel/core/pcm.c patching file pcm.c Hunk #3 succeeded at 739 (offset 2 lines). Hunk #5 succeeded at 954 (offset 2 lines). Hunk #7 succeeded at 1045 (offset 2 lines). copying file alsa-kernel/core/pcm_native.c patching file pcm_native.c Hunk #4 succeeded at 1544 (offset -25 lines). Hunk #5 succeeded at 2827 (offset 12 lines). Hunk #6 succeeded at 2878 (offset 10 lines). Hunk #7 FAILED at 2906. Hunk #8 FAILED at 2922. Hunk #9 succeeded at 2915 (offset -23 lines). Hunk #10 succeeded at 3036 (offset 10 lines). Hunk #11 succeeded at 3027 (offset -23 lines). Hunk #12 succeeded at 3074 (offset 10 lines). Hunk #13 succeeded at 3098 (offset -23 lines). Hunk #14 succeeded at 3143 (offset 10 lines). Hunk #15 succeeded at 3124 (offset -23 lines). Hunk #16 succeeded at 3214 (offset 10 lines). Hunk #17 succeeded at 3208 (offset -23 lines). Hunk #18 succeeded at 3271 (offset 10 lines). Hunk #19 succeeded at 3304 (offset -23 lines). Hunk #20 succeeded at 3386 (offset 10 lines). Hunk #21 succeeded at 3411 (offset -23 lines). Hunk #22 succeeded at 3456 (offset 10 lines). Hunk #23 succeeded at 3450 (offset -23 lines). Hunk #24 succeeded at 3525 (offset 10 lines). Hunk #25 succeeded at 3644 (offset -23 lines). 2 out of 25 hunks FAILED -- saving rejects to file pcm_native.c.rej make[2]: *** [pcm_native.c] Error 1 It's some days I get this, but I waited to report this since I thought it could be a temporary problem. My OS is Fedora 11 x86_64. Previous snapshots didn't give me this problem, but I can't say which one broke the compilation, since I usually try updated snapshots only at kernel updates. I searched for this error and the only relevant report I could find is this one: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-April/016420.html a report from last April. What could the problem be? Thanks _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

3 10

[alsa-devel] hda-intel missing mixer channels
by Orm Finnendahl 26 Aug '13

26 Aug '13

Hi, I sent this to alsa-user a week ago but didn't get any reply. Does anybody know, what is responsible for the missing faders? Did the driver change or is it some module loading mechanism in the distro which prevents the faders from showing up in alsamixer? This is so strange. Please help! -- Orm -------------------------------------------------------------------- Hi everybody, after the last update of Ubuntu (intrepid to jaunty) on my Lenovo Ideapad my microphone input doesn't work anymore (neither internal nor external). I found out that alsamixer lacks quite a lot of faders in the newer kernel/module compared to the older one. Some of the faders now unavailable were crucial for Mic input to work on the older system so I'd very much like to get them back ;-) Some more infos: Soundcard: Intel 82801G (ICH7 Family) Chip: Realtek ALC269 Module: snd_hda_intel (in both kernels) Older kernel: Ubuntu stock 2.6.27-14-generic Newer kernel: Ubuntu stock 2.6.28-13-rt Is there any way to make the missing controls available or did the driver change and I have to compile the older driver for the new kernel? Yours, Orm

2 3

[alsa-devel] [ASoc] TDM over one SSC channel on AT91 possible?
by Friedrich Lobenstock 24 Jun '11

24 Jun '11

Hello! The background: I'm just designing an ATMEL AT91RM9200 based board which got two TLV320AIC33 on board. It is either possible to hook up the two TLV320AIC33 to a separate SSC (synchronous serial control) channel each or use one SSC channel and configure it for TDM (time division multiplex) mode. There is already a driver for TLV320AIC14k/TLV320AIC2k in the development tree, so adding support for the TLV320AIC33 should be feasible. What I'm not sure about is the fact if ASOC is prepared for using channels, especially SSC, in TDM mode. Is the core ASOC structure prepared to handle that? Would we be better off instantiate one drive twice each time with different parameters for the SSC channel? Thanks for any feedback. -- MfG / Regards Friedrich Lobenstock _________________________________________________________ SCOTTY Group Austria GmbH a SCOTTY Group plc company, http://www.scottygroup.com/ _________________________________________________________

4 3

Re: [alsa-devel] [PATCH] ASoC: Add support for Cirrus Logic CS42L52 Lowpower Stereo Codec
by Mark Brown 22 Jun '11

22 Jun '11

On Thu, Feb 25, 2010 at 06:07:35PM -0600, Brian wrote: This is a quick first pass review only. It'd be best if you could include a Signed-off-by line in submissions so that they can be merged if they're OK, even if you expect problems you may be surprised! Overall this looks fairly good - there's a lot of comments below but the vast majority of them are stylistic issues or needing to update to current APIs rather than major structural problems with the code. The main thing I don't really follow is the register access code, there's quite a bit of stuff going on in there. > + * published by the Free Software Foundation. > + * Revision history > + * Nov 2007 Initial version. > + * Oct 2008 Updated to 2.6.26 > + * Feb 2010 Updated to latest asoc git tree Please remove the changelog, once things are merged git takes care of that. > + */ > +#define DEBUG Not by default in mainline :) > +#ifdef DEBUG > +#define SOCDBG(fmt, arg...) printk(KERN_ERR "%s: %s() " fmt, SOC_CS42L52_NAME, __FUNCTION__, ##arg) > +#else > +#define SOCDBG(fmt, arg...) > +#endif > +#define SOCINF(fmt, args...) printk(KERN_INFO "%s: " fmt, SOC_CS42L52_NAME, ##args) > +#define SOCERR(fmt, args...) printk(KERN_ERR "%s: " fmt, SOC_CS42L52_NAME, ##args) Please convert the driver to use the standard dev_ and pr_ macros for this (where possible the dev_ ones are better). > +static int soc_cs42l52_set_bias_level(struct snd_soc_codec *codec, > + enum snd_soc_bias_level level); > +static int soc_cs42l52_pcm_hw_params(struct snd_pcm_substream *substream, > + struct snd_pcm_hw_params *params, > + struct snd_soc_dai *dai); > +static int soc_cs42l52_set_sysclk(struct snd_soc_dai *codec_dai, > + int clk_id, u_int freq, int dir); > +static int soc_cs42l52_digital_mute(struct snd_soc_dai *dai, int mute); > +static int soc_cs42l52_set_fmt(struct snd_soc_dai *codec_dai, > + u_int fmt); > + > +static unsigned int soc_cs42l52_read(struct snd_soc_codec *codec, > + u_int reg); Please use 'unsigned int' rather than 'u_int' for consistency with the rest of ASoC. It's a bit surprising that you need the forward declarations at all but they do no harm. > +/** > + * snd_soc_get_volsw - single mixer get callback > + * @kcontrol: mixer control > + * @uinfo: control element information > + * > + * Callback to get the value of a single mixer control. > + * > + * Returns 0 for success. > + */ > +int snd_soc_cs42l5x_get_volsw(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); > + int reg = kcontrol->private_value & 0xff; The indentation looks wrong - should be tabs for indenting the code blocks. scripts/checkpatch.pl is a pretty good check for this sort of stuff, I'll not mention other issues. > + int shift = (kcontrol->private_value >> 8) & 0x0f; > + int rshift = (kcontrol->private_value >> 12) & 0x0f; > + int max = (kcontrol->private_value >> 16) & 0xff; > + int mask = (1 << fls(max)) - 1; > + int min = (kcontrol->private_value >> 24) & 0xff; > + > + ucontrol->value.integer.value[0] = > + ((snd_soc_read(codec, reg) >> shift) - min) & mask; > + if (shift != rshift) > + ucontrol->value.integer.value[1] = > + ((snd_soc_read(codec, reg) >> rshift) - min) & mask; This and most of the other custom control stuff looks an awful lot like it should be done by adding a SND_SOC_DOUBLE_SIGNED() or something along the lines of the existing _S8() but I didn't read entirely closely. I was speaking to someone on IRC only the other day who needed some of those types for a different device. These should also be updated to use struct soc_mixer_control for the private value rather than shifting everything into the private value, it allows wider ranges and is less error prone. > +static const u8 soc_cs42l52_reg_default[] = { > + 0x00, 0xE0, 0x01, 0x07, 0x05, /*4*/ > + 0xa0, 0x00, 0x00, 0x81, /*8*/ Very nitpicky but you're using a mix of upper and lower case for the letters in the hex digits. > +static inline int soc_cs42l52_read_reg_cache(struct snd_soc_codec *codec, > + u_int reg) > +{ > + u8 *cache = codec->reg_cache; > + > + return reg > SOC_CS42L52_REG_NUM ? -EINVAL : cache[reg]; > +} You should be able to replace all your register I/O code with use of soc-cache.c with 8 bit data, 8 bit register. Except... > + if(info->flags & SOC_CS42L52_ALL_IN_ONE) > + { > + for(i = 0; i < codec->num_dai; i++) > + { > + if(info->machine_handler) > + info->machine_handler(i); ...I'm not sure what's going on here but it could really use an explanation? I'm not sure what ALL_IN_ONE is supposed to do, or what the machine_handler() function is for. > + if(info->flags & SOC_CS42L52_CHIP_SWICTH) > + { > + num = info->flags & SOC_CS42L52_CHIP_MASK; > + if(info->machine_handler) > + info->machine_handler(num); > + } This too. There's a lot of unusual code using this machine handler function. I suspect this can all use ASoC standard stuff. > +static inline int soc_cs42l52_get_revison(struct snd_soc_codec *codec) > +{ > + u8 data; > + u8 addr; > + int num, ret = 0; > + struct soc_codec_cs42l52 *info = (struct soc_codec_cs42l52*)codec->private_data; No need to cast away from void (quite a few examples of this in the code). > + return ret < 0 ? ret : data; I'm not a big fan of the ternery operator... > +static unsigned int soc_cs42l52_read(struct snd_soc_codec *codec, > + u_int reg) > +{ > + u8 data; > + u8 addr; > + int i, ret = 0; > + struct soc_codec_cs42l52 *info = (struct soc_codec_cs42l52*)codec->private_data; > +#ifndef CONFIG_CS42L52_DEBUG > + if(reg == CODEC_CS42L52_SPK_STATUS) > + { > +#endif This really shouldn't be ifdefed. If you need to handle registers that report status from the device with the soc-cache stuff use the volatile_register() callback in the CODEC, any registers that need a CODEC read will call through to the hardware rather than using the cache. > +static const char *cs42l52_adc_mux[] = {"AIN1", "AIN2", "AIN3", "AIN4", "PGA"}; > +static const char *cs42l52_mic_mux[] = {"MIC1", "MIC2"}; > +static const char *cs42l52_stereo_mux[] = {"Mono", "Stereo"}; > +static const char *cs42l52_off[] = {"On", "Off"}; > +static const char *cs42l52_hpmux[] = {"Off", "On"}; > + > +static const struct soc_enum soc_cs42l52_enum[] = { > +SOC_ENUM_DOUBLE(CODEC_CS42L52_ANALOG_HPF_CTL, 4, 6, 2, cs42l52_hpf_freeze), /*0*/ > +SOC_ENUM_SINGLE(CODEC_CS42L52_ADC_HPF_FREQ, 0, 4, cs42l52_hpf_corner_freq), Don't use an array of enums, define individual variables for them. Some drivers use the arrays for historical reasons - they're quite painful to work with if you ever want to change anything in the middle and we've found a few off by one errors in the referencing into the arrays before :/. > +static const struct snd_kcontrol_new soc_cs42l52_controls[] = { > + > +SOC_ENUM("Mic VA Capture Switch", soc_cs42l52_enum[18]), /*0*/ enums shouldn't be called Switch - Switch has a specific meaning to ALSA (see Documentation/sound/alsa/ControlNames.txt, there's quite a few other controls could do with having the components of the name reordered and various other things following that). Normally just omit the ' Switch' from the name. > +SOC_DOUBLE("Analog SR Capture Switch", CODEC_CS42L52_ANALOG_HPF_CTL, 1, 3, 1, 1), > +SOC_DOUBLE("Analog ZC Capture Switch", CODEC_CS42L52_ANALOG_HPF_CTL, 0, 2, 1, 1), This'd normally be 'Capture ZC Switch' if it's for zero cross. > +SOC_ENUM("HPF corner freq Capture Switch", soc_cs42l52_enum[1]), /*5*/ > + > +SOC_SINGLE("Ganged Ctl Capture Switch", CODEC_CS42L52_ADC_MISC_CTL, 7, 1, 1), /* should be enabled init */ What does the comment mean here? > +SOC_SINGLE("HP Analog Gain Playback Volume", CODEC_CS42L52_PB_CTL1, 5, 7, 0), Just "Headphone Volume"? > +SOC_SINGLE("Playback B=A Volume Playback Switch", CODEC_CS42L52_PB_CTL1, 4, 1, 0), /*10*/ /*should be enabled init*/ If this is the mute for the headphone volume it should have the same name but with Switch instead of Volume so applications like alsamixer can display the two together. > +static int soc_cs42l52_add_controls(struct snd_soc_codec *codec) > +{ > + int i,ret = 0; > + > + for(i = 0; i < ARRAY_SIZE(soc_cs42l52_controls); i++) > + { > + ret = snd_ctl_add(codec->card, > + snd_soc_cnew(&soc_cs42l52_controls[i], codec, NULL)); > + if(ret < 0) > + { > + SOCDBG("add cs42l52 controls failed\n"); > + break; Replace this with snd_soc_add_controls(). > + /* Sum switches */ > + SND_SOC_DAPM_PGA("AIN1A Switch", CODEC_CS42L52_ADC_PGA_A, 0, 0, NULL, 0), Without having checked the datasheet I *suspect* most of these switches should be modelled as inputs to a mixer (possibly one with no power control of its own)? The "Switch" in the name certainly looks very out of place in the name of a DAPM control. > + /* Output path */ > + SND_SOC_DAPM_MUX("Passthrough Left Playback Switch", SND_SOC_NOPM, 0, 0, &cs42l52_hpa_mux), Normally "Bypass" instead of "Passthrough". > + /* Mic Bias */ > + {"Mic Bias Capture Switch", "On", "PGA MICA"}, > + {"Mic Bias Capture Switch", "On", "PGA MICB"}, > + {"Mic-Bias", NULL, "Mic Bias Capture Switch"}, > + {"Mic-Bias", NULL, "Mic Bias Capture Switch"}, > + {"ADC Mux Left Capture Switch", "PGA", "Mic-Bias"}, > + {"ADC Mux Right Capture Switch", "PGA", "Mic-Bias"}, > + {"Passthrough Left Playback Switch", "On", "Mic-Bias"}, > + {"Passthrough Right Playback Switch", "On", "Mic-Bias"}, This looks odd - normally the microphone bias would be connected to the microphone input externally and would not be hooked up as an input wihtin the CODEC? > + /* terminator */ > + {NULL, NULL, NULL}, Not needed any more (I'm vaugely surprised this doesn't generate an error). > +#define SOC_CS42L52_RATES ( SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 | \ > + SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_22050 | \ > + SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | \ > + SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | \ > + SNDRV_PCM_RATE_96000 ) /*refer to cs42l52 datasheet page35*/ This is equivalent to SNDRV_PCM_RATE_8000_96000 > +/* #define CONFIG_MANUAL_CLK */ This might use some comments (or should possibly be deleted)? > + soc_cs42l52_set_bias_level(soc_codec, SND_SOC_BIAS_OFF); > + soc_codec->bias_level = SND_SOC_BIAS_STANDBY; > + schedule_delayed_work(&soc_codec->delayed_work, msecs_to_jiffies(1000)); > + soc_cs42l52_required_setup(soc_codec); A comment about what the delayed work is up to wouldn't hurt? > + /*set hp default volume*/ > + soc_cs42l52_write(soc_codec, CODEC_CS42L52_HPA_VOL, DEFAULT_HP_VOL); > + soc_cs42l52_write(soc_codec, CODEC_CS42L52_HPB_VOL, DEFAULT_HP_VOL); For pretty much all the configuration you're doing here just let userspace set things up, there's no telling what's an appropriate setting on any given system and presumably the chip designers made a reasonable effort to ensure that the default state of the chip is at least not harmful. > +#ifdef CONFIG_MANUAL_CLK > + soc_cs42l52_write(soc_codec, CODEC_CS42L52_CLK_CTL, > + (soc_cs42l52_read(soc_codec, CODEC_CS42L52_CLK_CTL) > + & ~CLK_CTL_AUTODECT_ENABLE)); Pass this configuration in as platform data, this will allow multiple boards to build from the same kernel. > + ret = snd_soc_init_card(soc_dev); > + if(ret) > + { > + SOCERR("add snd card failed\n"); > + goto card_err; > + } Please develop against git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.35 (or whatever the latest kernel version branch is at any given time.) You should also be calling snd_soc_register_codec() and snd_soc_register_dai() from this function. > +#if defined (CONFIG_I2C) || defined (CONFIG_I2C_MODULE) No need for the ifdefs if you only support I2C, the ifdefs are used by drivers that have multiple control interfaces (typically I2C plus SPI). > + } > + > + > + return ret; > +} > + > +static int cs42l52_i2c_remove(struct i2c_client *client) > +{ > + struct snd_soc_codec *soc_codec; > + if(client) > + { > + soc_codec = i2c_get_clientdata(client); > + if(soc_codec) > + kfree(soc_codec->reg_cache); > + } > + return 0; > +} This should be unregistering from ASoC as well, or refusing to remove if not implemented. > + case SND_SOC_DAIFMT_DSP_B: > + SOCINF("unsupported format\n"); > + ret = -EINVAL; > + goto done; > + default: > + SOCINF("invaild format\n"); > + ret = -EINVAL; > + goto done; Could just squash these together. > + case SND_SOC_DAIFMT_IB_IF: > + SOCDBG("codec dai fmt inversed sclk\n"); > + iface |= IFACE_CTL1_INV_SCLK; > + break; > + case SND_SOC_DAIFMT_IB_NF: > + iface |= IFACE_CTL1_INV_SCLK; > + break; It looks like the hardware only supports the inversion of one of the clocks so only two of the clock polarity combinations should be supported? > + info->format = iface; I'd really expect to see interaction with the hardware here? > + /* 96k */ > + {12288000, 96000, CLK_CTL_S_DS_MODE, CLK_CTL_NOT_32K, CLK_CTL_NOT_27M, CLK_CTL_RATIO_128, 0}, > + {18432000, 96000, CLK_CTL_S_DS_MODE, CLK_CTL_NOT_32K, CLK_CTL_NOT_27M, CLK_CTL_RATIO_128, 0},/*29*/ > + {12000000, 96000, CLK_CTL_S_DS_MODE, CLK_CTL_NOT_32K, CLK_CTL_NOT_27M, CLK_CTL_RATIO_125, 0}, > + {24000000, 96000, CLK_CTL_S_DS_MODE, CLK_CTL_NOT_32K, CLK_CTL_NOT_27M, CLK_CTL_RATIO_125, 1}, If you're feeling adventurous you should be able to use this data to set up constraints for the DAI in the startup() callback so only sample rates supported from the system clock can be used by userspace. > +static int soc_cs42l52_pcm_hw_params(struct snd_pcm_substream *substream, > + struct snd_pcm_hw_params *params, > + struct snd_soc_dai *dai) > +{ > + int ret = 0; > + struct snd_soc_pcm_runtime *rtd = substream->private_data; > + struct snd_soc_device *soc_dev = rtd->socdev; > + struct snd_soc_codec *soc_codec = soc_dev->card->codec; > + struct soc_codec_cs42l52 *info = (struct soc_codec_cs42l52*)soc_codec->private_data; > + > + u32 clk = 0; > + int index = soc_cs42l52_get_clk(info->sysclk, params_rate(params)); > +static int soc_cs42l52_suspend(struct platform_device *pdev, pm_message_t state) > +{ > + struct snd_soc_device *soc_dev = (struct snd_soc_device*)platform_get_drvdata(pdev); > + struct snd_soc_codec *soc_codec = soc_dev->card->codec; > + > + soc_cs42l52_write(soc_codec, CODEC_CS42L52_PWCTL1, PWCTL1_PDN_CODEC); > + soc_cs42l52_set_bias_level(soc_codec, SND_SOC_BIAS_OFF); I'd expect that set_bias_level() would do what the explict write does? > +#if defined (CONFIG_I2C) || defined (CONFIG_I2C_MODULE) > + if(soc_codec_data->i2c_addr) > + { > + ret = i2c_add_driver(&cs42l52_i2c_drv); > + > + if(ret) > + { > + SOCERR("register i2c driver failed\n"); > + goto out; > + > + } > + SOCINF("Cirrus Logic ALSA SoC codec cs42l52 driver verison 1.2 2/2010\n"); > + return ret; > + } This should be changed to use standard device model registration - see http://git.kernel.org/?p=linux/kernel/git/broonie/sound-2.6.git;a=commit;h=… for an example of doing the conversion. > +struct soc_codec_cs42l52_data{ > + u_short i2c_addr; > +}; With the device model stuff this won't be needed any more. > +/* > + *CS42L52 internal registers > + */ > +#define CODEC_CS42L52_CHIP 0x01 > +#define CHIP_ID 0xE0 > +#define CHIP_ID_MASK 0xF8 Many of the register names and other definitions for register fields and values need to be namespace to avoid collisions.

4 5

[alsa-devel] Conexant CX20561 - Microphone problems
by Shawn Starr 19 Apr '11

19 Apr '11

Hello ALSA developers, I am having problems with the microphone on the following hardware this is on a Lenovo W500 laptop. Card: HDA Intel Chip: Conexant CX20561 (Hermosa) Here is the problems im noticing: 1) If I use ALSA 'default' with the microphone I get noise interference on output [high/low/high/low]. If I switch this to use the "ALSA Capture on HDA Intel [CONEXANT Analog] I get interference except it is the standard 60Hz electrical noise [steady noise] 2) Using the internal/external microphones gives an inconsistent volume. It also does not seem to work with the microphone cutting out so much. I need to adjust Digital + another microphone but it still drops capturing. Alsamixer shows: Digital/Docking Microphone/External Microphone/Internal Microphone Here is the module options I give to the sound driver: options snd-intel-hda enable_msi=1 power_save=10 power_save_controller=true model=laptop index=0 Assuming power saving/controller causes the microphone to cut out or not. 3) I'm now aware that this card has no pinouts for PCM capture https://bugzilla.redhat.com/show_bug.cgi?id=502293 Thanks for any help, Shawn.

2 12

[alsa-devel] CA0110 taints kernel
by Vedran Miletić 13 Apr '11

13 Apr '11

Hi, I experience frequent kernel crashes with 2.6.31 and CA0110. I know this card doesn't work, and there is no problem with that; however, it crashing non-stop is not very nice. Also, card doesn't get any controls (and I believe it does get some controls when it's the only card using HDA driver, that is when I disable onboard one). dmesg is here: http://pastebin.com/m7c53562f lspci: 02:00.0 PCI bridge: Creative Labs Device 7006 (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=02, secondary=03, subordinate=03, sec-latency=64 Memory behind bridge: fe900000-fe9fffff Capabilities: [50] Power Management version 3 Capabilities: [60] MSI: Enable- Count=1/16 Maskable- 64bit+ Capabilities: [80] Subsystem: Creative Labs Device 0010 Capabilities: [90] Express PCI/PCI-X Bridge, MSI 00 Capabilities: [100] Advanced Error Reporting Kernel modules: shpchp 03:00.0 Audio device: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG Subsystem: Creative Labs Device 0018 Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at fe9fc000 (32-bit, non-prefetchable) [size=16K] Capabilities: [dc] Power Management version 3 Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel Any ideas? -- Vedran Miletić P.S. Please CC me, as I'm not subscribed to mailing list at the moment.

2 2

[alsa-devel] idt STAC927x adat supported (sigmatel HDA codec) ?
by Eric 03 Mar '11

03 Mar '11

Is the ADAT output of the IDT (sigmatel) STAC927x HDA codec supported in alsa ? If not could someone please try to add this incredibly nice feature in the existing alsa driver ? Thank you very much

4 13

[alsa-devel] davinci-i2c,pcm updates
by Troy Kisky 27 Sep '10

27 Sep '10

This patch set is against git://git.alsa-project.org/alsa-kernel.git but the last patch in series won't compile until the sram allocator patch is available.

8 44

[alsa-devel] [PATCH 2.6.32.3] hda_intel: ALSA HD Audio patch for Intel Cougar Point DeviceIDs
by Seth Heasley 13 Sep '10

13 Sep '10

This patch adds the Intel Cougar Point (PCH) HD Audio Controller DeviceIDs. Signed-off-by: Seth Heasley <seth.heasley(a)intel.com> --- linux-2.6.32.3/sound/pci/hda/hda_intel.c.orig 2010-01-06 15:07:45.000000000 -0800 +++ linux-2.6.32.3/sound/pci/hda/hda_intel.c 2010-01-07 13:10:28.000000000 -0800 @@ -116,6 +116,7 @@ "{Intel, ICH9}," "{Intel, ICH10}," "{Intel, PCH}," + "{Intel, CPT}," "{Intel, SCH}," "{ATI, SB450}," "{ATI, SB600}," @@ -2648,6 +2649,8 @@ { PCI_DEVICE(0x8086, 0x3a6e), .driver_data = AZX_DRIVER_ICH }, /* PCH */ { PCI_DEVICE(0x8086, 0x3b56), .driver_data = AZX_DRIVER_ICH }, + /* CPT */ + { PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_ICH }, /* SCH */ { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH }, /* ATI SB 450/600 */

2 5

Re: [alsa-devel] Patchmix-style application for EMU cards
by Camilo Polymeris 30 Aug '10

30 Aug '10

Hello > That is more or less what I had figured out, but it how are playback_1 to > > _16 channels routed to DSP0-15? It seems that it depends on the setting > of > > Front, Surround, LFE, etc. mixer controls. If they are turned up, I > don't > > understand what happens, sound to playback channels appears on various > DSP > > buses, at different levels. > > Really? Well, I didn't much experiment with surround mode. In source code, > I > can see that there are up to playback 8 channels at hw:0,0 with can be > controlled by faders in alsamixer. I tried surround40 and surroun51 on my > emu1616m and it worked as expected. The channles were mapped to first > couple > of DSP ports in a correct order. In fact this should work the same as > audigy > does, except the result is passed to DSP ports instead of physical > outputs. > On my card, playback channels 1 & 2 (hw:0,3) appear on all DSP busses associated with surround. Say you turn up the "Side" fader in alsamixer, channels 1 & 2 will appear at the relevant DSPs (6-7, I think) Whatever, for now I am just keeping all surround controls down (that is, Front, Surround, Center, Side & LFE). > Anyway, I think if there is another layer of routing done in audigy DSP, > it > shouldn't be used in EMU specific application. Or at least not for now. > The > most important thing is to provide all the switches and FPGA routing > scheme > for each EMU model. Or, to be precise, three routing schemes for each EMU > model, because for "double speed" (e.g. 96kHz) and "quadro speed" (e.g. > 192kHz) modes of operation the numebr of both physical and virtual > channels > changes. > I think the switches and enums for the card models are rather trivial, one can handle it with a customized version of qamix (done with a simple XML file), for example. A separate application would not be necessary for only that. > > If I turn the Front/Surround/LFE/etc. faders down, I can mix playback > > channels to DSP using the "Multichannel PCM Send/Routing/Volume" faders, > in > > a more or less intuitive way, besides that routing values do not map > > directly to DSP buses (i.e. 14-15 map to DSP0-1, but 2-3 map to DSP2-3). > Handling of this controls motivated me to write the application in the first place. No sound at all will appear if I don't set the appropiate controls for each playback channel: Multichannel PCM Volume (full), Multichannel PCM Send (an index of 8 controls, the first 4 select the target DSP) & Multichannel PCM Send Volume (again faders 0-3 of 8) By the way, only DSP0-7 work in this way. I have no idea how to make DSP8-31 work. On which card you did tested it? The driver was primary written for the > 1820M/1212M V1, so some things may not work well on other models and need > to > be fixed. I have a 1212m, don't know which version, but I think it's V1-- it does have firewire. I am using driver version 1.0.16. Thanks, Camilo.

3 3