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

[alsa-devel] [PATCH] ASoC: sh: fsi: modify improper dependent
by Kuninori Morimoto 22 Dec '10

22 Dec '10

FSI-AK4642 and FSI-DA7210 are depend on I2C, not I2C_SH_MOBILE Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- This is v2 of "ASoC: sh: fsi: remove unnecessary dependent from Kconfig" Thanks Mark !! sound/soc/sh/Kconfig | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sh/Kconfig b/sound/soc/sh/Kconfig index 7f0a496..d8e06a6 100644 --- a/sound/soc/sh/Kconfig +++ b/sound/soc/sh/Kconfig @@ -48,7 +48,7 @@ config SND_SH7760_AC97 config SND_FSI_AK4642 tristate "FSI-AK4642 sound support" - depends on SND_SOC_SH4_FSI && I2C_SH_MOBILE + depends on SND_SOC_SH4_FSI && I2C select SND_SOC_AK4642 help This option enables generic sound support for the @@ -56,7 +56,7 @@ config SND_FSI_AK4642 config SND_FSI_DA7210 tristate "FSI-DA7210 sound support" - depends on SND_SOC_SH4_FSI && I2C_SH_MOBILE + depends on SND_SOC_SH4_FSI && I2C select SND_SOC_DA7210 help This option enables generic sound support for the -- 1.7.1

3 2

[alsa-devel] [PATCH] ASoC: Make LZO cache compression optional
by Mark Brown 21 Dec '10

21 Dec '10

Make LZO cache compression optional as it pulls in the kernel wide LZO implementation and rbtree compression is generally more efficient for typical register maps, especially in terms of CPU performance. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/Kconfig | 17 +++++++++++++++-- sound/soc/soc-cache.c | 4 ++++ 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig index 21a5465..a3efc52 100644 --- a/sound/soc/Kconfig +++ b/sound/soc/Kconfig @@ -4,8 +4,6 @@ menuconfig SND_SOC tristate "ALSA for SoC audio support" - select LZO_COMPRESS - select LZO_DECOMPRESS select SND_PCM select AC97_BUS if SND_SOC_AC97_BUS select SND_JACK if INPUT=y || INPUT=SND @@ -22,6 +20,21 @@ menuconfig SND_SOC if SND_SOC +config SND_SOC_CACHE_LZO + bool "Support LZO compression for register caches" + select LZO_COMPRESS + select LZO_DECOMPRESS + ---help--- + Select this to enable LZO compression for register caches. + This will allow machine or CODEC drivers to compress register + caches in memory, reducing the memory consumption at the + expense of performance. If this is not present and is used + the system will fall back to uncompressed caches. + + Usually it is safe to disable this option, where cache + compression in used the rbtree option will typically perform + better. + config SND_SOC_AC97_BUS bool diff --git a/sound/soc/soc-cache.c b/sound/soc/soc-cache.c index d78e5b7..6b95ae7 100644 --- a/sound/soc/soc-cache.c +++ b/sound/soc/soc-cache.c @@ -988,6 +988,7 @@ static int snd_soc_rbtree_cache_init(struct snd_soc_codec *codec) return 0; } +#ifdef CONFIG_SND_SOC_CACHE_LZO struct snd_soc_lzo_ctx { void *wmem; void *dst; @@ -1399,6 +1400,7 @@ err_tofree: } return ret; } +#endif static int snd_soc_flat_cache_sync(struct snd_soc_codec *codec) { @@ -1541,6 +1543,7 @@ static const struct snd_soc_cache_ops cache_types[] = { .write = snd_soc_flat_cache_write, .sync = snd_soc_flat_cache_sync }, +#ifdef CONFIG_SND_SOC_CACHE_LZO { .id = SND_SOC_LZO_COMPRESSION, .name = "LZO", @@ -1550,6 +1553,7 @@ static const struct snd_soc_cache_ops cache_types[] = { .write = snd_soc_lzo_cache_write, .sync = snd_soc_lzo_cache_sync }, +#endif { .id = SND_SOC_RBTREE_COMPRESSION, .name = "rbtree", -- 1.7.2.3

