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

[alsa-devel] [PATCH 0/2] ASoC: fsi: modify bug fix
by Kuninori Morimoto 31 Aug '10

31 Aug '10

Dear Mark, Liam These are bug fix for FSI ASoC: fsi: modify compile error ASoC: fsi-ak4642/fsi-da7210: modify dai link settings for card detect 2nd patch is quick hack for now. I will modify it more wisely in future. but no idea now Best regards -- Kuninori Morimoto

3 6

[alsa-devel] [PATCH] ASoC: Swap bias level enumeration
by Jarkko Nikula 31 Aug '10

31 Aug '10

Swapping the bias level enumeration is only meant to help debugging. It is easier if number 0 means bias off and bigger number means bigger bias level. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- include/sound/soc.h | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index d31e8b7..493b3a4 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -214,10 +214,10 @@ * @OFF: Power Off. No restrictions on transition times. */ enum snd_soc_bias_level { - SND_SOC_BIAS_ON, - SND_SOC_BIAS_PREPARE, - SND_SOC_BIAS_STANDBY, SND_SOC_BIAS_OFF, + SND_SOC_BIAS_STANDBY, + SND_SOC_BIAS_PREPARE, + SND_SOC_BIAS_ON, }; struct snd_jack; -- 1.7.1

3 2

[alsa-devel] Re-2: [PATCH 2/6] ASoC: ad1980: fix names of a few kcontrols
by marcus.weigelt＠fwd-online.de 31 Aug '10

31 Aug '10

Subject: Re: [alsa-devel] [PATCH 2/6] ASoC: ad1980: fix names of a few kcontrols (27-Aug-2010 20:32) From: Mark Brown <broonie(a)opensource.wolfsonmicro.com> To: marcus.weigelt(a)fwd-online.de > On Tue, Aug 24, 2010 at 03:09:40PM +0200, Uwe Kleine-K??nig wrote: > > From: Marcus Weigelt <marcus.weigelt(a)fwd-online.de> > > > > The names used before keep alsamixer from showing the appropriate > > controls for the AD1980. Mic and phone volume controls were shown in > > alsamixers' capture tab where they don??t belong to. Phone playback > > It's not massively obvious that microphone and phone aren't inputs and > therefore don't sensibly appear in the capture tab? The volume controls for mic and phone are actually hw mixing volumes that do not affect the recording path, therefore only the record selector belongs to capture tab, but not the volume control. > > > volume did not appear in playback tab and the microphone playback could > > never be unmuted. Further it was not possible to select phone as > > capture source. Changing the names fixes these problems. > > This doesn't sound real - misnamed controls might cause UI problems but > you'd have to try *really* hard to make the control name completely > prevent the setting of the control. May sound unreal, but if you look at the specific changes I´ve done, you will notice that I just added "Playback" to the mic volume and mic switch and changed "Phone Capture" to "Phone Playback". From the ALSA amixer.c I know, that there is some string compare on "playback" and "capture", don´t know if it is the same with the alsamixer, but this would explain the different behaviour after changing the names. I can see the result here - the controls are in the right place now and they are doing what they were supposed to. > > What is the actual problem that is is being fixed here? - microphone playback could not be unmuted before, that means that the hw mixing path from mic in to spk out/line out could never work - fixed by this - microphone volume was shown twice in "All" tab of Alsamixer, but running synchroniously, if you change one, the other will follow with the same value - fixed by this - if microphone voulme was changed in capture tab, the volume also changed in playback tab - fixed by this - microphone was never shown as active capture source, even if it was selected correctly, neither in capture tab nor in all-tab - fixed by this - phone was shown as selected capture source in capture tab, but actually it was not selected, instead it was muted/unmuted everytime one tries to select it as capture source - fixed by this > > > Signed-off-by: Marcus Weigelt <marcus.weigelt(a)fwd-online.de> > > Signed-off-by: Uwe Kleine-K??nig <u.kleine-koenig(a)pengutronix.de> > > Please remember to CC maintaintainers on patches. > > > --- > > sound/soc/codecs/ad1980.c | 8 ++++---- > > 1 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/sound/soc/codecs/ad1980.c b/sound/soc/codecs/ad1980.c > > index 35c0580..c1550b8 100644 > > --- a/sound/soc/codecs/ad1980.c > > +++ b/sound/soc/codecs/ad1980.c > > SOC_SINGLE("PCM Capture Switch", AC97_REC_GAIN, 15, 1, > > 1), > > SOC_SINGLE("Mono Playback Volume", AC97_MASTER_MONO, 0, 31, 1), > > SOC_SINGLE("Mono Playback Switch", AC97_MASTER_MONO, 15, 1, 1), > > > > -SOC_SINGLE("Phone Capture Volume", AC97_PHONE, 0, 31, 1), > > -SOC_SINGLE("Phone Capture Switch", AC97_PHONE, 15, 1, 1), > > +SOC_SINGLE("Phone Playback Volume", AC97_PHONE, 0, 31, 1), > > +SOC_SINGLE("Phone Playback Switch", AC97_PHONE, 15, 1, 1), > > > > -SOC_SINGLE("Mic Volume", AC97_MIC, 0, 31, 1), > > -SOC_SINGLE("Mic Switch", AC97_MIC, 15, 1, 1), > > +SOC_SINGLE("Mic Playback Volume", AC97_MIC, 0, 31, 1), > > +SOC_SINGLE("Mic Playback Switch", AC97_MIC, 15, 1, 1), > > > > SOC_SINGLE("Stereo Mic Switch", AC97_AD_MISC, 6, 1, 0), > > SOC_DOUBLE("Line HP Swap Switch", AC97_AD_MISC, 10, 5, 1, 0), > > -- > > 1.7.1 > > > > _______________________________________________ > > Alsa-devel mailing list > > Alsa-devel(a)alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > -- > "You grabbed my hand and we fell into it, like a daydream - or a fever." To: broonie(a)opensource.wolfsonmicro.com u.kleine-koenig(a)pengutronix.de Cc: alsa-devel(a)alsa-project.org sonic.zhang(a)analog.com lrg(a)slimlogic.co.uk

