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

[alsa-devel] regarding setting of fragment size in usbaudio driver
by Amit Nagal 14 Dec '10

14 Dec '10

Hi , i am using a OSS based usbaudio application for usb audio streaming . my usb audio device is capture only device . i want to set the fragment size of usbaudio alsa driver to reduce latency problem coming in my application . currently even if my application reads 4k data from userspace , i observed driver will buffer for 100 ms data ( period size data )= 16 k at 44100 frquency and after driver reads 16k data , read call will return with 4k data . so read() call remains blocked for 100ms which is causing some latency problem . i used SNDCTL_DSP_SETFRAGMENT ioctl , but still driver behaviour to buffer 100ms data remained same . how driver's fragment size in driver can be set to some less value in OSS based application . Can some patch be implemented in kernel space to do that .? Thanx & Regards Amit Nagal

2 5

[alsa-devel] Calculated average playback latency
by Jean-Yves Avenard 14 Dec '10

14 Dec '10

Hi there. I am involved in maintaining the mythtv audio code. Today one of our user complained that he couldn't get any audio out , even though everything was properly configured on his side. By default, Myth uses mmap access ; unless we found out that the audio device doesn't allow mmap (e.g. snd_pcm_hw_params_set_access(handle, params, SND_PCM_ACCESS_MMAP_INTERLEAVED) errored) Problem, turned out his was using a USB audio device, and snd_pcm_hw_params_set_access didn't return any error. It's not the first time we're having such issues, so I decided to stop using mmap and instead use snd_pcm_writei. Now on my system, this has added quite a bit of latency and the A/V sync isn't perfect anymore... Is there an official way to calculate an average system latency (doesn't need to be perfectly accurate). I couldn't find obvious references on how to perform such task. I find some references in program like mplayer or jack using snd_pcm_status_get_trigger_tstamp Would anyone be kind enough to point me to some documentation or explain to me how I could calculate the average latency between the time you start playback and the time sounds actually comes out. Thank you in advance Jean-Yves

2 1

[alsa-devel] [PATCH] ASoC: Explicitly clear WM8993 ramp controls on power down
by Mark Brown 14 Dec '10

14 Dec '10

This helps ensure that the ramp logic is reset when powering back up. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8993.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/wm8993.c b/sound/soc/codecs/wm8993.c index 77b1d44..15f34a2 100644 --- a/sound/soc/codecs/wm8993.c +++ b/sound/soc/codecs/wm8993.c @@ -1030,6 +1030,12 @@ static int wm8993_set_bias_level(struct snd_soc_codec *codec, WM8993_VMID_SEL_MASK | WM8993_BIAS_ENA, 0); + snd_soc_update_bits(codec, WM8993_ANTIPOP2, + WM8993_STARTUP_BIAS_ENA | + WM8993_VMID_BUF_ENA | + WM8993_VMID_RAMP_MASK | + WM8993_BIAS_SRC, 0); + #ifdef CONFIG_REGULATOR /* Post 2.6.34 we will be able to get a callback when * the regulators are disabled which we can use but -- 1.7.1

2 1

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

14 Dec '10

Hi Hans, On Tuesday 14 December 2010 15:51:08 Hans Verkuil wrote: > > Laurent Pinchart wrote: > >> On Monday 13 December 2010 17:10:51 Clemens Ladisch wrote: > >>> 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. > >> > >> I'm not sure I would split entities in internal/external categories. I > >> would > >> create a category for connectors though. > > > > I'm not disagreeing, but what is actually the distinction between types > > and subtypes? ;-) > > The type tells what the behavior is of an entity. E.g., type DEVNODE > represents device node(s) in userspace, V4L2_SUBDEV represents a v4l2 > sub-device, etc. The subtype tells whether a V4L2_SUBDEV is a sensor or a > receiver or whatever. Nice to know, but it doesn't change the way > sub-devices work. > > In the case of connectors you would create a CONNECTOR type and have a > bunch of subtypes for all the variations of connectors. > > That said, I'm not sure whether the distinction is useful for DEVNODEs. > You do need to know the subtype in order to interpret the union correctly. > > Laurent, does the MC code test against the DEVNODE type? I.e., does the MC > code ignore the subtype of a DEVNODE, or does it always use it? The MC code uses the DEVNODE type, ignoring the subtype, for power management. When a device node is opened all entities in the chain need to be powered up. -- Regards, Laurent Pinchart

1 0

[alsa-devel] [PATCH v2] ASoC: dapm: Add output driver widget
by Olaya, Margarita 14 Dec '10