2 1

[alsa-devel] [PATCH] ASoC: If we can't find a cache compression type default to flat
by Mark Brown 21 Dec '10

21 Dec '10

This makes it easier to make cache types build time configurable as we don't have a hard dependency on a given cache being built in. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-cache.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-cache.c b/sound/soc/soc-cache.c index 678fd75..d78e5b7 100644 --- a/sound/soc/soc-cache.c +++ b/sound/soc/soc-cache.c @@ -1531,6 +1531,7 @@ static int snd_soc_flat_cache_init(struct snd_soc_codec *codec) /* an array of all supported compression types */ static const struct snd_soc_cache_ops cache_types[] = { + /* Flat *must* be the first entry for fallback */ { .id = SND_SOC_FLAT_COMPRESSION, .name = "flat", @@ -1567,10 +1568,12 @@ int snd_soc_cache_init(struct snd_soc_codec *codec) for (i = 0; i < ARRAY_SIZE(cache_types); ++i) if (cache_types[i].id == codec->compress_type) break; + + /* Fall back to flat compression */ if (i == ARRAY_SIZE(cache_types)) { - dev_err(codec->dev, "Could not match compress type: %d\n", - codec->compress_type); - return -EINVAL; + dev_warn(codec->dev, "Could not match compress type: %d\n", + codec->compress_type); + i = 0; } mutex_init(&codec->cache_rw_mutex); -- 1.7.2.3

2 1

Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
by Laurent Pinchart 21 Dec '10

21 Dec '10

