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

Re: [alsa-devel] Status of the Tascam US-122mkII???
by Daniel Mack 19 Jun '10

19 Jun '10

(please don't remove any addresses from Cc:) On Sat, Jun 19, 2010 at 01:58:02PM -0400, jordan johnston wrote: > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 1 > bNumEndpoints 4 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 I just wanted to know whether they switched to class compliance interfaces, but as you can see here, that's not the case. > you will notice it is using usb 1.1 (i unbinded the usb2, as i am told > it doesn't work with it) How did you do this? And you modified the driver to match this device ID, right? > usb 4-1: new full speed USB device using uhci_hcd and address 3 > usb 4-1: New USB device found, idVendor=0644, idProduct=8021 > usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 4-1: Product: US-122 MKII > usb 4-1: Manufacturer: TASCAM > usb 4-1: SerialNumber: no serial number > ALSA sound/usb/usx2y/usb_stream.c:603: status=-2 > ALSA sound/usb/usx2y/usb_stream.c:603: status=-2 > ALSA sound/usb/usx2y/us122l.c:365: us122l_start error -14 > snd-usb-us122l: probe of 4-1:1.1 failed with error -22 > usbcore: registered new interface driver snd-usb-us122l Sorry, I can't help here. Maybe Karsten, die author of this driver, has any clue (put to Cc: now). Otherwise, you would need to trace the USB traffic using TASCAM's driver for Windows or MacOSX, and then reverse-engineer the protocol ... HTH, Daniel

1 0

[alsa-devel] Status of the Tascam US-122mkII???
by jordan johnston 19 Jun '10

19 Jun '10

hello, Recently, i have gotten my hands on a Tascam US-122mkII. i have done a lot of reading/googling and i can see that the device has been added to the snd-usb-us122l and even-cross referenced my own device to make sure the Id and such were there. Currently, i am unable to get sound out of the Unit. it does however, power up on boot. I have tried many things to get it working, and i have even gotten Jack to give me the option of picking this Device, however it shows errors and does not work :( **** I am curious about the status of these drivers?? **** does anyone have this unit working at all? **** and the steps they used to get it working. ( as much of the info i have read doesn't seem quite uptodate ) is there possibly firmware for this unit or do i use the -US122L firmware instead? for Just a bit of background, I am using Fedora 12 with Planet CCRMA. however, i do not using the CCRMA kernel, as it doesn't cut it for me. A: it doesn't support a lot of newer hardware, B: it doesn't use MSI-X on my machine(shared USB/soundcard) C: It's bloated... D: no BFS scheduler. Instead i am using Zen-kernel which tends to be a lot more up to date, and i have gotten much better performance from Zen than any other kernel on any distro i have ever used. now, I am more than willing to provide any information that might help.... this is what i know so far. dmesg: ALSA sound/usb/usx2y/usb_stream.c:603: status=-2 ALSA sound/usb/usx2y/usb_stream.c:603: status=-2 ALSA sound/usb/usx2y/us122l.c:365: us122l_start error -14 snd-usb-us122l: probe of 1-5:1.1 failed with error -22 i have tried googling these messages to no avail. i poked around through the driver, i've tried some of the trouble-shooting tips provided by the guy who originally got the older models to work, removing echi-hcd, or unbinding it, unplugging it, etc. but nothing seems to be making a difference. Then my thought was that i need a proper asound.conf or .asoundrc. because the soundcard seems to be available, when i unbind it and unplug/plug the unit back in. i even tried removing them to see if on reboot, that they might be reconfigured, but no luck. if anyone can provide help, that would be greatly appreciated. I have a 30-day return, so if i can't figure it out, i will be returning it for a FFADO approved/fully-supported device. however that being said, wouldn't it be nice to still take the opportunity to have this device better supported or help debug some issues?? while i am not a really good programmer, i think i could be useful, as i have this device in front of me and can provide useful information to developers, just let me know what you need! Jordan

2 1

[alsa-devel] Bug in alsa-lib or alsamixer and amixer
by Raymond Yau 19 Jun '10

19 Jun '10

2010/6/16 Colin Guthrie <gmane(a)colin.guthr.ie> > 'Twas brillig, and Raymond Yau at 15/06/10 00:43 did gyre and gimble: > > +12dB(400%) is even larger than the software gain 150% of PA > > Software gain of PA 150% = ~+11dB, so not as different as you imply. > > I've explained the cubic mapping already, so please don't use arbitrary, > differently calculated percentages when comparing things. It's like > comparing apples to oranges. > > Col > > When I changed the volume slider of the gnome sound applet ( select perference ) in Fedora 13 to maximum (i.e. PA 150% ) Seem to be bug in amixer and alsamixer alsamixer also change to 150% but press any key change back to 100% The volume range is only from 0 to 65536 why did alsa-lib allow alsa-pulse plugin to set it outside the range , alsamixer and amixer also display 150% ? amixer -D pulse Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 98304 [150%] [on] Front Right: Playback 98304 [150%] [on]

3 10

[alsa-devel] Update on TLV320AIC3204 Driver
by Stuart Longland 19 Jun '10

19 Jun '10

Hi all, I've managed to get significantly further along with a driver for the TLV320AIC3204, to the point now that I'm starting to look at further things to tidy up for its inclusion into the kernel. Some issues I've faced however: (1) When using the SOC_DOUBLE_R_SX_TLV controls, I notice there's an odd interaction between the mute switch associated with the control, and its corresponding gain setting. Nothing changes in the actual registers (except the mute bit of course) but the displayed gain shoots up to infinity if the mute is toggled when the gain associated with that mute control is set below 0dB. When the gain is at 0dB or above, toggling the mute has no effect on the displayed gain setting. Has anyone noticed this before and what would be the cause? For reference; the controls are defined in lines 395..414 of tlv320aic3204.c. (2) On the TLV320AIC3204, the clocks used on the audio bus can either be sourced from the ADC clocks, or the DAC clocks. Naturally, before you see any clocks on the bus, you must first power up either the DAC or ADC (or both), and choose the appropriate source. I do this currently in the hw_params callback (right where I *used* to power up the DACs/ADCs, DAPM does this now). The issue I see, is what happens when a playback stream starts, followed later by a recording stream. All will be fine until the recording stream stops -- if the playback is still going, I fear the clocks will get shut off with the DAC, and the recording will come to a grinding halt. Duplex will be okay since both recording and playback are synchronised events in this case... but I can see the potential for this alternate case causing problems. Therefore, I ask: Is there a way to control this via DAPM, so that, when the component supplying the bit clocks is shut down, the serial interface clock source is switched automatically to the alternate source? (i.e. if DAC is shut down, switch to using the ADC clocks) For reference; the switching presently occurs in lines 917..924 of tlv320aic3204.c. (3) The sysfs interface of my driver still remains. I had a look at using the ASoC debugfs interface, however there are a *lot* of registers on the 'AIC3204 in a sparse memory map. When I try to inspect the registers via /sys/kernel/debug/asoc/tlv320aic3204.0-0018/codec_reg ... I notice there are more registers in the device than are accessible via this interface: karo ~ # tail /sys/kernel/debug/asoc/tlv320aic3204.0-0018/codec_reg tlv320aic3204-i2c 0-0018: aic3204_write: pg 0 reg 0[0000] <= 01 tlv320aic3204-i2c 0-0018: aic3204_write: pg 0 reg 0[0000] <= 02 tlv320aic3204-i2c 0-0018: aic3204_write: pg 0 reg 0[0000] <= 03 tlv320aic3204-i2c 0-0018: aic3204_write: pg 0 reg 0[0000] <= 00 tlv320aic3204-i2c 0-0018: aic3204_write: pg 0 reg 0[0000] <= 01 tlv320aic3204-i2c 0-0018: aic3204_write: pg 0 reg 0[0000] <= 02 tlv320aic3204-i2c 0-0018: aic3204_write: pg 0 reg 0[0000] <= 03 1a7: 0 1a8: 0 1a9: 0 1aa: 0 1ab: 0 1ac: 0 1ad: 0 1ae: 0 1af: 0 1b0: karo ~ # Notice it stops at 0x01b0 (corresponding to page 3, register 48), with an incomplete line. There were more registers, than there was buffer space to write the file. Is there a way to increase this buffer? Or alternatively, should I perhaps port my sysfs interface to debugfs, and modify it to augment the existing debugfs interface? The driver is still using the registration model that was used in kernel 2.6.34. I've managed to backport the ALSA tree to 2.6.28 for our project (since that's what's officially supported by Ka-Ro) and so far, it's working, although things are still quite crude. Since my last contact I've managed to figure out some aspects of DAPM, for instance the DACs and ADCs are powered up and down by DAPM, whereas I used to do this when setting the PLL manually. I cache more of the registers now, I tried doing something "clever" and skipping the pages of registers that aren't used and trying to cache just the pages that were meaningful, but I noticed that the rest of ALSA more or less assumed the register address used with cache was the real address. Digging around on the mailing list about how to handle a sparse register map lead me to the solution of just biting the bullet and caching all 80-odd pages. Wasteful on memory, but I won't miss anything. The driver still has an initialisation script facility, whereby custom register settings can be made at init. I'm still undecided as to whether to keep this or not... it's not the "done thing", but if I leave it there, it allows for custom adaptive filtering coefficients and other parameters to be set by the machine driver, which may be useful in some applications. Is it worth cleaning this up, or should it be ditched before the driver is submitted for inclusion? The driver is accessible online at <http://www.longlandclan.yi.org/~stuartl/asoc/> along with some comments about how to add it to your kernel sources. I'd appreciate any feedback or advice on how the driver can be improved. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere.

4 21

Re: [alsa-devel] [PATCH] ASoC: Add new TI TLV320AIC3204 CODEC driver
by Liam Girdwood 19 Jun '10

19 Jun '10

On Fri, 2010-06-18 at 13:57 +1000, Stuart Longland wrote: > The TLV320AIC3204 is a low-power stereo audio CODEC capable of sample > rates of up to 192kHz. This driver implements basic functionality, > using I²C for the control channel. > > The audio interface supports many data bus formats, including I²S > master/slave, DSP, left/right justified and TDM. > > What works: > - Playback at various bitrates up to 96kHz > - Recording at various bitrates up to 96kHz > - Mixer interface > - PLL generation of CODEC clocks from MCLK > > What could work better: > - DAPM > > What isn't tested: > - Audio interfaces other than I²S > - PLL with clocks other than ~12MHz > - Mono recording/playback > - 192kHz recording/playback > > What isn't implemented: > - SPI interface support > - PLL without fractional divider (would allow <10MHz clocks) > - Clock sources other than MCLK > - Adaptive filtering > - AGC > - Headset detection, JACK framework > > Signed-off-by: Stuart Longland <redhatter(a)gentoo.org> Just had a quick check and the register caching needs addressed. I agree with your comments, I don't think we really want to cache all 16K of codec registers here as we will probably only ever use a handful of them. I think a smaller lookup table containing only the registers that we care about will do. Fwiw, a generic ASoC lookup table would be best as this could be used by other codecs with large register maps too. The table should be ordered (for quick lookup) and also contain a readable/writeable/volatile flag for each register. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk

3 4

[alsa-devel] Alsa 1.0.23 problems with VIA VT1708S
by William King 19 Jun '10

19 Jun '10

A few different issues with this system, but for devel and debugging I have 3 laptops of the exact same hardware. Asus k50AB laptops with the VIA VT1708S sound card. I am documenting as best as I can on this ubuntu bug ticket: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/595606 Currently the issues are: 1. Front mic does not work. No audio with any tests, even arecord test. 2. headphone jack does not work. When headphones are plugged in, the sound continues to come out of the speakers, and no sound out of the headphones. I am able to test patches easily. I have just installed from source 1.0.23 release.

1 0

Re: [alsa-devel] [Alsa-user] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
by Giuliano Pochini 18 Jun '10

18 Jun '10

On Thu, 17 Jun 2010 08:11:06 -0400 "F. Heitkamp" <heitkamp(a)ameritech.net> wrote: > >> My goal is to be able to plug in a MIDI keyboard, or USB guitar > >> interface and play along with songs etc. > >> > >> I plugged in a MIDI keyboard, "/proc/asound/cards" showed the keyboard > >> was recognized. The keyboard has a USB and MIDI interface. > >> I am not sure if they both work at the same time. I had the MIDI cable > >> plugged into the Gina3G, but I could not tell if the keyboard was > >> recognized. > >> I compiled csound5. When I engaged it the system immediately froze and > >> started spitting out: > >> [...] > > Ok, I compiled csound, but I don't know how to use it. How can I reproduce > > the problem ? > > > Sorry I took so long to get back to you. > It turns out Csound is not related to the problem. > > In this case I am only using kernel 2.6.33.5-rt23-amd64, alsa lib 1.0.2, > but 2.6.34 does it too. > I bring up firefox. Web pages attempt to play sound. The kernel > begans doing: > > [ 2879.766331] allocate_pipes: ch=1 int=2 > [ 2879.766332] allocate_pipes: channel already open > [ 2879.766333] allocate_pipes(1) err=-11 > [ 2879.766334] pcm_hw_freed > [ 2.821190] pcm_analog_out_open cs=0 oc=2 r=44100 > [ 2879.821266] allocate_pipes: ch=1 int=2 > [ 2879.821267] allocate_pipes: channel already open > > ,infinitely. The system is unusable at this point and I have to > Alt-SysRq-k to get back in. > > Let me know what other information to provide. Perhaps is it related with the OSS emulation ? Do you know if the browser plays the sound itself or if it is using an external program or plugin ? -- Giuliano.

1 0

[alsa-devel] Cannot find
by subapriya sakthivel 18 Jun '10

18 Jun '10

Hay guys, I have download eclair branch code using below commands. repo init -u git://android.git.kernel.org/platform/manifest.git -b eclair repo sync But inside Hardware folder, i cannot find alsa_sound folder. Can anyone help me on this? Am i chekout from correct branch? If so, where can i get this folder. Thanks for your help in advance. -Priya

3 2

[PATCH] soc/imx: clean Kconfig
by Eric Bénard 18 Jun '10

18 Jun '10

Signed-off-by: Eric Bénard <eric(a)eukrea.com> --- sound/soc/imx/Kconfig | 10 ++-------- 1 files changed, 2 insertions(+), 8 deletions(-) diff --git a/sound/soc/imx/Kconfig b/sound/soc/imx/Kconfig index 6ef57e0..35e6cf6 100644 --- a/sound/soc/imx/Kconfig +++ b/sound/soc/imx/Kconfig @@ -8,22 +8,17 @@ config SND_IMX_SOC Say Y or M if you want to add support for codecs attached to the i.MX SSI interface. -config SND_MXC_SOC_SSI - tristate - config SND_MXC_SOC_WM1133_EV1 tristate "Audio on the the i.MX31ADS with WM1133-EV1 fitted" depends on SND_IMX_SOC && MACH_MX31ADS_WM1133_EV1 && EXPERIMENTAL select SND_SOC_WM8350 - select SND_MXC_SOC_SSI help Enable support for audio on the i.MX31ADS with the WM1133-EV1 PMIC board with WM8835x fitted. config SND_SOC_PHYCORE_AC97 tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards" - depends on MACH_PCM043 || MACH_PCA100 - select SND_MXC_SOC_SSI + depends on SND_IMX_SOC && (MACH_PCM043 || MACH_PCA100) select SND_SOC_WM9712 help Say Y if you want to add support for SoC audio on Phytec phyCORE @@ -31,8 +26,7 @@ config SND_SOC_PHYCORE_AC97 config SND_SOC_EUKREA_TLV320 bool "Eukrea TLV320" - depends on MACH_EUKREA_MBIMX27_BASEBOARD || MACH_EUKREA_MBIMXSD_BASEBOARD - select SND_IMX_SOC + depends on SND_IMX_SOC && (MACH_EUKREA_MBIMX27_BASEBOARD || MACH_EUKREA_MBIMXSD_BASEBOARD) select SND_SOC_TLV320AIC23 help Enable I2S based access to the TLV320AIC23B codec attached -- 1.6.3.3 --------------020001010209060103040907--

1 0

Re: [alsa-devel] Contents of Alsa-devel digest...
by Junhwa Rhee 18 Jun '10

18 Jun '10

On Jun 18, 2010, at 11:38 AM, alsa-devel-request(a)alsa-project.org wrote: > Send Alsa-devel mailing list submissions to > alsa-devel(a)alsa-project.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > or, via email, send a message with subject or body 'help' to > alsa-devel-request(a)alsa-project.org > > You can reach the person managing the list at > alsa-devel-owner(a)alsa-project.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Alsa-devel digest..." > > > Today's Topics: > > 1. Re: [PATCH 2/5] ALSA: usb-audio: unify UAC macros and struct > names (Daniel Mack) > 2. Re: Timing Info (Clemens Ladisch) > 3. Re: [PATCH] ASoC: pandora: fix CLKX polarity (Mark Brown) > 4. [PATCH] ALSA: hda - add ideapad model for Conexant 5051 codec > (Herton Ronaldo Krzesinski) > 5. Re: [PATCH] ALSA: hda - add ideapad model for Conexant 5051 > codec (Takashi Iwai) > 6. Re: snd_mixer_selem_get_playback_volume return value outside > allowed range (Raymond Yau) > 7. Re: [PATCH] eukrea-tlv320: add support for our i.MX25 board > (Mark Brown) > 8. SOC_DOUBLE_R_SX_TLV (was Update on TLV320AIC3204 Driver) > (Stuart Longland) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 Jun 2010 17:26:26 +0200 > From: Daniel Mack <daniel(a)caiaq.de> > Subject: Re: [alsa-devel] [PATCH 2/5] ALSA: usb-audio: unify UAC > macros and struct names > To: Alex Lee <alexlee188(a)gmail.com> > Cc: Takashi Iwai <tiwai(a)suse.de>, "alsa-devel(a)alsa-project.org" > <alsa-devel(a)alsa-project.org>, "clemens(a)ladisch.de" > <clemens(a)ladisch.de> > Message-ID: <20100617152626.GL17833(a)buzzloop.caiaq.de> > Content-Type: text/plain; charset=us-ascii > > (hint, hint: don't top-post :)) > > On Thu, Jun 17, 2010 at 08:21:22AM -0700, Alex Lee wrote: >> It will not help existing codes, I agree. But it may make writing new UAC2 >> specific code easier? > > Not as long as most of the code stays hybrid for both versions. If there > were versions of these enum values for both UAC1 and UAC2, you would > need to choose one of them in the parser codes. Which one you go for > doesn't actually make any difference as they're both the same, but the > code would read as if it was specific to any version. > > I'd say this would add more to the confusion, and not ease any. > > > Daniel > > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Jun 2010 17:36:59 +0200 > From: Clemens Ladisch <clemens(a)ladisch.de> > Subject: Re: [alsa-devel] Timing Info > To: Paul Dugas <paul(a)dugasenterprises.com> > Cc: alsa-devel(a)alsa-project.org > Message-ID: <4C1A411B.2060301(a)ladisch.de> > Content-Type: text/plain; charset=us-ascii > > Paul Dugas wrote: >> On Sun, Jun 13, 2010 at 10:10 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote: >>> Set SND_PCM_TSTAMP_ENABLE to generate a timestamp whenever the hardware >>> position is updated. Call snd_pcm_status to read the position and the >>> corresponding timestamp. >> >> I've re-read this a number of times and have been fiddling with code >> that dumps the status at various points but I'm still not grasping the >> concept here. Can comeone point me to an explanation of the delay, >> avail, and avail_max values? > > The avail value tells you how many frames are available, i.e., can be > written, in the output buffer. The largest value that this had since > the last snd_pcm_status call is avail_max. > > The delay value is the time that will elapse before the next frame that > you write into the buffer will actually be output by the hardware. This > is not only the time until the hardware reads this frame out of the > buffer (which could be computed from avail) but also any processing > after that. > > > HTH > Clemens > > > ------------------------------ > > Message: 3 > Date: Thu, 17 Jun 2010 16:50:01 +0100 > From: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > Subject: Re: [alsa-devel] [PATCH] ASoC: pandora: fix CLKX polarity > To: Grazvydas Ignotas <notasas(a)gmail.com>, alsa-devel(a)alsa-project.org > Cc: lrg(a)slimlogic.co.uk > Message-ID: <u6g5khs6pbrq63fngu2ncjvv.1276789801383(a)email.android.com> > Content-Type: text/plain; charset=utf-8 > > Acked-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > > Probably best to add a CC to stable too. Sorry about the rubbish formatting, on my phone and it can't do any better. > > Grazvydas Ignotas <notasas(a)gmail.com> wrote: > >> After mass production started it was found that several boards exhibit >> noise problems during sound playback. After some investigation it was >> determined that CLKX polarity is set incorrectly, and even if most boards >> can tolerate the wrong setting, there are some that don't. >> >> Fix polarity setup in the board file. As the clock settings for input and >> output now match, merge in and out functions and structures to simplify >> code. >> >> Signed-off-by: Grazvydas Ignotas <notasas(a)gmail.com> >> --- >> sound/soc/omap/omap3pandora.c | 36 ++++++++---------------------------- >> 1 files changed, 8 insertions(+), 28 deletions(-) >> >> diff --git a/sound/soc/omap/omap3pandora.c b/sound/soc/omap/omap3pandora.c >> index 87ce842..9eecac1 100644 >> --- a/sound/soc/omap/omap3pandora.c >> +++ b/sound/soc/omap/omap3pandora.c >> @@ -43,12 +43,14 @@ >> >> static struct regulator *omap3pandora_dac_reg; >> >> -static int omap3pandora_cmn_hw_params(struct snd_pcm_substream *substream, >> - struct snd_pcm_hw_params *params, unsigned int fmt) >> +static int omap3pandora_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 *codec_dai = rtd->dai->codec_dai; >> struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; >> + int fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | >> + SND_SOC_DAIFMT_CBS_CFS; >> int ret; >> >> /* Set codec DAI configuration */ >> @@ -91,24 +93,6 @@ static int omap3pandora_cmn_hw_params(struct snd_pcm_substream *substream, >> return 0; >> } >> >> -static int omap3pandora_out_hw_params(struct snd_pcm_substream *substream, >> - struct snd_pcm_hw_params *params) >> -{ >> - return omap3pandora_cmn_hw_params(substream, params, >> - SND_SOC_DAIFMT_I2S | >> - SND_SOC_DAIFMT_IB_NF | >> - SND_SOC_DAIFMT_CBS_CFS); >> -} >> - >> -static int omap3pandora_in_hw_params(struct snd_pcm_substream *substream, >> - struct snd_pcm_hw_params *params) >> -{ >> - return omap3pandora_cmn_hw_params(substream, params, >> - SND_SOC_DAIFMT_I2S | >> - SND_SOC_DAIFMT_NB_NF | >> - SND_SOC_DAIFMT_CBS_CFS); >> -} >> - >> static int omap3pandora_dac_event(struct snd_soc_dapm_widget *w, >> struct snd_kcontrol *k, int event) >> { >> @@ -231,12 +215,8 @@ static int omap3pandora_in_init(struct snd_soc_codec *codec) >> return snd_soc_dapm_sync(codec); >> } >> >> -static struct snd_soc_ops omap3pandora_out_ops = { >> - .hw_params = omap3pandora_out_hw_params, >> -}; >> - >> -static struct snd_soc_ops omap3pandora_in_ops = { >> - .hw_params = omap3pandora_in_hw_params, >> +static struct snd_soc_ops omap3pandora_ops = { >> + .hw_params = omap3pandora_hw_params, >> }; >> >> /* Digital audio interface glue - connects codec <--> CPU */ >> @@ -246,14 +226,14 @@ static struct snd_soc_dai_link omap3pandora_dai[] = { >> .stream_name = "HiFi Out", >> .cpu_dai = &omap_mcbsp_dai[0], >> .codec_dai = &twl4030_dai[TWL4030_DAI_HIFI], >> - .ops = &omap3pandora_out_ops, >> + .ops = &omap3pandora_ops, >> .init = omap3pandora_out_init, >> }, { >> .name = "TWL4030", >> .stream_name = "Line/Mic In", >> .cpu_dai = &omap_mcbsp_dai[1], >> .codec_dai = &twl4030_dai[TWL4030_DAI_HIFI], >> - .ops = &omap3pandora_in_ops, >> + .ops = &omap3pandora_ops, >> .init = omap3pandora_in_init, >> } >> }; >> -- >> 1.6.3.3 >> > > ------------------------------ > > Message: 4 > Date: Thu, 17 Jun 2010 14:15:06 -0300 > From: Herton Ronaldo Krzesinski <herton(a)mandriva.com.br> > Subject: [alsa-devel] [PATCH] ALSA: hda - add ideapad model for > Conexant 5051 codec > To: alsa-devel(a)alsa-project.org > Cc: Takashi Iwai <tiwai(a)suse.de> > Message-ID: <201006171415.07101.herton(a)mandriva.com.br> > Content-Type: Text/Plain; charset="us-ascii" > > Lenovo IdeaPad Y430 has an additional subwoofer connected at pin 0x1b, > which isn't muted when headphone is plugged in. This adds additional > support to the extra subwoofer via new ideapad model. > > Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com.br> > --- > Documentation/sound/alsa/HD-Audio-Models.txt | 1 + > sound/pci/hda/patch_conexant.c | 20 ++++++++++++++++++++ > 2 files changed, 21 insertions(+), 0 deletions(-) > > diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt > b/Documentation/sound/alsa/HD-Audio-Models.txt > index 1d38b0d..84e81ad 100644 > --- a/Documentation/sound/alsa/HD-Audio-Models.txt > +++ b/Documentation/sound/alsa/HD-Audio-Models.txt > @@ -282,6 +282,7 @@ Conexant 5051 > hp HP Spartan laptop > hp-dv6736 HP dv6736 > hp-f700 HP Compaq Presario F700 > + ideapad Lenovo IdeaPad laptop > lenovo-x200 Lenovo X200 laptop > toshiba Toshiba Satellite M300 > > diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c > index 2bf2cb5..54f7419 100644 > --- a/sound/pci/hda/patch_conexant.c > +++ b/sound/pci/hda/patch_conexant.c > @@ -1632,6 +1632,11 @@ static void cxt5051_update_speaker(struct hda_codec > *codec) > pinctl = (!spec->hp_present && spec->cur_eapd) ? PIN_OUT : 0; > snd_hda_codec_write(codec, 0x1a, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, > pinctl); > + /* on ideapad there is an aditional speaker (subwoofer) to mute */ > + if (spec->ideapad) > + snd_hda_codec_write(codec, 0x1b, 0, > + AC_VERB_SET_PIN_WIDGET_CONTROL, > + pinctl); > } > > /* turn on/off EAPD (+ mute HP) as a master switch */ > @@ -1888,6 +1893,13 @@ static void cxt5051_init_mic_port(struct hda_codec > *codec, hda_nid_t nid, > #endif > } > > +static struct hda_verb cxt5051_ideapad_init_verbs[] = { > + /* Subwoofer */ > + {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, > + {0x1b, AC_VERB_SET_CONNECT_SEL, 0x00}, > + { } /* end */ > +}; > + > /* initialize jack-sensing, too */ > static int cxt5051_init(struct hda_codec *codec) > { > @@ -1917,6 +1929,7 @@ enum { > CXT5051_LENOVO_X200, /* Lenovo X200 laptop, also used for Advanced Mini > Dock 250410 */ > CXT5051_F700, /* HP Compaq Presario F700 */ > CXT5051_TOSHIBA, /* Toshiba M300 & co */ > + CXT5051_IDEAPAD, /* Lenovo IdeaPad Y430 */ > CXT5051_MODELS > }; > > @@ -1927,6 +1940,7 @@ static const char *cxt5051_models[CXT5051_MODELS] = { > [CXT5051_LENOVO_X200] = "lenovo-x200", > [CXT5051_F700] = "hp-700", > [CXT5051_TOSHIBA] = "toshiba", > + [CXT5051_IDEAPAD] = "ideapad", > }; > > static struct snd_pci_quirk cxt5051_cfg_tbl[] = { > @@ -1938,6 +1952,7 @@ static struct snd_pci_quirk cxt5051_cfg_tbl[] = { > CXT5051_LAPTOP), > SND_PCI_QUIRK(0x14f1, 0x5051, "HP Spartan 1.1", CXT5051_HP), > SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo X200", CXT5051_LENOVO_X200), > + SND_PCI_QUIRK(0x17aa, 0x3a0d, "Lenovo IdeaPad", CXT5051_IDEAPAD), > {} > }; > > @@ -1999,6 +2014,11 @@ static int patch_cxt5051(struct hda_codec *codec) > spec->mixers[0] = cxt5051_toshiba_mixers; > spec->auto_mic = AUTO_MIC_PORTB; > break; > + case CXT5051_IDEAPAD: > + spec->init_verbs[spec->num_init_verbs++] = > + cxt5051_ideapad_init_verbs; > + spec->ideapad = 1; > + break; > } > > return 0; > -- > 1.7.1 > > > > ------------------------------ > > Message: 5 > Date: Thu, 17 Jun 2010 20:39:20 +0200 > From: Takashi Iwai <tiwai(a)suse.de> > Subject: Re: [alsa-devel] [PATCH] ALSA: hda - add ideapad model for > Conexant 5051 codec > To: Herton Ronaldo Krzesinski <herton(a)mandriva.com.br> > Cc: alsa-devel(a)alsa-project.org > Message-ID: <s5hk4pxld0n.wl%tiwai(a)suse.de> > Content-Type: text/plain; charset=US-ASCII > > At Thu, 17 Jun 2010 14:15:06 -0300, > Herton Ronaldo Krzesinski wrote: >> >> Lenovo IdeaPad Y430 has an additional subwoofer connected at pin 0x1b, >> which isn't muted when headphone is plugged in. This adds additional >> support to the extra subwoofer via new ideapad model. >> >> Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com.br> > > Thanks, applied now. > > > Takashi > >> --- >> Documentation/sound/alsa/HD-Audio-Models.txt | 1 + >> sound/pci/hda/patch_conexant.c | 20 ++++++++++++++++++++ >> 2 files changed, 21 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt >> b/Documentation/sound/alsa/HD-Audio-Models.txt >> index 1d38b0d..84e81ad 100644 >> --- a/Documentation/sound/alsa/HD-Audio-Models.txt >> +++ b/Documentation/sound/alsa/HD-Audio-Models.txt >> @@ -282,6 +282,7 @@ Conexant 5051 >> hp HP Spartan laptop >> hp-dv6736 HP dv6736 >> hp-f700 HP Compaq Presario F700 >> + ideapad Lenovo IdeaPad laptop >> lenovo-x200 Lenovo X200 laptop >> toshiba Toshiba Satellite M300 >> >> diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c >> index 2bf2cb5..54f7419 100644 >> --- a/sound/pci/hda/patch_conexant.c >> +++ b/sound/pci/hda/patch_conexant.c >> @@ -1632,6 +1632,11 @@ static void cxt5051_update_speaker(struct hda_codec >> *codec) >> pinctl = (!spec->hp_present && spec->cur_eapd) ? PIN_OUT : 0; >> snd_hda_codec_write(codec, 0x1a, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, >> pinctl); >> + /* on ideapad there is an aditional speaker (subwoofer) to mute */ >> + if (spec->ideapad) >> + snd_hda_codec_write(codec, 0x1b, 0, >> + AC_VERB_SET_PIN_WIDGET_CONTROL, >> + pinctl); >> } >> >> /* turn on/off EAPD (+ mute HP) as a master switch */ >> @@ -1888,6 +1893,13 @@ static void cxt5051_init_mic_port(struct hda_codec >> *codec, hda_nid_t nid, >> #endif >> } >> >> +static struct hda_verb cxt5051_ideapad_init_verbs[] = { >> + /* Subwoofer */ >> + {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, >> + {0x1b, AC_VERB_SET_CONNECT_SEL, 0x00}, >> + { } /* end */ >> +}; >> + >> /* initialize jack-sensing, too */ >> static int cxt5051_init(struct hda_codec *codec) >> { >> @@ -1917,6 +1929,7 @@ enum { >> CXT5051_LENOVO_X200, /* Lenovo X200 laptop, also used for Advanced Mini >> Dock 250410 */ >> CXT5051_F700, /* HP Compaq Presario F700 */ >> CXT5051_TOSHIBA, /* Toshiba M300 & co */ >> + CXT5051_IDEAPAD, /* Lenovo IdeaPad Y430 */ >> CXT5051_MODELS >> }; >> >> @@ -1927,6 +1940,7 @@ static const char *cxt5051_models[CXT5051_MODELS] = { >> [CXT5051_LENOVO_X200] = "lenovo-x200", >> [CXT5051_F700] = "hp-700", >> [CXT5051_TOSHIBA] = "toshiba", >> + [CXT5051_IDEAPAD] = "ideapad", >> }; >> >> static struct snd_pci_quirk cxt5051_cfg_tbl[] = { >> @@ -1938,6 +1952,7 @@ static struct snd_pci_quirk cxt5051_cfg_tbl[] = { >> CXT5051_LAPTOP), >> SND_PCI_QUIRK(0x14f1, 0x5051, "HP Spartan 1.1", CXT5051_HP), >> SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo X200", CXT5051_LENOVO_X200), >> + SND_PCI_QUIRK(0x17aa, 0x3a0d, "Lenovo IdeaPad", CXT5051_IDEAPAD), >> {} >> }; >> >> @@ -1999,6 +2014,11 @@ static int patch_cxt5051(struct hda_codec *codec) >> spec->mixers[0] = cxt5051_toshiba_mixers; >> spec->auto_mic = AUTO_MIC_PORTB; >> break; >> + case CXT5051_IDEAPAD: >> + spec->init_verbs[spec->num_init_verbs++] = >> + cxt5051_ideapad_init_verbs; >> + spec->ideapad = 1; >> + break; >> } >> >> return 0; >> -- >> 1.7.1 >> > > > ------------------------------ > > Message: 6 > Date: Fri, 18 Jun 2010 07:39:07 +0800 > From: Raymond Yau <superquad.vortex2(a)gmail.com> > Subject: Re: [alsa-devel] snd_mixer_selem_get_playback_volume return > value outside allowed range > To: ALSA Development Mailing List <alsa-devel(a)alsa-project.org> > Message-ID: > <AANLkTin7y2JzkaCYb4p69uDfWOo4cTa85in0Q3l7RwbD(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 2010/6/17 Clemens Ladisch <clemens(a)ladisch.de> > >> Raymond Yau wrote: >>> Should snd_mixer_selem_get_playback_volume() perform range check ? >> >> No, it's the responsibility of the control implementation to return >> valid values (and to check that values that are being set are valid). >> >> >> Regards, >> Clemens >> > > If it is the responsibility of the driver/external plugin to keep the value > inside the allowed range > > your patch actually help those buggy driver/external plugin hide the bug > only > > > ------------------------------ > > Message: 7 > Date: Fri, 18 Jun 2010 01:56:37 +0100 > From: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > Subject: Re: [alsa-devel] [PATCH] eukrea-tlv320: add support for our > i.MX25 board > To: Eric B?nard <eric(a)eukrea.com> > Cc: alsa-devel(a)alsa-project.org, s.hauer(a)pengutronix.de, > lrg(a)slimlogic.co.uk > Message-ID: <20100618005637.GA3333(a)opensource.wolfsonmicro.com> > Content-Type: text/plain; charset=iso-8859-1 > > On Thu, Jun 17, 2010 at 03:44:01PM +0200, Eric B?nard wrote: >> * tdm slot has to be configured to get sound working on i.MX25 >> >> Signed-off-by: Eric B?nard <eric(a)eukrea.com> > > Applied but I had to hand apply the Kconfig update, please check that it > applied correctly. > > > ------------------------------ > > Message: 8 > Date: Fri, 18 Jun 2010 12:38:10 +1000 > From: Stuart Longland <redhatter(a)gentoo.org> > Subject: [alsa-devel] SOC_DOUBLE_R_SX_TLV (was Update on TLV320AIC3204 > Driver) > To: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > Cc: Takashi Iwai <tiwai(a)suse.de>, alsa-devel(a)alsa-project.org, Eric > B??nard <eric(a)eukrea.com>, Liam Girdwood <lrg(a)slimlogic.co.uk> > Message-ID: <20100618023810.GS7759(a)www.longlandclan.yi.org> > Content-Type: text/plain; charset=us-ascii > > On Tue, Jun 15, 2010 at 03:11:10PM +1000, Stuart Longland wrote: >> When a read is performed, this structure points to this function as the >> means for reading the register (defined in sound/soc-core.c): >> >> /** >> * snd_soc_get_volsw_2r_sx - double with tlv and variable data size >> * mixer get callback >> * @kcontrol: mixer control >> * @uinfo: control element information >> * >> * Returns 0 for success. >> */ >> int snd_soc_get_volsw_2r_sx(struct snd_kcontrol *kcontrol, >> struct snd_ctl_elem_value *ucontrol) >> { >> struct soc_mixer_control *mc = >> (struct soc_mixer_control *)kcontrol->private_value; >> struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); >> unsigned int mask = (1<<mc->shift)-1; >> int min = mc->min; >> int val = snd_soc_read(codec, mc->reg) & mask; >> int valr = snd_soc_read(codec, mc->rreg) & mask; >> >> ucontrol->value.integer.value[0] = ((val & 0xff)-min); >> ucontrol->value.integer.value[1] = ((valr & 0xff)-min); >> return 0; >> } >> EXPORT_SYMBOL_GPL(snd_soc_get_volsw_2r_sx); > > I've figured it out now... and there'll be a patch to fix it. > > The mute <--> gain interaction was pure coincidence as it turns out. > There's no interaction between the two, just that when I toggle the > mute, the gain gets re-read, and hence it *appeared* to interact. > > Notice the value calculated for the channel is: > > output = ( regval & 0xff ) - minimum > > In my case, my minimum is -6. Suppose I set my driver gain to -1dB, in > hexadecimal, 0x3f. Since no sign extension is done, (regval & 0xff) = > 63. Adding 6 to this (double negation) you get 69... which is greater > than the maximum gain of 29. Hence the scale shoots up to maximum. > > The fix, is to change the above so that they mask the result; thus > wrapping around the zero point like so: > > output = ( ( regval & 0xff ) - minimum ) & mask > > This fixes the problem that I observe, and shouldn't break the other > user of the control. A patch to fix this issue is coming. > -- > Stuart Longland (aka Redhatter, VK4MSL) .'''. > Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : > . . . . . . . . . . . . . . . . . . . . . . .'.' > http://dev.gentoo.org/~redhatter :.' > > I haven't lost my mind... > ...it's backed up on a tape somewhere. > > > ------------------------------ > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > End of Alsa-devel Digest, Vol 40, Issue 80 > ******************************************

1 0