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

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] Routing irq throw a gpio using the wm9713
by Michael Trimarchi 18 Aug '10

18 Aug '10

Hi all, I'm trying to rise an irq using irq2 of the wm9713 so I have configured the codec like this: #define GPIO2 (1 << 2) #define GPIO6 (1 << 6) /* Enable Interrupt Output enable on GPIO02 */ reg = codec->read(codec, AC97_MISC_AFE); codec->write(codec, AC97_MISC_AFE, reg & ~GPIO02); reg = codec->read(codec, AC97_GPIO_CFG); codec->write(codec, AC97_GPIO_CFG, reg & ~GPIO02); reg = codec->read(codec, AC97_GPIO_STICKY); codec->write(codec, AC97_GPIO_STICKY, reg | GPIO06); reg = codec->read(codec, AC97_GPIO_WAKEUP); codec->write(codec, AC97_GPIO_WAKEUP, reg | GPIO06); Then create a soc-jack on a gpio that is wired with the gpio6 of the codec. I don't received any interrupt Michael Trimarchi

1 1

[alsa-devel] [PATCH]alsa:patch_realtek.c Add support for the MacBookAir1, 1
by Justin P. Mattock 30 Jul '10

30 Jul '10

This patch adds support for the MacBookAir1,1 Note:I do not have this machine on hand only the codec#0 file for the machine.. located at https://bugs.launchpad.net/mactel-support/+bug/268301 So please test if you have the appropriate equipment, and report any issues to the alsa devel list (alsa-devel(a)alsa-project.org). Signed-off-by: Justin P. Mattock <justinmattock(a)gmail.com> --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 + sound/pci/hda/patch_realtek.c | 59 +++++++++++++++++++++++++- 2 files changed, 58 insertions(+), 2 deletions(-) diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 1d38b0d..d3838b5 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -125,6 +125,7 @@ ALC882/883/885/888/889 macpro MacPro support mb5 Macbook 5,1 macmini3 Macmini 3,1 + mba11 MacBook Air 1,1 mba21 Macbook Air 2,1 mbp3 Macbook Pro rev3 imac24 iMac 24'' with jack detection diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index fc767b6..1dcf78c 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -209,6 +209,7 @@ enum { ALC882_ASUS_A7J, ALC882_ASUS_A7M, ALC885_MACPRO, + ALC885_MBA11, ALC885_MBA21, ALC885_MBP3, ALC885_MB5, @@ -7444,6 +7445,13 @@ static struct snd_kcontrol_new alc885_mba21_mixer[] = { { } }; +/* MacBookAir1,1 not sure what/where things are(dont have the machine). */ + +static struct snd_kcontrol_new alc885_mba11_mixer[] = { + HDA_CODEC_VOLUME("Speaker Playback Volume", 0x0c, 0x00, HDA_OUTPUT), + HDA_BIND_MUTE("Speaker Playback Switch", 0x0c, 0x02, HDA_OUTPUT), + { } +}; static struct snd_kcontrol_new alc885_mbp3_mixer[] = { HDA_CODEC_VOLUME("Speaker Playback Volume", 0x0c, 0x00, HDA_OUTPUT), @@ -7929,6 +7937,40 @@ static struct hda_verb alc885_mba21_init_verbs[] = { { } }; +static struct hda_verb alc885_mba11_init_verbs[] = { + /*Internal and HP Speaker Mixer*/ + {0x0c, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_ZERO}, + {0x0c, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, + {0x0c, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)}, + /* Main Speaker */ + {0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, (PIN_OUT | AC_PINCTL_VREF_50) }, + {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE}, + {0x14, AC_VERB_SET_CONNECT_SEL, 0x00}, + /* HP jack */ + {0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, 0xc4}, + {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE}, + {0x15, AC_VERB_SET_CONNECT_SEL, 0x00}, + {0x15, AC_VERB_SET_UNSOLICITED_ENABLE, (ALC880_HP_EVENT | AC_USRSP_EN)}, + /* FIXME: Line in? (as well as the mic). */ + {0x17, AC_VERB_SET_PIN_WIDGET_CONTROL, AC_PINCTL_VREF_50}, + {0x17, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE}, + /* 0x22 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In */ + {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, + {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, + {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, + {0x22, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, + /* 0x23 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In */ + {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, + {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, + {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, + {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, + /* 0x24 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In */ + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, + { } +}; /* Macbook Pro rev3 */ static struct hda_verb alc885_mbp3_init_verbs[] = { @@ -9298,6 +9340,7 @@ static const char *alc882_models[ALC882_MODEL_LAST] = { [ALC885_MACPRO] = "macpro", [ALC885_MB5] = "mb5", [ALC885_MACMINI3] = "macmini3", + [ALC885_MBA11] = "mba11", [ALC885_MBA21] = "mba21", [ALC885_MBP3] = "mbp3", [ALC885_IMAC24] = "imac24", @@ -9478,7 +9521,7 @@ static struct snd_pci_quirk alc882_ssid_cfg_tbl[] = { SND_PCI_QUIRK(0x106b, 0x2c00, "MacbookPro rev3", ALC885_MBP3), SND_PCI_QUIRK(0x106b, 0x3000, "iMac", ALC889A_MB31), SND_PCI_QUIRK(0x106b, 0x3200, "iMac 7,1 Aluminum", ALC882_ASUS_A7M), - SND_PCI_QUIRK(0x106b, 0x3400, "MacBookAir 1,1", ALC885_MBP3), + SND_PCI_QUIRK(0x106b, 0x3400, "MacBookAir 1,1", ALC885_MBA11), SND_PCI_QUIRK(0x106b, 0x3500, "MacBookAir 2,1", ALC885_MBA21), SND_PCI_QUIRK(0x106b, 0x3600, "Macbook 3,1", ALC889A_MB31), SND_PCI_QUIRK(0x106b, 0x3800, "MacbookPro 4,1", ALC885_MBP3), @@ -9542,7 +9585,19 @@ static struct alc_config_preset alc882_presets[] = { .input_mux = &alc882_capture_source, .dig_out_nid = ALC882_DIGOUT_NID, }, - [ALC885_MBA21] = { + [ALC885_MBA11] = { + .mixers = { alc885_mba11_mixer }, + .init_verbs = { alc885_mba11_init_verbs, alc880_gpio1_init_verbs }, + .num_dacs = 2, + .dac_nids = alc882_dac_nids, + .channel_mode = alc885_mba21_ch_modes, + .num_channel_mode = ARRAY_SIZE(alc885_mba21_ch_modes), + .input_mux = &alc882_capture_source, + .unsol_event = alc_automute_amp_unsol_event, + .setup = alc885_mbp3_setup, + .init_hook = alc_automute_amp, + }, + [ALC885_MBA21] = { .mixers = { alc885_mba21_mixer }, .init_verbs = { alc885_mba21_init_verbs, alc880_gpio1_init_verbs }, .num_dacs = 2, -- 1.7.1.rc1.21.gf3bd6