14 Dec '10

In some cases it was not possible to follow the appropiate power ON/OFF sequence like in cases where the PGA needs to be enabled before the driver and disabled before the PGA for pop reduction. Add a widget to support output driver (speaker, haptic, vibra, etc) drivers where power ON/OFF ordering is important. Signed-off-by: Margarita Olaya Cabrera <magi.olaya(a)ti.com> --- include/sound/soc-dapm.h | 10 ++++++++++ sound/soc/soc-dapm.c | 6 ++++++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index 041e98b..2f76a51 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -71,6 +71,10 @@ wcontrols, wncontrols) \ { .id = snd_soc_dapm_pga, .name = wname, .reg = wreg, .shift = wshift, \ .invert = winvert, .kcontrols = wcontrols, .num_kcontrols = wncontrols} +#define SND_SOC_DAPM_OUT_DRV(wname, wreg, wshift, winvert,\ + wcontrols, wncontrols) \ +{ .id = snd_soc_dapm_out_drv, .name = wname, .reg = wreg, .shift = wshift, \ + .invert = winvert, .kcontrols = wcontrols, .num_kcontrols = wncontrols} #define SND_SOC_DAPM_MIXER(wname, wreg, wshift, winvert, \ wcontrols, wncontrols)\ { .id = snd_soc_dapm_mixer, .name = wname, .reg = wreg, .shift = wshift, \ @@ -115,6 +119,11 @@ { .id = snd_soc_dapm_pga, .name = wname, .reg = wreg, .shift = wshift, \ .invert = winvert, .kcontrols = wcontrols, .num_kcontrols = wncontrols, \ .event = wevent, .event_flags = wflags} +#define SND_SOC_DAPM_OUT_DRV_E(wname, wreg, wshift, winvert, wcontrols, \ + wncontrols, wevent, wflags) \ +{ .id = snd_soc_dapm_out_drv, .name = wname, .reg = wreg, .shift = wshift, \ + .invert = winvert, .kcontrols = wcontrols, .num_kcontrols = wncontrols, \ + .event = wevent, .event_flags = wflags} #define SND_SOC_DAPM_MIXER_E(wname, wreg, wshift, winvert, wcontrols, \ wncontrols, wevent, wflags) \ { .id = snd_soc_dapm_mixer, .name = wname, .reg = wreg, .shift = wshift, \ @@ -368,6 +377,7 @@ enum snd_soc_dapm_type { snd_soc_dapm_mixer, /* mixes several analog signals together */ snd_soc_dapm_mixer_named_ctl, /* mixer with named controls */ snd_soc_dapm_pga, /* programmable gain/attenuation (volume) */ + snd_soc_dapm_out_drv, /* output driver */ snd_soc_dapm_adc, /* analog to digital converter */ snd_soc_dapm_dac, /* digital to analog converter */ snd_soc_dapm_micbias, /* microphone bias (power) */ diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 6a29d59..31e9681 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -62,6 +62,7 @@ static int dapm_up_seq[] = { [snd_soc_dapm_mixer_named_ctl] = 7, [snd_soc_dapm_pga] = 8, [snd_soc_dapm_adc] = 9, + [snd_soc_dapm_out_drv] = 10, [snd_soc_dapm_hp] = 10, [snd_soc_dapm_spk] = 10, [snd_soc_dapm_post] = 11, @@ -72,6 +73,7 @@ static int dapm_down_seq[] = { [snd_soc_dapm_adc] = 1, [snd_soc_dapm_hp] = 2, [snd_soc_dapm_spk] = 2, + [snd_soc_dapm_out_drv] = 2, [snd_soc_dapm_pga] = 4, [snd_soc_dapm_mixer_named_ctl] = 5, [snd_soc_dapm_mixer] = 5, @@ -231,6 +233,7 @@ static void dapm_set_path_status(struct snd_soc_dapm_widget *w, break; /* does not effect routing - always connected */ case snd_soc_dapm_pga: + case snd_soc_dapm_out_drv: case snd_soc_dapm_output: case snd_soc_dapm_adc: case snd_soc_dapm_input: @@ -1243,6 +1246,7 @@ static ssize_t dapm_widget_show(struct device *dev, case snd_soc_dapm_dac: case snd_soc_dapm_adc: case snd_soc_dapm_pga: + case snd_soc_dapm_out_drv: case snd_soc_dapm_mixer: case snd_soc_dapm_mixer_named_ctl: case snd_soc_dapm_supply: @@ -1421,6 +1425,7 @@ static int snd_soc_dapm_add_route(struct snd_soc_dapm_context *dapm, case snd_soc_dapm_adc: case snd_soc_dapm_dac: case snd_soc_dapm_pga: + case snd_soc_dapm_out_drv: case snd_soc_dapm_input: case snd_soc_dapm_output: case snd_soc_dapm_micbias: @@ -1538,6 +1543,7 @@ int snd_soc_dapm_new_widgets(struct snd_soc_dapm_context *dapm) w->power_check = dapm_dac_check_power; break; case snd_soc_dapm_pga: + case snd_soc_dapm_out_drv: w->power_check = dapm_generic_check_power; dapm_new_pga(dapm, w); break; -- 1.7.0.4