2 1

[alsa-devel] [PATCH 0/2] ASoC: Add iPAQ RX1950 sound support
by Vasily Khoruzhick 31 Aug '10

31 Aug '10

These two 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.

2 17

[alsa-devel] [PATCH 0/7] WM8580 updates
by Mark Brown 31 Aug '10

31 Aug '10

This batch of patches should get the sample ratio selection for the WM8580 based on the configured sysclk correct, and also fixes a few random other things. The configuration of the ADC clocking (which is slaved to the DAC clocking) is still not ideal - userspace has to configure playback at the sample rate to be used prior to starting a record - but this needs some more thought at the framework level since this is essentially the same problem we have when multiple DAIs run over one physical interface using TDM. Ideally we'd solve the more general problem. Mark Brown (7): ASoC: Add a bit of resource unwinding in the S3C IISv4 driver ASoC: Convert WM8580 hw_params to use snd_soc_update_bits() ASoC: Remove unused rate selection bitmasks from WM8580 ASoC: Automatically calculate clock ratio for WM8580 ASoC: Implement BCLK rate selection for WM8580 ASoC: Fix inverted WM8580 capture mute control ASoC: Automatically manage WM8580 DAC OSR sound/soc/codecs/wm8580.c | 144 +++++++++++++++++++++++++--------- sound/soc/codecs/wm8580.h | 14 ++-- sound/soc/s3c24xx/s3c64xx-i2s-v4.c | 11 +++ sound/soc/s3c24xx/smdk64xx_wm8580.c | 9 +- 4 files changed, 128 insertions(+), 50 deletions(-)

4 29

[alsa-devel] alsa-linux 2.4
by asim khan 31 Aug '10

31 Aug '10

Hello Iam using kernel 2.6.24 and trying run an ALSA capture application on arm11 board this application when tries to open the device snd_pcm_open (&capture_handle, "plughw:1,0", SND_PCM_STREAM_CAPTURE, 0)) < 0)...it gives an error ALSA lib pcm_hw.c:1399 _snd_pcm_hw_open) Invalid value for card I have also tried using device "hw:1,0" plughw:0,1...but it didnt help. I get same error then i checked /dev directory so there it has not created /dev/snd directory but I can see /dev/dsp0 dsp1,dsp2....which seems its not using ALSA as it has not created /dev/snd so I manually created the /dev/snd and the devices like /dev/snd/pcmC0D0p and /dev/snd/controlC0. with major and minor number as on x86 machine.same application is running well on x86 can anyone please help me in this that what could be the problem as soon as possible..and what is solution for it....Thanks in advance --Regards Asim

1 0

[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