2 2

[alsa-devel] [PATCH] Two patches for Alsa-plugins (pulse)
by David Henningsson 29 Jul '10

29 Jul '10

These two patches are being used in Ubuntu Lucid (released this April) and are working well enough to have people asking us to backport them to Karmic. Today I got an email, asking for the upstream status of one of these patches, since he wanted them in Fedora. If posting them here isn't the correct way to upstream them, please tell me so. The first one (Fix invalid buffer pointer return value) fixes broken logic: This patch improves recovering from underruns, and prevents hangs inside snd_pcm_write* and snd_pcm_read* due to snd_pcm_avail* returning too low values. It especially helps low latency situations. The second one (Do not report underruns to the ALSA layer) is more a change of behavior, which could be questioned. The arguments for removing that code are these: * If pulseaudio gets an underrun, the normal way to end that underrun is to feed it with more buffers. This is different from the ALSA way of dealing with underruns, which requires hardware buffer pointers to be reset. * In addition, underrun signals are delivered asynchronously from pulseaudio. This means that there might be more buffers on the way to pulseaudio when the underrun is reported, making the underrun obsolete. Unfortunately, there is currently no known way to determine whether this is the case or not. // David

5 20

[alsa-devel] [PATCH] Ensure codec patch files are checked for the correct codec ID
by David Henningsson 26 Jul '10

26 Jul '10

This one just popped out when I read the source code - or is there a reason for parsing vendorid and subid without caring about the result? // David

4 5

[alsa-devel] [PATCH 1/4] ASoC: DaVinci: remove requirement that dma_params is 1st in structure
by Troy Kisky 13 Jul '10

13 Jul '10

