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

[alsa-devel] [PATCH] ASoC: add AD1980 obsolete information
by Mike Frysinger 10 Aug '10

10 Aug '10

From: Sonic Zhang <sonic.zhang(a)analog.com> This codec has been obsoleted by ADI, so add appropriate warnings to the source tree to dissuade people from using in new designs based on driver support. Signed-off-by: Sonic Zhang <sonic.zhang(a)analog.com> Signed-off-by: Mike Frysinger <vapier(a)gentoo.org> --- sound/soc/blackfin/Kconfig | 7 ++++++- sound/soc/blackfin/bf5xx-ad1980.c | 10 +++++++++- sound/soc/codecs/ad1980.c | 10 +++++++++- sound/soc/codecs/ad1980.h | 6 ++++++ 4 files changed, 30 insertions(+), 3 deletions(-) diff --git a/sound/soc/blackfin/Kconfig b/sound/soc/blackfin/Kconfig index 75bbc90..b73ee38 100644 --- a/sound/soc/blackfin/Kconfig +++ b/sound/soc/blackfin/Kconfig @@ -113,13 +113,18 @@ config SND_BF5XX_RESET_GPIO_NUM Set the correct GPIO for RESET the sound chip. config SND_BF5XX_SOC_AD1980 - tristate "SoC AD1980/1 Audio support for BF5xx" + tristate "SoC AD1980/1 Audio support for BF5xx (Obsolete)" depends on SND_BF5XX_AC97 select SND_BF5XX_SOC_AC97 select SND_SOC_AD1980 help Say Y if you want to add support for SoC audio on BF5xx STAMP/EZKIT. + Warning: + Because Analog Devices Inc. discontinued the ad1980 sound chip since + Sep. 2009, this ad1980 driver is not maintained, tested and supported + by ADI now. + config SND_BF5XX_SOC_SPORT tristate diff --git a/sound/soc/blackfin/bf5xx-ad1980.c b/sound/soc/blackfin/bf5xx-ad1980.c index d8f5912..92f7c32 100644 --- a/sound/soc/blackfin/bf5xx-ad1980.c +++ b/sound/soc/blackfin/bf5xx-ad1980.c @@ -26,6 +26,14 @@ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* + * WARNING: + * + * Because Analog Devices Inc. discontinued the ad1980 sound chip since + * Sep. 2009, this ad1980 driver is not maintained, tested and supported + * by ADI now. + */ + #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/device.h> @@ -109,5 +117,5 @@ module_exit(bf5xx_board_exit); /* Module information */ MODULE_AUTHOR("Cliff Cai"); -MODULE_DESCRIPTION("ALSA SoC AD1980/1 BF5xx board"); +MODULE_DESCRIPTION("ALSA SoC AD1980/1 BF5xx board (Obsolete)"); MODULE_LICENSE("GPL"); diff --git a/sound/soc/codecs/ad1980.c b/sound/soc/codecs/ad1980.c index 0420727..70cfaec 100644 --- a/sound/soc/codecs/ad1980.c +++ b/sound/soc/codecs/ad1980.c @@ -11,6 +11,14 @@ * option) any later version. */ +/* + * WARNING: + * + * Because Analog Devices Inc. discontinued the ad1980 sound chip since + * Sep. 2009, this ad1980 driver is not maintained, tested and supported + * by ADI now. + */ + #include <linux/init.h> #include <linux/slab.h> #include <linux/module.h> @@ -298,6 +306,6 @@ struct snd_soc_codec_device soc_codec_dev_ad1980 = { }; EXPORT_SYMBOL_GPL(soc_codec_dev_ad1980); -MODULE_DESCRIPTION("ASoC ad1980 driver"); +MODULE_DESCRIPTION("ASoC ad1980 driver (Obsolete)"); MODULE_AUTHOR("Roy Huang, Cliff Cai"); MODULE_LICENSE("GPL"); diff --git a/sound/soc/codecs/ad1980.h b/sound/soc/codecs/ad1980.h index db6c850..538f37c 100644 --- a/sound/soc/codecs/ad1980.h +++ b/sound/soc/codecs/ad1980.h @@ -1,5 +1,11 @@ /* * ad1980.h -- ad1980 Soc Audio driver + * + * WARNING: + * + * Because Analog Devices Inc. discontinued the ad1980 sound chip since + * Sep. 2009, this ad1980 driver is not maintained, tested and supported + * by ADI now. */ #ifndef _AD1980_H -- 1.7.2