2 1

Re: [alsa-devel] [PATCH 5/5] sound: ml403-ac97cr: Use vsprintf extension %pR for struct resource
by Takashi Iwai 14 Dec '10

14 Dec '10

At Mon, 13 Dec 2010 13:42:22 -0800, Joe Perches wrote: > > Signed-off-by: Joe Perches <joe(a)perches.com> Applied now. Thanks. Takashi > --- > sound/drivers/ml403-ac97cr.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sound/drivers/ml403-ac97cr.c b/sound/drivers/ml403-ac97cr.c > index a1282c1..5cfcb90 100644 > --- a/sound/drivers/ml403-ac97cr.c > +++ b/sound/drivers/ml403-ac97cr.c > @@ -1143,8 +1143,8 @@ snd_ml403_ac97cr_create(struct snd_card *card, struct platform_device *pfdev, > (resource->start) + 1); > if (ml403_ac97cr->port == NULL) { > snd_printk(KERN_ERR SND_ML403_AC97CR_DRIVER ": " > - "unable to remap memory region (%x to %x)\n", > - resource->start, resource->end); > + "unable to remap memory region (%pR)\n", > + resource); > snd_ml403_ac97cr_free(ml403_ac97cr); > return -EBUSY; > } > -- > 1.7.3.3.398.g0b0cd.dirty >

1 0

[alsa-devel] [PATCH] ASoC: Fix AC'97 registration unwind
by Mark Brown 13 Dec '10

13 Dec '10

soc_unregister_ac97_dai_link() takes a CODEC as an argument, not a rtd like the registration function, so give it what it's looking for. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-core.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 68edc69..1dc4b11 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1830,7 +1830,7 @@ static void snd_soc_instantiate_card(struct snd_soc_card *card) if (ret < 0) { printk(KERN_ERR "asoc: failed to register AC97 %s\n", card->name); while (--i >= 0) - soc_unregister_ac97_dai_link(&card->rtd[i]); + soc_unregister_ac97_dai_link(card->rtd[i].codec); goto probe_aux_dev_err; } } -- 1.7.1

2 1

[alsa-devel] [PATCH] regulator: Update LDO2 for WM8958
by Mark Brown 13 Dec '10

13 Dec '10

LDO2 has a slightly different range of supported voltages on WM8958 so update the selector<->voltage mappings to match. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- As the WM8958 support is currently sitting in the ASoC tree for the next merge window this should get merged that way. I've done some test merges here and git seems to be able to figure out the overlaps with the code in your tree so are you OK with applying to ASoC? drivers/regulator/wm8994-regulator.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/wm8994-regulator.c b/drivers/regulator/wm8994-regulator.c index 03713bc..21fefef 100644 --- a/drivers/regulator/wm8994-regulator.c +++ b/drivers/regulator/wm8994-regulator.c @@ -131,10 +131,19 @@ static struct regulator_ops wm8994_ldo1_ops = { static int wm8994_ldo2_list_voltage(struct regulator_dev *rdev, unsigned int selector) { + struct wm8994_ldo *ldo = rdev_get_drvdata(rdev); + if (selector > WM8994_LDO2_MAX_SELECTOR) return -EINVAL; - return (selector * 100000) + 900000; + switch (ldo->wm8994->type) { + case WM8994: + return (selector * 100000) + 900000; + case WM8958: + return (selector * 100000) + 1000000; + default: + return -EINVAL; + } } static int wm8994_ldo2_get_voltage(struct regulator_dev *rdev) @@ -157,7 +166,17 @@ static int wm8994_ldo2_set_voltage(struct regulator_dev *rdev, struct wm8994_ldo *ldo = rdev_get_drvdata(rdev); int selector, v; - selector = (min_uV - 900000) / 100000; + switch (ldo->wm8994->type) { + case WM8994: + selector = (min_uV - 900000) / 100000; + break; + case WM8958: + selector = (min_uV - 1000000) / 100000; + break; + default: + return -EINVAL; + } + v = wm8994_ldo2_list_voltage(rdev, selector); if (v < 0 || v > max_uV) return -EINVAL; -- 1.7.1