Hi Hans, On Tuesday 14 December 2010 13:40:21 Hans Verkuil wrote: > > On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: > >> * Entity types > >> > >> TYPE_NODE was renamed to TYPE_DEVICE because "node" sounds like a node > >> in a graph, which does not distinguish it from other entity types > >> because all entities are part of the topology graph. I chose "device" > >> as this type describes entities that are visible as some device node to > >> other software. > > > > What this type describes is a device node. Both NODE and DEVICE can be > > confusing in my opinion, but DEVICE_NODE is a bit long. > > What about DEVNODE? I think that would be a good alternative. Fine with me. Clemens, any opinion on that ? > >> TYPE_EXT describes entities that represent some interface to the > >> external world, TYPE_INT those that are internal to the entire device. > >> (I'm not sure if that distinction is very useful, but TYPE_SUBDEV seems > >> to be an even more meaningless name.) > > > > SUBDEV comes from the V4L2 world, and I agree that it might not be a very > > good name. > > SUBDEV refers to a specific type of driver. Within the v4l world it is > well defined. So I prefer to keep this. Perhaps some additional comments > or documentation can be added to clarify this. Should this be clarified by using V4L2_SUBDEV instead then ? What about ALSA entities, should they use MEDIA_ENTITY_TYPE_ALSA_* ? > > I'm not sure I would split entities in internal/external categories. I > > would create a category for connectors though. > > I agree. It was always the plan to eventually add connectors, but v4l > didn't really need it (it already has an API to enumerate connectors). > > >> ALSA mixer controls are not directly represented; a better fit for the > >> architecture of actual devices is that one or more mixer controls can be > >> associated with an entity. (This can be done with a field of the mixer > >> control.) > > > > Agreed. > > > >> * Entity properties > >> > >> There needs to be a mechanism to associate meta-information (properties) > >> with entities. This information should be optional and extensible, but, > >> when being handled inside the kernel, doesn't need to be more than > >> a read-only blob. I think that something like ALSA's TLV format (used > >> for mixer controls) can be used here. (I'm not mentioning the X-word > >> here, except to note that the "M" stands for "markup".) > > > > I've been thinking of adding a new ioctl for that. It's something we need > > to draft. The UVC driver will need it, and I'm pretty sure other V4L2 > > drivers would find it useful as well. > > > >> * Entity subtypes > >> > >> EXT_JACK_ANALOG represents any analog audio and/or video connector. > >> Properties for audio jacks would be jack type (TRS/RCA), color code, > >> line level, position, etc. > >> > >> EXT_JACK_DIGITAL represents a digital connector like S/PDIF (coax/ > >> TOSLINK), ADAT, TDIF, or MADI. > >> > >> EXT_JACK_BUS represents a bus like FireWire and comes from the USB audio > >> spec. (I doubt that any devices with this entitiy will ever exist.) > >> > >> EXT_INSTRUMENT represents something like an e-guitar, keyboard, or MIDI > >> controller. (Instrument entities are typically audio sources and MIDI > >> sources and sinks, but can also be audio sinks.) > >> > >> EXT_SPEAKER also includes headphones; there might be made a case for > >> having those as a separate subtype. > > > > Shouldn't headphones be represented by an EXT_JACK_ANALOG ? > > > >> EXT_PLAYER represents a device like a CD/DVD/tape player. Recorders can > >> also write to that device, so "player" might not be an ideal name. > >> > >> EXT_BROADCAST represents devices like TV tuners, satellite receivers, > >> cable tuners, or radios. > > I don't think it is right to talk about 'represents devices'. I'd rephrase > it to 'connects to devices'. > > > There's clearly an overlap with V4L here. Hopefully someone from the > > linux-media list can comment on this. > > I don't think this will be a problem. Initially we probably won't be > enumerating connectors for V4L since it already has its own API for that. My understanding is that EXT_BROADCAST really represents the TV tuners, ..., not the connector they connect to. Some (all ?) of them are definitely V4L2 subdevs. > >> INT_SYNTHESIZER converts MIDI to audio. > >> > >> INT_NOISE_SOURCE comes from the USB audio spec; this is not an attempt > >> to describe the characteristics of consumer-grade devices :-) , but > >> represents an internal noise source for level calibration or > >> measurements. > >> > >> INT_CONTROLS may have multiple independent controls (this is USB's > >> Feature Unit); INT_EFFECT may have multiple controls that affect one > >> single algorithm. > > > > I'd describe this as a feature unit/processing unit then. > > > >> INT_CHANNEL_SPLIT/MERGE are needed for HDAudio devices, whose topology > >> information has only stereo links. > > > > Some of those INT entities could also be implemented in dedicated chips, > > so I really think the EXT/INT split doesn't make too much sense. Should we > > have an AUDIO category ? > > > >> * Entity specifications > >> > >> While TYPE_DEVICE entities can be identified by their device node, other > >> entities typcially have just a numeric ID. > > > > In V4L2 sub-devices have (or rather will have once the media controller > > patches will be integrated) device nodes as well, so exposing that > > information > > is required. > > > >> For that, it would be useful to make do without separate identification > >> and let the driver choose the entity ID. > > > > How would drivers do that ? What if you have two instances of the same > > chip (a video sensor, audio mixer, ...) on the same board ? -- Regards, Laurent Pinchart

3 3

[alsa-devel] [PATCH] ASoC: Add optional pointer to machine audio routes to snd_soc_card
by Jarkko Nikula 21 Dec '10

21 Dec '10