Remove requirement that dma_params is 1st in the structures davinci_audio_dev and davinci_mcbsp_dev. Signed-off-by: Troy Kisky <troy.kisky(a)boundarydevices.com> --- sound/soc/davinci/davinci-i2s.c | 6 +----- sound/soc/davinci/davinci-mcasp.c | 1 + sound/soc/davinci/davinci-mcasp.h | 5 ----- sound/soc/davinci/davinci-pcm.c | 7 ++++--- 4 files changed, 6 insertions(+), 13 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index 4ae7070..9e69a4e 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -98,11 +98,6 @@ enum { }; struct davinci_mcbsp_dev { - /* - * dma_params must be first because rtd->dai->cpu_dai->private_data - * is cast to a pointer of an array of struct davinci_pcm_dma_params in - * davinci_pcm_open. - */ struct davinci_pcm_dma_params dma_params[2]; void __iomem *base; #define MOD_DSP_A 0 @@ -547,6 +542,7 @@ static int davinci_i2s_probe(struct platform_device *pdev) dev->dma_params[SNDRV_PCM_STREAM_CAPTURE].channel = res->start; davinci_i2s_dai.private_data = dev; + davinci_i2s_dai.dma_data = dev->dma_params; ret = snd_soc_register_dai(&davinci_i2s_dai); if (ret != 0) goto err_free_mem; diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 5d1f98a..5023915 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -907,6 +907,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev) dma_data->channel = res->start; davinci_mcasp_dai[pdata->op_mode].private_data = dev; + davinci_mcasp_dai[pdata->op_mode].dma_data = dev->dma_params; davinci_mcasp_dai[pdata->op_mode].dev = &pdev->dev; ret = snd_soc_register_dai(&davinci_mcasp_dai[pdata->op_mode]); diff --git a/sound/soc/davinci/davinci-mcasp.h b/sound/soc/davinci/davinci-mcasp.h index 9d179cc..582c924 100644 --- a/sound/soc/davinci/davinci-mcasp.h +++ b/sound/soc/davinci/davinci-mcasp.h @@ -39,11 +39,6 @@ enum { }; struct davinci_audio_dev { - /* - * dma_params must be first because rtd->dai->cpu_dai->private_data - * is cast to a pointer of an array of struct davinci_pcm_dma_params in - * davinci_pcm_open. - */ struct davinci_pcm_dma_params dma_params[2]; void __iomem *base; int sample_rate; diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index c73a915..c2c2e85 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -238,10 +238,11 @@ static int davinci_pcm_open(struct snd_pcm_substream *substream) struct davinci_runtime_data *prtd; int ret = 0; struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct davinci_pcm_dma_params *pa = rtd->dai->cpu_dai->private_data; - struct davinci_pcm_dma_params *params = &pa[substream->stream]; - if (!params) + struct davinci_pcm_dma_params *pa = rtd->dai->cpu_dai->dma_data; + struct davinci_pcm_dma_params *params; + if (!pa) return -ENODEV; + params = &pa[substream->stream]; snd_soc_set_runtime_hwparams(substream, &davinci_pcm_hardware); /* ensure that buffer size is a multiple of period size */ -- 1.5.6.3

3 5

[alsa-devel] How does struct snd_pcm_hardware relate to the actual hardware
by Adam Rosenberg 12 Jul '10

12 Jul '10

I am using DMA to transfer data to SPORT1 on my Blackfin BF537. I am using a CS42448 CODEC that has 8 DACs. I am using TDM mode and have set the following: DMA Buffer Size For Each SPORT Data Line (Rx or Tx) = 131072 bytes DMA Periods = 8 static struct snd_pcm_hardware snd_pcm_hw = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_RESUME), .formats = SNDRV_PCM_FMTBIT_S32_LE, .rates = SNDRV_PCM_RATE_48000, .rate_min = 48000, .rate_max = 48000, .buffer_bytes_max = 32768, .channels_min = 2, .channels_max = 2, .period_bytes_min = 8, .period_bytes_max = 4096, .periods_min = 8, .periods_max = 8, }; Everytime I receive a DMA interrupt from the SPORT driver I call snd_pcm_period_elapsed for all of the substreams that are currently active. In the PCM Copy callback I calculate the position within the DMA buffer to write to based on the TDM slot for the channel and the position passed into the function. The audio is not being placed into the DMA buffer properly. The audio plays faster than it should and has a constant stutter. I have read the "writing an ALSA driver" guide multiple times but it does not explain the relationship between struct snd_pcm_hardware, snd_pcm_period_elapsed, and the copy callback clearly enough for me to understand what I am doing wrong. Please explain how these interact in more detail to help me fix this problem. I can also send the full source code to the CS42448 driver I am working on if more details are needed. Thank you, Adam