2 1

[alsa-devel] [RFC 2.6.38] ASoC: Fix bias power down of non-DAPM codec
by Jarkko Nikula 13 Dec '10

13 Dec '10

Currently bias of non-DAPM codec will be powered down (standby/off) whenever there is a stream stop. This is wrong in simultaneous playback/capture since the bias is put down immediately after stopping the first stream. Fix this by using the codec->active count when figuring out the needed bias level after stream stop. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- RFC since does this look a valid fix and how to deal with 2.6.37? I think patching the .37 first will result in bisect build errors in mainline when later merging upcoming .38 changes. Would it be better to patch .37 after it's released? --- sound/soc/soc-dapm.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 9af2d8a..b521a13 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -981,6 +981,9 @@ static int dapm_power_widgets(struct snd_soc_dapm_context *dapm, int event) case SND_SOC_DAPM_STREAM_RESUME: sys_power = 1; break; + case SND_SOC_DAPM_STREAM_STOP: + sys_power = !!dapm->codec->active; + break; case SND_SOC_DAPM_STREAM_SUSPEND: sys_power = 0; break; -- 1.7.2.3

5 10

Re: [alsa-devel] [RFC/PATCH v6 03/12] media: Entities, pads and links
by Clemens Ladisch 13 Dec '10

13 Dec '10

Laurent Pinchart wrote: > A link is a point-to-point oriented connection between two pads, either > on the same entity or on different entities. Data flows from a source > pad to a sink pad. > > Links are stored in the source entity. In the descriptors of USB Audio and HDAudio devices, the links are stored only in the sink. But AFAICS this doesn't matter in the media driver API. > +Links have flags that describe the link capabilities and state. > + > + MEDIA_LINK_FLAG_ACTIVE indicates that the link is active and can be > + used to transfer media data. When two or more links target a sink pad, > + only one of them can be active at a time. > + MEDIA_LINK_FLAG_IMMUTABLE indicates that the link active state can't > + be modified at runtime. If MEDIA_LINK_FLAG_IMMUTABLE is set, then > + MEDIA_LINK_FLAG_ACTIVE must also be set since an immutable link is > + always active. So the intended userspace API for controlling routing is to change the ACTIVE flag of links? In USB and HD audio devices, all links are immutable, and the routing is controlled by 'selector' entities that activate exactly one of their input pads. In userspace, this entity shows up as a mixer control. I guess it would be possible to map the ACTIVE flag onto these controls. Alternatively, entities can have 'mute' mixer controls associated with their pads. In this case, multiple unmuted inputs would be mixed together. > +#define MEDIA_ENTITY_TYPE_MASK 0x00ff0000 > +#define MEDIA_ENTITY_SUBTYPE_MASK 0x0000ffff > + > +#define MEDIA_ENTITY_TYPE_NODE (1 << MEDIA_ENTITY_TYPE_SHIFT) > ... > +#define MEDIA_ENTITY_TYPE_NODE_ALSA (MEDIA_ENTITY_TYPE_NODE + 3) ALSA has PCM and MIDI devices, and several types of mixer controls. (It also has hardware dependent and timer devices, but I don't think these would need topology information.) So we need at least these: MEDIA_ENTITY_TYPE_NODE_ALSA_PCM MEDIA_ENTITY_TYPE_NODE_ALSA_MIDI MEDIA_ENTITY_TYPE_SUBDEV_ALSA_CONTROL Furthermore, topology information is also needed for entities not associated with a mixer control, such as microphones, speakers, jacks/ connectors, and effect units. These entities are defined in the USB and HD audio specifications, but are not yet handled by ALSA. > +struct media_entity { > ... > + union { > + /* Node specifications */ > + struct { > + u32 major; > + u32 minor; > + } v4l; > + struct { > + u32 major; > + u32 minor; > + } fb; > + int alsa; > + int dvb; > + > + /* Sub-device specifications */ > + /* Nothing needed yet */ > + }; ALSA devices are not addressed by their device node but with card/device/ subdevice numbers; mixer controls have numeric IDs, unique per card: struct { int card; int device; int subdevice; } alsa_device; struct { int card; int numid; } alsa_control; Regards, Clemens

3 7