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

[alsa-devel] 5.1 surround on 3 jacks (retasking)
by Keith Chew 30 Aug '10

30 Aug '10

Hi I have a small-form factor PC (KingYoung brand, model S645), which has 3 jacks connected to a Realtek ALC888 chipset. I have confirmed with the manufacturers the pin outs: 1) The front panel left side phone jack : Codec Line2-L & Line2-R (pin 14 & pin 15) 2) The front panel right side phone jack : Codec Mic2-L & Mic2-R (pin 16 & pin 17) 3) The back panel phone jack : Codec Front-L & Front-R (pin 35 & pin 36) I would like to update patch_realtek.c in alsa-drivers, to output 5.1 surround using these 3 jacks. Can someone give me some guidance on how I can do this? I have looked and studied patch_realtek as much as I can, I just need some help in getting started. Regards Keith

4 14

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

[alsa-devel] X-Fi Titanium: Capture is possible only with unmuted input
by Thor Kristoffersen 30 Aug '10

30 Aug '10

Hi, I'm having issues with an X-Fi Titanium and ALSA. The problem is that it appears to be impossible to capture without unmuting the channel I'm capturing from. I assume that this must be a bug. If there's anything I can do to assist with debugging this, please let me know. This is my software configuration: - Debian Squeeze - Linux 2.6.32 (Debian Linux 2.6.32-20) - alsa-lib 1.0.23 Best regards, Thor Kristoffersen

2 13

[alsa-devel] Wrong channel order with multichannel HDMI on MCP7A
by Stephen Warren 30 Aug '10

30 Aug '10

[Sorry for breaking threading by pasting the previous email into a new one, but I wasn't subscribed to the list then, so can't just reply...] Anssi Hannula wrote: > Anssi Hannula kirjoitti keskiviikko, 28. heinkuuta 2010 05:42:09: > > Wei Ni kirjoitti tiistai, 27. heinkuuta 2010 10:14:37: > > > Hi, Takashi > > > MCP7x use old HW design in HDMI, they don't support channel mapping like > > > MCP89. It use nvhdmi_dig_playback_pcm_prepare_8ch() to prepare channel > > > mapping and steam id,format. > > > > > > Anssi Hannula > > > Please try the following changes in patch_nvhdmi.c > > > static hda_nid_t nvhdmi_con_nids_7x[4] = { > > > > > > /*front, rear, clfe, rear_surr */ > > > > > > - 0x6, 0x8, 0xa, 0xc, > > > + 0x6, 0xa, 0x8, 0xc, > > > }; > > > > I actually tried that already, but for some reason changing the order in > > nvhdmi_con_nids_7x doesn't have any effect. > > > > Actually, disabling the whole for loop that assigns the channels in > > nvhdmi_dig_playback_pcm_prepare_8ch() has no effect, leading me to believe > > that the commands are not reaching the hardware or they are being > > overridden. > > Well, I confirmed with AC_VERB_GET_CONV that they are getting through, and > they are still the same in nvhdmi_dig_playback_pcm_close_8ch_7x(). > > Any idea why they are having no effect? Anssi, As Wei mentioned above, the older MCP7x HW doesn't support this feature. Wei pointed out offline that this was discussed about a year ago. See for example: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-June/018156.html In that message, Takashi mentioned something about fixing this in alsa-lib. However, I guess this didn't ever get resolved. A couple messages later, it appears that Wu Fengguang confirmed that various Intel chipsets also don't support channel mapping, and have a different fixed mapping. Takashi, is this still something that can/should be solved in alsa-lib? > > I also just noticed that the HDMI output is the only detected output, even > > though this board has analog audio and S/PDIF outputs as well. I'm not sure > > if this is related or not. > > This was not related, updating to latest git fixed it. > > > > -----Original Message----- > > > From: Takashi Iwai [mailto:tiwai at suse.de] > > > Sent: Monday, July 26, 2010 5:35 PM > > > To: Anssi Hannula > > > Cc: alsa-devel at alsa-project.org; Wei Ni > > > Subject: Re: [alsa-devel] Wrong channel order with multichannel HDMI on > > > MCP7A > > > > > > At Mon, 26 Jul 2010 11:14:17 +0200, > > > > > > \u79c1 wrote: > > > > At Sun, 25 Jul 2010 19:51:39 +0300, > > > > > > > > Anssi Hannula wrote: > > > > > Hi all! > > > > > > > > > > I have a motherboard with NVIDIA MCP7A HDMI audio. > > > > > However, multichannel audio is not mapped properly into the HDMI > > > > > order. > > > > > > > > > > On 5.1, I get RL in FC, RR in LFE, FC in RL, LFE in RR. > > > > > > > > > > Interestingly, this is not consistent with the ALSA channel order (FL > > > > > FR RL RR FC LFE) being passed directly to HDMI (FL FR LFE FC RL RR). > > > > > Instead it looks like there has been a waveformatex (FL FR FC LFE RL > > > > > RR; windows?) => HDMI conversion instead of ALSA => HDMI. > > > > > > > > > > Same happens for 7.1. > > > > > > > > > > Is it possible to set the hardware to do an ALSA => HDMI conversion > > > > > instead? If not, we should manually compensate for this somewhere, > > > > > right? > > > > > > > > Does the patch below change anything? > > > > > > Ah crap, it should be irrelevant. > > > Wei, don't MCP 7x chips support the channel mapping as MCP 89? > > > > > > > > > thanks, > > > > > > Takashi > > > > > > > > Somewhat relatedly, trying to output 4 channels results in silence > > > > > only. > > > > > > > > Although 5.1/7.1 work? > > > > > > > > > Trying to output 3 or 5 channels triggers a timeout with I/O error, > > > > > with the following in the kernel log: "ALSA pcm_lib.c:1757: playback > > > > > write error (DMA or IRQ trouble?)" > > > > > > > > HD-audio doesn't support the odd number of channels in general, so > > > > they should be played as 4 or 6 channels. But, it looks like > > > > something wrong in the setup... > > > > > > > > > > > > thanks, > > > > > > > > Takashi > > > > > > > > --- > > > > diff --git a/sound/pci/hda/patch_nvhdmi.c > > > > b/sound/pci/hda/patch_nvhdmi.c index 3c10c0b..7355c60 100644 > > > > --- a/sound/pci/hda/patch_nvhdmi.c > > > > +++ b/sound/pci/hda/patch_nvhdmi.c > > > > @@ -511,6 +511,8 @@ static int patch_nvhdmi_8ch_7x(struct hda_codec > > > > *codec) > > > > > > > > codec->patch_ops = nvhdmi_patch_ops_8ch_7x; > > > > > > > > + init_channel_allocations(); > > > > + > > > > > > > > return 0; > > > > > > > > } -- nvpublic