2 2

[alsa-devel] Smart 5.1 function not working on VIA VT1708S with *three* jacks on mainboard
by Viliam Kubis 09 Jul '10

09 Jul '10

Hello, for quite some time the "Smart 5.1" function in alsa is not working properly when motherboard has only 3 audio jacks. Me and Raymond on alsa-bugtracker have been trying to solve the issue for a long time but were unsuccessful. Please take a look at this alsa bug ticket: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4895 It contains A LOT of info on the problem + steps that we tried, which included patching the code. Synthom : NO "Surround" , "Center" and "LFE" Control and switch with VT1708S on a motherboard with 3 audio jacks Also NO surround sound. speaker-test -c 4 -t wav -Dsurround40 Channels count (4) not available for playbacks: Invalid argument Setting of hwparams failed: Invalid argument Please advise if you can. Thank you Best Regards Viliam Kubis -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

3 3

[alsa-devel] [RFC 00/16] ASoC: multi-component - CODECs
by Liam Girdwood 05 Jul '10

05 Jul '10

This is the second part of the multi-component series and focuses on the changes required to support ASoC multi-component on CODEC drivers. I've split the CODEC driver patches into smaller chunks and tried to group (where possible) similar CODECs together. All the patches will be rebased together at upstream time so we don't break bisect. Most CODEC drivers were extremely straight forward with changes limited to their probe() and remove() sections. Some CODECs did require a little extra work and this is marked in their commit messages. Thanks Liam

5 24

[alsa-devel] [RFC 0/5] ASoC multi-component support : core
by Liam Girdwood 05 Jul '10

05 Jul '10

ASoC is now coming up to it's 5th birthday and is beginning to show it's age a little when it comes to supporting the next generation of smart phones and multimedia devices with it's current single CODEC and single DMA platform design. Historically, ASoC is designed around an embedded sound card with a single CODEC and a single platform DMA driver (with multiple DAIs). This design works great for most of the current audio hardware in production, however we are now seeing hardware designs for the next generation of devices that can have many CODECs, DMAs, DSPs and a host of other audio peripherals connected to the audio subsystem. So we now need ASoC to support new audio hardware architectures with multiple audio CODECs, DMA engines, DSPs, DAIs etc. This patch series allows an ASoC sound card to support multiple components (CODECs, DAI and DMA) and is the first part in a series of work (other parts coming later in the year from Mark and I) designed to enhance ASoC for modern mobile audio hardware. This patch series provides the following important features:- 1) Allow sound cards to have multiple CODECs and platform DMA controllers. 2) Allow CODEC drivers to support more than one CODEC device. 3) Allow all CODEC, platform DMA and DAI drivers to have platform data. This is achieved by: - 1) Separating the component struct driver data from the component struct device data. 2) Making all components kernel devices. (A side effect of this change is that we can now store all our component private data in struct device private data (like everyone else) and there is also now less pointer indirection for components.) The change mainly affects only the probe() and remove() sections of component drivers and the component enumeration section of the core. The core also now handles setting up the CODEC data structs too (meaning CODEC drivers dont have to do this). All component PCM, DAPM and Kcontrol operations remain unchanged. I've so far tested the new multi-component enumeration on the TI OMAP and Marvell PXA platforms with AC97, MFD and I2C based CODECs. I do however need ASoC platform maintainers to test on their systems (as I only have a subset of the hardware). Some ASOC platforms do need a little extra checking/fixups too :- o Samsung platform: required the most work to untangle the components. o i.MX platform: required work to de-couple components. o Injenic J4740 platform: I do not have a toolchain to even build this arch so it will also need someone to build it too. If you find your platform does not work then the most likely reason is that I'm missing a platform_device registration for your CODEC, DAI, etc. device in your arch board.c or device.c files. Please let me know or send a patch :) All the multi-component code is in my multi-component branch here :- git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git This RFC post contains the changes to ASoC core only. I'll post the multi-component CODEC and platform changes as separate RFCs in order not to flood the list (as there are 38 patches in all). This patch series will eventually be rebased into a single patch for upstream so we dont break bisect. The subsequent patches for CODECs and platforms in this series can be found in the git branch above. The intention is to upstream this for 2.6.36 Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk

5 14