This is targeted mostly to cross-device setups where single audio map defining routes around and between the codecs looks cleaner than defining and registering maps to each codec separately from machine init callbacks. This could be also used to reduce simple machine init callbacks where only snd_soc_dapm_add_routes and snd_soc_dapm_sync are called. However, this does work only if the widgets names are unique in the system. Idea of common audio map came from Peter Ujfalusi <peter.ujfalusi(a)nokia.com>. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> Cc: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- include/sound/soc.h | 8 ++++++++ sound/soc/soc-core.c | 21 +++++++++++++++++++++ 2 files changed, 29 insertions(+), 0 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 74921f2..d037996 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -654,6 +654,14 @@ struct snd_soc_card { struct snd_soc_pcm_runtime *rtd_aux; int num_aux_rtd; + /* + * optional machine audio map. Can be used as an alternative for + * snd_soc_dapm_add_routes call in machine init in single codec setup + * or as a common audio map in cross-device setup + */ + const struct snd_soc_dapm_route *route; + int num_routes; + struct work_struct deferred_resume_work; /* lists of probed devices belonging to this card */ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index a233607..66591e3 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1720,6 +1720,7 @@ static void snd_soc_instantiate_card(struct snd_soc_card *card) struct snd_soc_codec *codec; struct snd_soc_codec_conf *codec_conf; enum snd_soc_compress_type compress_type; + const char *temp; int ret, i; mutex_lock(&card->mutex); @@ -1813,6 +1814,26 @@ static void snd_soc_instantiate_card(struct snd_soc_card *card) } } + if (card->route) { + /* + * use the last codec and dapm context of it when setting up + * the common audio map + */ + codec = list_first_entry(&card->codec_dev_list, + struct snd_soc_codec, card_list); + temp = codec->name_prefix; + codec->name_prefix = NULL; + ret = snd_soc_dapm_add_routes(&codec->dapm, + card->route, card->num_routes); + if (ret < 0) { + pr_err("asoc: failed to add routes %s: %d\n", + card->name, ret); + goto probe_aux_dev_err; + } + codec->name_prefix = temp; + snd_soc_dapm_sync(&codec->dapm); + } + snprintf(card->snd_card->shortname, sizeof(card->snd_card->shortname), "%s", card->name); snprintf(card->snd_card->longname, sizeof(card->snd_card->longname), -- 1.7.2.3

4 9

[alsa-devel] Underrun problem in capture and playback application
by Irfan Shaikh 21 Dec '10

21 Dec '10

Hello Developers I have set following configuration for my capture and playback application I am getting lot of UNDERRUN. How can i avoid buffer underruns. At a time i am READING "BUFFERSIZE" frames and writing same number of frames in while loop. SAMPLERATE 44100 PERIODSIZE_CAPTURE 1024 NUMBER_OF_PERIODS_CAPTURE 8 PERIODSIZE_PLAYBACK 512 NUMBER_OF_PERIODS_PLAYBACK 16 NUMBER_OF_CHANNELS 1 SAMPLESIZE 2 FRAMESIZE (NUMBER_OF_CHANNELS * SAMPLESIZE) BUFFERSIZE = (PERIODSIZE_CAPTURE * NUMBER_OF_PERIODS_CAPTURE) SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html

1 0

[alsa-devel] [PATCH] regulator: Clean up logging a bit
by Mark Brown 21 Dec '10

21 Dec '10

The recent introduction of standard regulator API logging macros means that all our log messages have at least the function name in them and logging that the constraints are for the regulator API is probably a bit much. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- drivers/regulator/core.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index ab419f8..911b774 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -739,7 +739,7 @@ static void print_constraints(struct regulator_dev *rdev) if (constraints->valid_modes_mask & REGULATOR_MODE_STANDBY) count += sprintf(buf + count, "standby"); - rdev_info(rdev, "regulator: %s\n", buf); + rdev_info(rdev, "%s\n", buf); } static int machine_constraints_voltage(struct regulator_dev *rdev, -- 1.7.1

2 1

[alsa-devel] [PATCH] ASoC: twl6040: Convert HF and HS drivers to use DAPM OUT_DRV widget
by Olaya, Margarita 21 Dec '10

21 Dec '10

Make the phoenix HS and HF drivers use the new DAPM driver widget in order to guarantee power ON/OFF order sequence. Signed-off-by: Margarita Olaya Cabrera <magi.olaya(a)ti.com> --- sound/soc/codecs/twl6040.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/twl6040.c b/sound/soc/codecs/twl6040.c index 2f68f59..4bbf1b1 100644 --- a/sound/soc/codecs/twl6040.c +++ b/sound/soc/codecs/twl6040.c @@ -1138,19 +1138,19 @@ static const struct snd_soc_dapm_widget twl6040_dapm_widgets[] = { SND_SOC_NOPM, 0, 0, &hsr_mux_controls), /* Analog playback drivers */ - SND_SOC_DAPM_PGA_E("Handsfree Left Driver", + SND_SOC_DAPM_OUT_DRV_E("Handsfree Left Driver", TWL6040_REG_HFLCTL, 4, 0, NULL, 0, pga_event, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD), - SND_SOC_DAPM_PGA_E("Handsfree Right Driver", + SND_SOC_DAPM_OUT_DRV_E("Handsfree Right Driver", TWL6040_REG_HFRCTL, 4, 0, NULL, 0, pga_event, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD), - SND_SOC_DAPM_PGA_E("Headset Left Driver", + SND_SOC_DAPM_OUT_DRV_E("Headset Left Driver", TWL6040_REG_HSLCTL, 2, 0, NULL, 0, pga_event, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD), - SND_SOC_DAPM_PGA_E("Headset Right Driver", + SND_SOC_DAPM_OUT_DRV_E("Headset Right Driver", TWL6040_REG_HSRCTL, 2, 0, NULL, 0, pga_event, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD), -- 1.7.0.4

3 2

[alsa-devel] [PATCH] ASoC: Fix WM8994/58 3D stereo control definitions
by Mark Brown 21 Dec '10

21 Dec '10

Cut'n'paste in the register names. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index af104ac..e1a775b 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -869,15 +869,15 @@ SOC_SINGLE_TLV("SPKR DAC1 Volume", WM8994_SPKMIXR_ATTENUATION, SOC_SINGLE_TLV("AIF1DAC1 3D Stereo Volume", WM8994_AIF1_DAC1_FILTERS_2, 10, 15, 0, wm8994_3d_tlv), -SOC_SINGLE("AIF1DAC1 3D Stereo Switch", WM8994_AIF1_DAC2_FILTERS_2, +SOC_SINGLE("AIF1DAC1 3D Stereo Switch", WM8994_AIF1_DAC1_FILTERS_2, 8, 1, 0), SOC_SINGLE_TLV("AIF1DAC2 3D Stereo Volume", WM8994_AIF1_DAC2_FILTERS_2, 10, 15, 0, wm8994_3d_tlv), SOC_SINGLE("AIF1DAC2 3D Stereo Switch", WM8994_AIF1_DAC2_FILTERS_2, 8, 1, 0), -SOC_SINGLE_TLV("AIF2DAC 3D Stereo Volume", WM8994_AIF1_DAC1_FILTERS_2, +SOC_SINGLE_TLV("AIF2DAC 3D Stereo Volume", WM8994_AIF2_DAC_FILTERS_2, 10, 15, 0, wm8994_3d_tlv), -SOC_SINGLE("AIF2DAC 3D Stereo Switch", WM8994_AIF1_DAC2_FILTERS_2, +SOC_SINGLE("AIF2DAC 3D Stereo Switch", WM8994_AIF2_DAC_FILTERS_2, 8, 1, 0), }; -- 1.7.1

2 1

[alsa-devel] [PATCH] ASoC: Remove some unused defines from WM8903
by Mark Brown 21 Dec '10

21 Dec '10

These would have been used if we'd done manual clock divider setup, but we didn't. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8903.h | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/wm8903.h b/sound/soc/codecs/wm8903.h index 7f9f6be..5f23d3c 100644 --- a/sound/soc/codecs/wm8903.h +++ b/sound/soc/codecs/wm8903.h @@ -19,10 +19,6 @@ extern int wm8903_mic_detect(struct snd_soc_codec *codec, struct snd_soc_jack *jack, int det, int shrt); -#define WM8903_MCLK_DIV_2 1 -#define WM8903_CLK_SYS 2 -#define WM8903_BCLK 3 -#define WM8903_LRCLK 4 /* * Register values. -- 1.7.1

2 1