2 1

[alsa-devel] [PATCH 0/4] Add FSI - HDMI support
by Kuninori Morimoto 30 Aug '10

30 Aug '10

Dear Mark, Paul These are FSI - HDMI prototype sound support Kuninori Morimoto (4): fbdev: sh-mobile: Add HDMI sound type selection ASoC: Add sh_mobile_hdmi sound support ASoC: fsi-codec: Add FSI - HDMI support ARM: mach-shmobile: ap4evb: Add HDMI sound support >> Paul 1st patch is depend on [PATCH] fbdev: sh-mobile_hdmi: remove un-necessity settings which I sent to LinuxSH ML in 2010/08/27 Best regards -- Kuninori Morimoto

2 6

[alsa-devel] [PATCH] ASoC: Complete supported clock ratios and rate constraints for wm8741.
by Ian Lartey 30 Aug '10

30 Aug '10

Signed-off-by: Ian Lartey <ian(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8741.c | 175 ++++++++++++++++++++++++++++++++------------- 1 files changed, 124 insertions(+), 51 deletions(-) diff --git a/sound/soc/codecs/wm8741.c b/sound/soc/codecs/wm8741.c index fdd24da..c8e7a26 100644 --- a/sound/soc/codecs/wm8741.c +++ b/sound/soc/codecs/wm8741.c @@ -36,7 +36,7 @@ static const char *wm8741_supply_names[WM8741_NUM_SUPPLIES] = { "DVDD", }; -#define WM8741_NUM_RATES 4 +#define WM8741_NUM_RATES 6 /* codec private data */ struct wm8741_priv { @@ -44,8 +44,7 @@ struct wm8741_priv { u16 reg_cache[WM8741_REGISTER_COUNT]; struct regulator_bulk_data supplies[WM8741_NUM_SUPPLIES]; unsigned int sysclk; - unsigned int rate_constraint_list[WM8741_NUM_RATES]; - struct snd_pcm_hw_constraint_list rate_constraint; + struct snd_pcm_hw_constraint_list *sysclk_constraints; }; static const u16 wm8741_reg_defaults[WM8741_REGISTER_COUNT] = { @@ -108,10 +107,84 @@ static struct { int value; int ratio; } lrclk_ratios[WM8741_NUM_RATES] = { - { 1, 256 }, - { 2, 384 }, - { 3, 512 }, - { 4, 768 }, + { 1, 128 }, + { 2, 192 }, + { 3, 256 }, + { 4, 384 }, + { 5, 512 }, + { 6, 768 }, +}; + +static unsigned int rates_11289[] = { + 44100, 88235, +}; + +static struct snd_pcm_hw_constraint_list constraints_11289 = { + .count = ARRAY_SIZE(rates_11289), + .list = rates_11289, +}; + +static unsigned int rates_12288[] = { + 32000, 48000, 96000, +}; + +static struct snd_pcm_hw_constraint_list constraints_12288 = { + .count = ARRAY_SIZE(rates_12288), + .list = rates_12288, +}; + +static unsigned int rates_16384[] = { + 32000, +}; + +static struct snd_pcm_hw_constraint_list constraints_16384 = { + .count = ARRAY_SIZE(rates_16384), + .list = rates_16384, +}; + +static unsigned int rates_16934[] = { + 44100, 88235, +}; + +static struct snd_pcm_hw_constraint_list constraints_16934 = { + .count = ARRAY_SIZE(rates_16934), + .list = rates_16934, +}; + +static unsigned int rates_18432[] = { + 48000, 96000, +}; + +static struct snd_pcm_hw_constraint_list constraints_18432 = { + .count = ARRAY_SIZE(rates_18432), + .list = rates_18432, +}; + +static unsigned int rates_22579[] = { + 44100, 88235, 1764000 +}; + +static struct snd_pcm_hw_constraint_list constraints_22579 = { + .count = ARRAY_SIZE(rates_22579), + .list = rates_22579, +}; + +static unsigned int rates_24576[] = { + 32000, 48000, 96000, 192000 +}; + +static struct snd_pcm_hw_constraint_list constraints_24576 = { + .count = ARRAY_SIZE(rates_24576), + .list = rates_24576, +}; + +static unsigned int rates_36864[] = { + 48000, 96000, 19200 +}; + +static struct snd_pcm_hw_constraint_list constraints_36864 = { + .count = ARRAY_SIZE(rates_36864), + .list = rates_36864, }; @@ -132,7 +205,7 @@ static int wm8741_startup(struct snd_pcm_substream *substream, snd_pcm_hw_constraint_list(substream->runtime, 0, SNDRV_PCM_HW_PARAM_RATE, - &wm8741->rate_constraint); + wm8741->sysclk_constraints); return 0; } @@ -192,47 +265,52 @@ static int wm8741_set_dai_sysclk(struct snd_soc_dai *codec_dai, { struct snd_soc_codec *codec = codec_dai->codec; struct wm8741_priv *wm8741 = snd_soc_codec_get_drvdata(codec); - unsigned int val; - int i; dev_dbg(codec->dev, "wm8741_set_dai_sysclk info: freq=%dHz\n", freq); - wm8741->sysclk = freq; - - wm8741->rate_constraint.count = 0; - - for (i = 0; i < ARRAY_SIZE(lrclk_ratios); i++) { - dev_dbg(codec->dev, "index = %d, ratio = %d, freq = %d", - i, lrclk_ratios[i].ratio, freq); - - val = freq / lrclk_ratios[i].ratio; - /* Check that it's a standard rate since core can't - * cope with others and having the odd rates confuses - * constraint matching. - */ - switch (val) { - case 32000: - case 44100: - case 48000: - case 64000: - case 88200: - case 96000: - dev_dbg(codec->dev, "Supported sample rate: %dHz\n", - val); - wm8741->rate_constraint_list[i] = val; - wm8741->rate_constraint.count++; - break; - default: - dev_dbg(codec->dev, "Skipping sample rate: %dHz\n", - val); - } + switch (freq) { + case 11289600: + wm8741->sysclk_constraints = &constraints_11289; + wm8741->sysclk = freq; + return 0; + + case 12288000: + wm8741->sysclk_constraints = &constraints_12288; + wm8741->sysclk = freq; + return 0; + + case 16384000: + wm8741->sysclk_constraints = &constraints_16384; + wm8741->sysclk = freq; + return 0; + + case 16934400: + wm8741->sysclk_constraints = &constraints_16934; + wm8741->sysclk = freq; + return 0; + + case 18432000: + wm8741->sysclk_constraints = &constraints_18432; + wm8741->sysclk = freq; + return 0; + + case 22579200: + case 33868800: + wm8741->sysclk_constraints = &constraints_22579; + wm8741->sysclk = freq; + return 0; + + case 24576000: + wm8741->sysclk_constraints = &constraints_24576; + wm8741->sysclk = freq; + return 0; + + case 36864000: + wm8741->sysclk_constraints = &constraints_36864; + wm8741->sysclk = freq; + return 0; } - - /* Need at least one supported rate... */ - if (wm8741->rate_constraint.count == 0) - return -EINVAL; - - return 0; + return -EINVAL; } static int wm8741_set_dai_fmt(struct snd_soc_dai *codec_dai, @@ -391,10 +469,6 @@ static int wm8741_i2c_probe(struct i2c_client *i2c, if (wm8741 == NULL) return -ENOMEM; - wm8741->rate_constraint.list = &wm8741->rate_constraint_list[0]; - wm8741->rate_constraint.count = - ARRAY_SIZE(wm8741->rate_constraint_list); - for (i = 0; i < ARRAY_SIZE(wm8741->supplies); i++) wm8741->supplies[i].supply = wm8741_supply_names[i]; @@ -464,9 +538,8 @@ static int __init wm8741_modinit(void) #if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE) ret = i2c_add_driver(&wm8741_i2c_driver); - if (ret != 0) { + if (ret != 0) pr_err("Failed to register WM8741 I2C driver: %d\n", ret); - } #endif return ret; -- 1.7.0.4

2 1

[alsa-devel] wm8727 and asoc atmel at91
by András Takács 30 Aug '10

30 Aug '10

Dear All, I would like to using a WM8727 codec on my board, which has at Atmel AT91SAM9261 processor. I implemented the board specific part of the ASoC driver: I'm trying to test it with: cat /dev/urandom > /dev/dsp I'm getting the following error message in dmesg: [ 7.140000] ASoC: SSC0 device request OK [ 7.140000] ASoC: wm8727 device allocation OK [ 7.160000] asoc: WM8727 <-> atmel-ssc0 mapping ok [ 7.160000] SoC IRF WM8727 init [ 7.220000] ASoC: wm8727 device registration OK [ 16.330000] atmel_ssc_startup: SSC_SR=0x204 [ 16.440000] SoC IRF WM8727 hw_params: cpu_dai [ 16.440000] SoC IRF WM8727 hw_params OK [ 16.440000] atmel_ssc_hw_params: RCMR=00010721 RFMR=0000008f TCMR=00010702 TFMR=0000008f [ 16.440000] atmel_ssc_dai: Starting clock [ 16.440000] atmel_ssc_dai,hw_params: SSC initialized [ 16.440000] transmit enabled SSC_SR=0x000104cf [ 210.850000] ALSA sound/core/pcm_lib.c:1758: playback write error (DMA or IRQ trouble?) [ 210.850000] ALSA sound/core/pcm_lib.c:1758: playback write error (DMA or IRQ trouble?) [ 220.850000] ALSA sound/core/pcm_native.c:1492: playback drain error (DMA or IRQ trouble?) [ 220.850000] atmel_ssc_shutdown: transmit disabled SSC_SR=0x000000c0 [ 220.850000] atmel_ssc_dau: Stopping clock Did anybody used this codec before? What's missing from my code? My source code: static int soc_irf_wm8727_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; int ret; printk("SoC IRF WM8727 hw_params: cpu_dai\n"); /* set cpu DAI configuration */ ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM); if (ret < 0) return ret; printk("SoC IRF WM8727 hw_params OK\n"); return 0; } static struct snd_soc_ops soc_irf_wm8727_ops = { .hw_params = soc_irf_wm8727_hw_params, }; static int soc_irf_wm8727_init(struct snd_soc_codec *codec) { printk("SoC IRF WM8727 init\n"); return 0; } static struct snd_soc_dai_link soc_irf_wm8727_dai[] = { { .name = "WM8727", .stream_name = "WM8727 PCM", .cpu_dai = &atmel_ssc_dai[0], .codec_dai = &wm8727_dai, .init = soc_irf_wm8727_init, .ops = &soc_irf_wm8727_ops, } }; static struct snd_soc_card snd_soc_wm8727_irf = { .name = "SOC_IRF_WM8727", .platform = &atmel_soc_platform, .dai_link = soc_irf_wm8727_dai, .num_links = ARRAY_SIZE(soc_irf_wm8727_dai), }; static struct snd_soc_device soc_irf_wm8727_snd_devdata = { .card = &snd_soc_wm8727_irf, .codec_dev = &soc_codec_dev_wm8727, }; static struct platform_device *soc_irf_wm8727_snd_device; static int __init soc_irf_init(void) { struct atmel_ssc_info *ssc_p_wm8727 = soc_irf_wm8727_dai[0].cpu_dai->private_data; struct ssc_device *ssc = NULL; int ret; /* Request SSC device */ ssc = ssc_request(0); if (IS_ERR(ssc)) { printk(KERN_ERR "ASoC: Failed to request SSC 0\n"); ret = PTR_ERR(ssc); ssc = NULL; goto err; } ssc_p_wm8727->ssc = ssc; printk("ASoC: SSC0 device request OK\n"); at91_set_B_periph(AT91_PIN_PA17, 1); at91_set_B_periph(AT91_PIN_PA18, 1); at91_set_B_periph(AT91_PIN_PA19, 1); /* WM8727 codec */ soc_irf_wm8727_snd_device = platform_device_alloc("soc-audio", 1); if (!soc_irf_wm8727_snd_device) { printk(KERN_ERR "ASoC: Platform device allocation failed: wm8727\n"); ret = -ENOMEM; goto err_ssc; } printk("ASoC: wm8727 device allocation OK\n"); platform_set_drvdata(soc_irf_wm8727_snd_device, &soc_irf_wm8727_snd_devdata); soc_irf_wm8727_snd_devdata.dev = &soc_irf_wm8727_snd_device->dev; ret = platform_device_add(soc_irf_wm8727_snd_device); if (ret) { printk(KERN_ERR "ASoC: Platform device allocation failed: wm8727\n"); ret = -ENODEV; goto err_wm8727; } printk("ASoC: wm8727 device registration OK\n"); return ret; err_ssc: ssc_free(ssc); ssc_p_wm8727->ssc = NULL; err: return ret; } static void __exit soc_irf_exit(void) { struct atmel_ssc_info *ssc_p_wm8727 = soc_irf_wm8727_dai[0].cpu_dai->private_data; struct ssc_device *ssc; if (ssc_p_wm8727 != NULL) { ssc = ssc_p_wm8727->ssc; if (ssc != NULL) ssc_free(ssc); ssc_p_wm8727->ssc = NULL; } platform_device_unregister(soc_irf_wm8727_snd_device); soc_irf_wm8727_snd_device = NULL; } module_init(soc_irf_init); module_exit(soc_irf_exit); Thank you for your help! BR, András

1 0

[alsa-devel] imx-ssi in master mode?
by Sven Zeisberg 30 Aug '10

30 Aug '10

Hi I found that the i.MX25 can not transfer multichannels frames through SSI when it is set up as slave. (when the i.MX25 SSI is set up as slave, the SSI is set to "normal" mode in which only one word per frame is transfered) Now I'm wondering if anybody has successfully used a codec with the i.MX25 SSI set up as Master. When we do this here, we can see that the i.MX25 is generating the bit clock but no frame sync. BR Sven

2 2

[alsa-devel] How to transfer more than 2 channels between i.MX25 & AD1938 using SSI?
by Sven Zeisberg 30 Aug '10

30 Aug '10

Hi, has anybody succeeded to transfer more than 2 audio channels between i.MX25 and a CODEC throught the i.MX25 SSI Port? We have succeeded to set the CODEC (AD1938) as Master to the required mode (TDM with 8 Timeslots and 32 Bit per Timeslot). However, as soon as we start to play a wav file with aplay, we can see on the logic analyzer that the data format on the SSI lines is reset to a stereo mode (2 channels with frame sync changing level between channels). In the imx-ssi driver, I can see that .channel_max = 2 - therefore my question: does this driver support more than two channels at all? BR Sven

2 2

[alsa-devel] [PATCH v4 0/3] ASoC: Add iPAQ RX1950 support
by Vasily Khoruzhick 29 Aug '10

29 Aug '10

These three patches are necessary to add sound support for iPAQ RX1950 PDA, appropriate mach-rx1950.c patch is missing, as it depends on battery and LEDs patches which are still not merged nor reviewed. First patch improves situation with power consumption for uda1380 and also fixes suspend/resume. Second patch just adds glue driver. Third patch fixes s3c_device_iis name and exports s3c_device_pcm for all s3c24xx-based devices.

2 15