2 1

[alsa-devel] [PATCH] ASoC: register cache should be 1 byte aligned for 1 byte long register
by Mike Frysinger 10 Aug '10

10 Aug '10

From: Cliff Cai <cliff.cai(a)analog.com> Signed-off-by: Cliff Cai <cliff.cai(a)analog.com> Signed-off-by: Mike Frysinger <vapier(a)gentoo.org> --- sound/soc/soc-cache.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-cache.c b/sound/soc/soc-cache.c index 472af38..adbc68c 100644 --- a/sound/soc/soc-cache.c +++ b/sound/soc/soc-cache.c @@ -340,7 +340,7 @@ static unsigned int snd_soc_16_8_read_i2c(struct snd_soc_codec *codec, static unsigned int snd_soc_16_8_read(struct snd_soc_codec *codec, unsigned int reg) { - u16 *cache = codec->reg_cache; + u8 *cache = codec->reg_cache; reg &= 0xff; if (reg >= codec->reg_cache_size) @@ -351,7 +351,7 @@ static unsigned int snd_soc_16_8_read(struct snd_soc_codec *codec, static int snd_soc_16_8_write(struct snd_soc_codec *codec, unsigned int reg, unsigned int value) { - u16 *cache = codec->reg_cache; + u8 *cache = codec->reg_cache; u8 data[3]; int ret; -- 1.7.2

2 1

Re: [alsa-devel] [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards
by Niels Mayer 10 Aug '10

10 Aug '10

On Tue, Aug 10, 2010 at 1:14 AM, <fons(a)kokkinizita.net> wrote: > - The meters are there to show levels at the AD/DA converters, > i.e. to allow you to check you are using those in a sensible > way. They happen to be on the same window as the mixer, which > can be useful as they suggest to the user which signal is > being controlled by a fader. But otherwise they are not part > of the mixer, and a better place for them would be with the > HW gain controls. The meters show the levels at the A/D&D/A's but also at other things that don't necessarily end up being routed to the analog I/O. See the "Peak" labels on http://nielsmayer.com/envy24control/envy24mixer-architecture.png ... That's: * 10 channels of hardware peak-levels of inputs (including an SPDIF pair). * 10 channels of hardware peak-level outputs (including an SPDIF pair). * 2 channels for the digital mixer output. So in reality (assuming reality==documentation== http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf ) the peak meters are part of the mixer. However, the peak meter information is most useful in the "Analog Volume" panel, but that would miss four-six channels + spdif-pair of outputs. As a stopgap, I put the dBFS value alongside each channel, since adding the full meters to this panel was a much larger and more radical change than my initial patches. A better design overall, IMHO would be to combine all 20 input and output faders feeding the digital-summer into a single panel. Instead of two faders per channel, just one fader and a panpot, which would normally be swung hard-left or hard-right, but should also have a detent or page-position at center mix. The panpot would also indicate inactive and set at center-mix when "L/R Gang" is selected. Each channel would have the numeric dbFS input value displayed as a "button", which when selected, expands a meter that fills the column vertically; and deselected, it goes back to being a text display of the peak levels. That mechanism of dynamically adding a meter per channel could also be used in the "Analog Volumes" section to optionally allow meter info to be displayed alongside each slider. > - The post-fader signals in the mixer are not available anywhere, > they just get summed to the bus. They are "available" in that the output of the digital mixer is metered and that meter is always displayed in envy24control. If you want to see the resulting level of any particular channels' attenuation, "solo" it (by manually muting the other incoming channels) and observe the resulting levels under the "Digital Mixer" meters. (Actually, a "Channel Solo" option-menu would be a useful addition to the digital mixer GUI: "off", "solo left" "solo right" "solo center". -- Niels http://nielsmayer.com

1 0

Re: [alsa-devel] [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards
by Niels Mayer 10 Aug '10

10 Aug '10

On Mon, Aug 9, 2010 at 5:53 PM, Tim E. Real <termtech(a)rogers.com> wrote: > On August 9, 2010 08:45:49 pm Tim E. Real wrote: >> Hey hey hey! >> Look what I've got... >> I thought it important and complete enough to let you see >> where it is going. Just applied the patches, compiled... AWESOME! Sliders, dB scales and meters in "Monitor Inputs" and "Monitor PCMs" resize when the window is stretched! I'm looking forward to the completion of your TODO items in AUTHORS esp the digital mixer meter resizing with stretchy scales just like the mixer's channel meters. Let me know when you have things finalized, and I'll add a mudita24 1.04 version to http://nielsmayer.com/envy24control/ . Of course the new resizeability feature brings up the issue that the sliders can become long enough to display different positions for two sliders at the same attenuator dB value. Perhaps this could be remedied by an on-release callback that sets the slider back to the center of it's actual dbFS value, e.g. -1.5dB, -3.0, -4.5, -6.0 etc... This becomes especially noticeable on a stretched slider in "Monitor Inputs" or "Monitor PCMs" due to the 1.5dB steps provided by the 24bit attenuators feeding the digital mixer. It doesn't seem to be as noticeable with the 0.5dB steps in the "Analog Volumes" panel. However, on a fully-height-expanded window, you can notice, for example, two sliders of a stereo pair showing the same dB value but slightly different positions visually. One "regression" in your change: formerly, you could click within the scale/labeling area to set focus on a given slider. This is a large and easy-to-click area if you just want to set GUI focus to that particular channel and use the scroll-wheel or keyboard up/down arrows to change values). Because if you click in the slider area to set the selection, unless you click on the slider itself, the value gets changed. > One more thing: Because of my use of gtk_adjustment_get_page_increment() > and friends, which require gtk+ 2.14, I think it may be necessary to > release this as a separate program than envy24control. > There may be people out there with old setups who need the old one. > The ALSA folks may not like replacing the old one with mudita24 for > that reason. Seems like there should be a way for their build system to handle skipping programs that use gtk2 if only gtk1 available ... at least for the myriad packages in alsa-tools "Specialist tools for ALSA" -- which might also be a perfectly appropriate place to put a latest-gtk2-using tool providing special control to a specific set of cards. I haven't surveyed the other packages to see what kind of dependencies they have... I'm CC'ing to alsa-devel in hopes of getting an answer on this. (thread summary: http://linuxaudio.org/mailarchive/lad/2010/8/8/172623 http://linuxaudio.org/mailarchive/lad/2010/8/8/172629 ) Niels http://nielsmayer.com

1 0

[alsa-devel] amp power down event (resend with the correct email)
by Michael Trimarchi 10 Aug '10

10 Aug '10

Hi all, I'm t rying to unde rstand when the event a re called. ... SND_SOC_DAPM_SPK("Front Speaker", amp_event), ... My idea was: - set the mixe r - open st ream amp_event: event => [ 169.820558] ON - close st ream and receive the event => OFF. In the aplay example this happen afte r some seconds but in my application I don't receive the OFF event. What is w rong? Michael

3 8

[alsa-devel] Minivosc entry on Wiki - discuss
by Smilen Dimitrov 10 Aug '10

10 Aug '10

Hi ALSA-devel, Since I found programming ALSA drivers - and understanding device drivers in general - quite overwhelming, I had posted my starting steps in the form of a *mini*mal *v*irtual *osc*illator ALSA driver code (minivosc), and a discussion/tutorial about it on: http://www.alsa-project.org/main/index.php/Minivosc Originally intended to be "short", it is now in itself a mouthful - just like all the other introductory stuff / tutorials I could find :) Still, I don't think having an additional point of view will hurt... So, I would please ask the community to have a glance at it - and let me know if there is something wrong with it - or if additional things (links, comments) should be added. Also, I could notice that there are two ALSA "wiki's": Main Page - AlsaProject - http://www.alsa-project.org/main/index.php/Main_Page ALSA unofficial - http://alsa.opensrc.org/index.php/Main_Page I posted the wiki entry under the 'official' one - if it is inappropriate, please let me know, and I'll move it elsewhere... Well - please let me know if you have any comments about this entry, Cheers!

1 0

[alsa-devel] Model=auto for LG R510
by David Henningsson 10 Aug '10

10 Aug '10

I've got two users saying model=auto is working better for them (it enables the internal mic and no regressions). I don't know if that is enough to remove an existing quirk, but if it is, please apply the attached patch. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 1

[PATCH] HDA: Use model=auto for LG R510
by David Henningsson 10 Aug '10

10 Aug '10

Two users report model=auto is needed to make the internal mic work properly. BugLink: https://bugs.launchpad.net/bugs/495134 Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 6b00a23..55d6e5b 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -13477,7 +13477,6 @@ static struct snd_pci_quirk alc268_cfg_tbl[] = { SND_PCI_QUIRK(0x14c0, 0x0025, "COMPAL IFL90/JFL-92", ALC268_TOSHIBA), SND_PCI_QUIRK(0x152d, 0x0763, "Diverse (CPR2000)", ALC268_ACER), SND_PCI_QUIRK(0x152d, 0x0771, "Quanta IL1", ALC267_QUANTA_IL1), - SND_PCI_QUIRK(0x1854, 0x1775, "LG R510", ALC268_DELL), {} }; -- 1.7.0.4 --------------040608090104040106090302--

1 0

[alsa-devel] [PATCH 0/3] ASoC: multi-comp: OMAP platform fixes
by Peter Ujfalusi 10 Aug '10

10 Aug '10

Hello, The following series introduces some cleanups for OMAP platforms in multi-component branch. - Enable audio for OMAP1 class - Registers only the available amount of omap-mcbsp-dai devices for OMAP2,3, and 4 Please do verify, if the chages are correct, especially the number of McBSP ports on different devices. Liam: in case you take this, you can squash this to the corresponding commit. Peter --- Peter Ujfalusi (3): ASoC: multi-comp: OMAP McBSP: use macro for platform_device ASoC: multi-comp: OMAP McBSP: Enable audio on OMAP1 platform ASoC: multi-comp: OMAP2,3,4 McBSP: register correct number of ports arch/arm/mach-omap1/devices.c | 24 +++++++++++++++ arch/arm/mach-omap2/devices.c | 50 ++++++++++++++++-------------- arch/arm/plat-omap/include/plat/mcbsp.h | 7 ++++ 3 files changed, 58 insertions(+), 23 deletions(-) -- 1.7.2

5 14

[alsa-devel] patch_nvhdmi.c's snd_hda_preset_nvhdmi[] formatting, entry naming, new entries
by Stephen Warren 09 Aug '10

09 Aug '10

All, I'm working on a patch to add some new codec IDs to patch_nvhdmi.c. I notice that many lines in that table are wrapped to avoid long lines. Is there a hard 80 column limit for ALSA driver or kernel files? I'd find the table and diff much easier to read if I could simply put each new entry on a single line, but don't want to violate any hard-and-fast coding style rules... Second, I wish to add entries for some GPUs that haven't yet been released. For these, I'd like to make the codec names simply "GPU HDMI/DP", since I can't expose naming for unreleased products. We'd like to get these entries into the driver early so that they're available in distros before products ship, so that the hardware "just works" out of the box. Indications so far are that these devices will simply be standard Azalia codecs, and hence not need any code/tables/quirks to operate correctly (i.e. they'll follow the existing "MCP89" path). Finally, the naming for existing discrete GPU entries (GT220/GT21x/GT240) is a mixture of engineering GPU names and marketing names. I'd like to edit these names to also be simply "GPU HDMI/DP" for consistency. Unfortunately, I'm not allowed to submit engineering GPU names for any GPUs, and using marketing names in these entries doesn't make sense, since there may be multiple marketing names per codec ID, and the marketing names many change over time. Does anyone have any problems with any of the above before I submit a proposed patch? Thanks. -- nvpublic

2 1