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

[alsa-devel] [PATCH] ASoC: Blackfin: convert internal names from bf52x to bf5xx
by Mike Frysinger 20 Jun '09

20 Jun '09

From: Barry Song <barry.song(a)analog.com> These drivers aren't BF52x specific, so don't use bf52x in the names. Signed-off-by: Barry Song <barry.song(a)analog.com> Signed-off-by: Mike Frysinger <vapier(a)gentoo.org> --- sound/soc/blackfin/bf5xx-ad73311.c | 16 ++++++++-------- sound/soc/blackfin/bf5xx-ssm2602.c | 16 ++++++++-------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/sound/soc/blackfin/bf5xx-ad73311.c b/sound/soc/blackfin/bf5xx-ad73311.c index edfbdc0..9825b71 100644 --- a/sound/soc/blackfin/bf5xx-ad73311.c +++ b/sound/soc/blackfin/bf5xx-ad73311.c @@ -203,23 +203,23 @@ static struct snd_soc_device bf5xx_ad73311_snd_devdata = { .codec_dev = &soc_codec_dev_ad73311, }; -static struct platform_device *bf52x_ad73311_snd_device; +static struct platform_device *bf5xx_ad73311_snd_device; static int __init bf5xx_ad73311_init(void) { int ret; pr_debug("%s enter\n", __func__); - bf52x_ad73311_snd_device = platform_device_alloc("soc-audio", -1); - if (!bf52x_ad73311_snd_device) + bf5xx_ad73311_snd_device = platform_device_alloc("soc-audio", -1); + if (!bf5xx_ad73311_snd_device) return -ENOMEM; - platform_set_drvdata(bf52x_ad73311_snd_device, &bf5xx_ad73311_snd_devdata); - bf5xx_ad73311_snd_devdata.dev = &bf52x_ad73311_snd_device->dev; - ret = platform_device_add(bf52x_ad73311_snd_device); + platform_set_drvdata(bf5xx_ad73311_snd_device, &bf5xx_ad73311_snd_devdata); + bf5xx_ad73311_snd_devdata.dev = &bf5xx_ad73311_snd_device->dev; + ret = platform_device_add(bf5xx_ad73311_snd_device); if (ret) - platform_device_put(bf52x_ad73311_snd_device); + platform_device_put(bf5xx_ad73311_snd_device); return ret; } @@ -227,7 +227,7 @@ static int __init bf5xx_ad73311_init(void) static void __exit bf5xx_ad73311_exit(void) { pr_debug("%s enter\n", __func__); - platform_device_unregister(bf52x_ad73311_snd_device); + platform_device_unregister(bf5xx_ad73311_snd_device); } module_init(bf5xx_ad73311_init); diff --git a/sound/soc/blackfin/bf5xx-ssm2602.c b/sound/soc/blackfin/bf5xx-ssm2602.c index bc0cdde..3a00fa4 100644 --- a/sound/soc/blackfin/bf5xx-ssm2602.c +++ b/sound/soc/blackfin/bf5xx-ssm2602.c @@ -148,24 +148,24 @@ static struct snd_soc_device bf5xx_ssm2602_snd_devdata = { .codec_data = &bf5xx_ssm2602_setup, }; -static struct platform_device *bf52x_ssm2602_snd_device; +static struct platform_device *bf5xx_ssm2602_snd_device; static int __init bf5xx_ssm2602_init(void) { int ret; pr_debug("%s enter\n", __func__); - bf52x_ssm2602_snd_device = platform_device_alloc("soc-audio", -1); - if (!bf52x_ssm2602_snd_device) + bf5xx_ssm2602_snd_device = platform_device_alloc("soc-audio", -1); + if (!bf5xx_ssm2602_snd_device) return -ENOMEM; - platform_set_drvdata(bf52x_ssm2602_snd_device, + platform_set_drvdata(bf5xx_ssm2602_snd_device, &bf5xx_ssm2602_snd_devdata); - bf5xx_ssm2602_snd_devdata.dev = &bf52x_ssm2602_snd_device->dev; - ret = platform_device_add(bf52x_ssm2602_snd_device); + bf5xx_ssm2602_snd_devdata.dev = &bf5xx_ssm2602_snd_device->dev; + ret = platform_device_add(bf5xx_ssm2602_snd_device); if (ret) - platform_device_put(bf52x_ssm2602_snd_device); + platform_device_put(bf5xx_ssm2602_snd_device); return ret; } @@ -173,7 +173,7 @@ static int __init bf5xx_ssm2602_init(void) static void __exit bf5xx_ssm2602_exit(void) { pr_debug("%s enter\n", __func__); - platform_device_unregister(bf52x_ssm2602_snd_device); + platform_device_unregister(bf5xx_ssm2602_snd_device); } module_init(bf5xx_ssm2602_init); -- 1.6.3.1

3 4

[alsa-devel] [PATCH 1/5] ASoC codec: SSM2602: remove unsupported sample rates
by Mike Frysinger 20 Jun '09

20 Jun '09

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/codecs/ssm2602.c | 8 +++----- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/ssm2602.c b/sound/soc/codecs/ssm2602.c index 87f606c..d6af069 100644 --- a/sound/soc/codecs/ssm2602.c +++ b/sound/soc/codecs/ssm2602.c @@ -497,11 +497,9 @@ static int ssm2602_set_bias_level(struct snd_soc_codec *codec, return 0; } -#define SSM2602_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |\ - SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_22050 |\ - SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |\ - SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 |\ - SNDRV_PCM_RATE_96000) +#define SSM2602_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_32000 |\ + SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |\ + SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000) #define SSM2602_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE |\ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE) -- 1.6.3.1

7 40

[alsa-devel] The new mixer logic in PA
by Lennart Poettering 20 Jun '09

20 Jun '09

Heya! During the last weeks I have been reworking the ALSA mixer and device enumeration handling in PA to be more flexible and support more features of usual mixers/cards then it previously did. (Previously we just picked one simple mixer element and used it for volume and muting; 'Master' for output; 'Capture' for input; and the ALSA device name list we used was hardcoded). I just landed all of this in PA, and would like to pass this at least roughly by you folks, hoping for comments. So here's a rough overview of what's going on: The current ALSA mixer APIs have been criticized in the past (including by me) for their complexity and stacking of abstraction layers. Some folks (including me) suggested reworking the ALSA mixer APIs to simplify the APIs. After doing my research I am not so sure anymore that this really would be of much benefit -- at least for software like PA. The reason for that is simply that PA has very specific needs on the mixer interfacing: we are only interested in a subset of the potential functionality: a) we want to do hw volume control when supported for a specific snd_pcm_t with good granularity and range, b) we want mute control, and c) we want to select the output/input port for a snd_pcm_t (i.e. line-in vs. mic/speaker vs. headset). And that's about it. We generally don't want to support any fancier setups even if the hardware would provide it: we don't want simulatenous output to multiple distinct outports, we want no hw mixing, we don't want to support legacy input sources such as CD/Phone/PCSpk..., no "3D" features, not even input feedback. OTOH PA can do stuff other clients cannot do, e.g. extending in softwre the capabilities of the hw if possible and sensible. e.g. we can extend the volume control range/granularity in software beyond the discrete steps the hw provides. It has been suggested to make queryable how mixer elements relate to each other via some mixer API, possibly using the HDA codec graph data. While that would be nice to have I believe that this information would be much more than PA could ever need, and also certainly not help simplicity of an API. I am hence not asking for that, what I do ask for however is that a couple of assumptions I make stay valid. (see below) Given that what PA needs and doesn't need is very different from the needs of almost all other applications needed further abstraction can happen in PA, and doesn't need to be done in ALSA. Which is basically the reason why I decided to do all this mixer abstraction work inside of PA, instead of trying to get that into ALSA. To be able to control more than just one element, PA needs to have some minimal clue how elements are related to each other. ALSA (as mentioned) currently doesn't provide that info, so PA must guess. Hardcoding assumptions about how mixer elements relate to each other of course sucks, which is why I chose to define the list of elements PA should control plus minimal information about how they work together in config files that can be updated more easily and that during runtime. I tried to encode only minimal and the most obvious assumptions. These config files simply list a series of (simple) mixer controls and the way how to initialize them/expose them in PA. Switches can either be bound to always off or on, or be used to follow PA's mute status, or be exposed as distinct options in the UI (which however almost no switch should do). Volumes can either be bound to the minimal values, or to 0dB or be integrated into the volume slider PA exposes. Enumeration values can be exposed in the UI, too, but only if that makes sense. The most interesting part of that is probably the volume handling: for that we go from top to botton in the list of elements in those config files and try to set the volume on the first element marked for it, then divide the actual volume set from our target volume and find the next volume element and apply the remaining volume there, and so on. What's left we then do in attenuate software. All this mixer handling assumes that PA is the only one in charge of volume control. Also, I assume that while I now control a substantial part of the available mixer controls that those I don't control will be initialized properly by "alsactl init". Here's an example how that looks like, for implementing a Mic path (which is the most complex path, due to the input selection stuff) http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/modules/alsa/mixer/pa… http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/modules/alsa/mixer/pa… http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/modules/alsa/mixer/pa… To simplifiy these rules a bit I'd like to see some cleanups in the names used for controls: - Some drivers have a "Input Source Select" enumeration, others a "Input Source" and even others "Capture Source". These could be named the same, can't they? Or is there any difference in their behaviour from an apps PoV? (There's also a "Mic Select" enum, which however probably makes sense to keep seperate given that it the name suggests it is only useful if "Mic" is activated in a capture group) - The options of said enums are really chaotically named. That could really be cleaned up, and would probably be a trivial fix. - Since the various "boost" switches effectively control the volume I'd prefer if they'd be exposed as volume controls with dB info attached. Some Boosts encode the dB info in the name, which sucks. - Some cards have an element "TV Tuner", others "Video". I think that could be merged. I'll prepare a patch for at least some of these suggestions. Of course renaming controls on a big scale will break alsactl restore. Is that a problem? There's one assumption I am currently encoding in the files I am not really sure about. Which is that I assume that the volume level of the surround outputs is influenced by the following volume elements if that they exist: PCM -> Master -> Front, Rear, Surround, Side, Center, LFE while if switched to headphones I assume: PCM -> Master -> Headphone May I assume that? Or is sometimes the routing PCM -> Headphones, and 'Master' does not have influence? There's something else I was wondering, in contrast to the usual code that makes use of the ALSA mixer's dB data I use them to do actual calculations while previously they were just used for "enriching" the information shown on the screen. I wonder if this is going to backfire? How reliable is the dB data actually? [1] For more information on how all this really works you might find this mail I posted to the PA ML interesting: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004229.html It goes more into details in things which are relevant for PA folks, probably not so much for the ALSA folks. I'd be very interested in opinions on all of this! Thanks, Lennart [1] To verify and measure the dB data I actually wrote a little tool that can measure the data, which seemed to yield quite correct information on my HDA chip: http://git.0pointer.de/?p=dbmeasure.git;a=tree http://git.0pointer.de/?p=dbmeasure.git;a=blob;f=README -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 1

[alsa-devel] Why analog loopback of sigmatel devices got removed?
by Maxim Levitsky 20 Jun '09

20 Jun '09

Hi, Due to lack of time, I didn't update kernel on my desktop system. Now I notice that analog loopback go removed. Why? Searching around I found this: http://article.gmane.org/gmane.linux.alsa.devel/59878 * Removed analog loopback mixer items, not mentioned in sigmatel datasheets and reported to break sound support. First they are mention. It took me lot of time to find them. I only have added the loopback items for devices that have this feature in datasheet. Then how it can break sound support? could you explain? I need this feature since I use it with my TV card, and I know more users that use that feature. I don't know about other devices, but I attach the my patch that was included in kernel for this feature. Best regards, Maxim Levitsky

3 13

[alsa-devel] [Bug] ICE1712 analog outputs are unusable
by Peter Lawler 20 Jun '09

20 Jun '09

http://mailman.alsa-project.org/pipermail/alsa-devel/2009-January/014108.ht… https://bugzilla.redhat.com/show_bug.cgi?id=499435 http://mailman.alsa-project.org/pipermail/alsa-devel/2009-June/018616.html The original patch to fix this was declined and thus the issue has been left to fester. I'm available to help test out any new patch proposals etc. Please don't hesitate to contact me etc. Pete.

1 0

[alsa-devel] IDT quirks...where?
by Adam Williamson 20 Jun '09

20 Jun '09

Hi, guys. Following up a Fedora forum quirk report: http://forums.fedoraforum.org/showpost.php?p=1229209&postcount=16 elsewhere in the thread, the reporter is instructed to try the hp-dv5 model parameter, and reports that this works. The alsa-info output shows the subsystem ID as 103c:3621, and the codec as IDT 92HD71B7X. This is one I haven't seen before. I wanted to write up a bug report with a patch to add a quirk for this chipset, but I can't see which of the quirk files it should go into - none of the patch_*.c files seems to cover IDT codecs. What's the story with these? Where do their quirks go? Does current ALSA have one already? (I did try searching through each of the patch_*.c files for 3621 and found nothing, but I may have missed something). Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

2 2

[alsa-devel] LSB inclusion of ALSA
by Robert Schweikert 19 Jun '09

19 Jun '09

Hi, Currently ALSA is a trial use module for LSB (http://www.linuxfoundation.org/collaborate/workgroups/lsb) 4.0 and it is the intention to make ALSA mandatory with the LSB 4.1 release targeted for Q1 2010. One of the requirements of a mandatory module is the existence of a test suite for the module that covers a good chunk of the interfaces provided by the LSB spec. An initial exploratory look at the existing test cases showed that tests appear to be tied to hardware drivers and are interactive. Is this initial impression correct? _From an LSB testing perspective, interface testing is very important; i.e. I call the interface with the arguments required and I get the expected result back. Further the tests need to run in an automated fashion and produce a certain output (automated processing). The output can be created by retrofitting existing tests or by specifically writing tests within the LSB test framework. IMHO it would be best to have tests that are useful to both, the project and the LSB and in a best case scenario we wouldn't have to start over as the existing tests already cover a good part of the interface. With this as background there are a few questions that have been raised while discussing this during LSB workgroup sessions. 1.) Is there interest from the community side to participate in this effort and accept patches? 2.) Is it reasonable to expect that the existing tests can be used in some way by using a dummy sound device or a sound loop device to verify output? One requirement for LSB testing is that a test has only two states, pass or fail, and a recovery or try again mode is not supported. Further a test must pass or fail. 3.) Would the community be more comfortable if this is an effort that creates new tests separate from the existing HW focused tests? 4.) Is anyone interested in helping with this effort, writing tests, answering questions about ALSA for those not familiar with the interface and or sound in general? Comments, thoughts, etc. are much appreciated. Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Software Engineer Consultant LINUX rschweikert(a)novell.com 781-464-8147 Novell Making IT Work As One

4 8

Re: [alsa-devel] Laptop (Samsung Q45) speakers unmute when master channel is unmuted even with headphones connected
by Takashi Iwai 19 Jun '09

19 Jun '09

At Fri, 19 Jun 2009 11:56:29 +0100, Sam Morris wrote: > > On Thu, 2009-05-07 at 17:11 +0200, Takashi Iwai wrote: > > At Tue, 05 May 2009 11:58:39 +0100, > > Sam Morris wrote: > > > > > > On Tue, 2009-05-05 at 12:47 +0200, Takashi Iwai wrote: > > > > At Sat, 2 May 2009 13:14:42 +0100, > > > > Sam Morris wrote: > > > > > > > > > > Since Linux 2.6.28 and through to 2.6.30-rc4, the hda-intel driver has had a > > > > > bug on my laptop (a Samsung Q45). > > > > > > > > > > If I connect my headphones, the laptop's internal speakers are muted--fine. But > > > > > if I then mute and unmute the master mixer channel, the speakers come back to > > > > > life, even though the headphones are still connected. > > > > > > > > Could you run alsa-info.sh with --no-upload option, and attach the > > > > generated file? > > > > > > Here you go! > > > > Thanks. > > > > What if you use model=auto option? > > This is fixed in 2.6.30, but only if I use the model=auto option. :) What about with the later version, e.g. Linus git tree? Or you can use sound git tree git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git I think this was already fixed there. Takashi

1 0

Re: [alsa-devel] [PATCH] New ASoC Drivers for ADI AD1938 codec
by Liam Girdwood 19 Jun '09

19 Jun '09

On Fri, 2009-06-19 at 17:28 +0800, Barry Song wrote: > 1. add AD1938 codec driver (codec) > 2. add blackfin SPORT-TDM DAI and PCM driver (platform) > 3. add bf5xx board with AD1938 driver (machine) > Signed-off-by: Barry Song <21cnbao(a)gmail.com> > --- > include/sound/soc-dai.h | 1 + > sound/soc/blackfin/Kconfig | 46 +++- > sound/soc/blackfin/Makefile | 6 + > sound/soc/blackfin/bf5xx-ad1938.c | 178 ++++++++++++ > sound/soc/blackfin/bf5xx-tdm-pcm.c | 330 ++++++++++++++++++++++ > sound/soc/blackfin/bf5xx-tdm-pcm.h | 21 ++ > sound/soc/blackfin/bf5xx-tdm.c | 295 +++++++++++++++++++ > sound/soc/blackfin/bf5xx-tdm.h | 14 + > sound/soc/codecs/Kconfig | 4 + > sound/soc/codecs/Makefile | 2 + > sound/soc/codecs/ad1938.c | 548 ++++++++++++++++++++++++++++++++++++ > sound/soc/codecs/ad1938.h | 68 +++++ > 12 files changed, 1512 insertions(+), 1 deletions(-) > create mode 100644 sound/soc/blackfin/bf5xx-ad1938.c > create mode 100644 sound/soc/blackfin/bf5xx-tdm-pcm.c > create mode 100644 sound/soc/blackfin/bf5xx-tdm-pcm.h > create mode 100644 sound/soc/blackfin/bf5xx-tdm.c > create mode 100644 sound/soc/blackfin/bf5xx-tdm.h > create mode 100644 sound/soc/codecs/ad1938.c > create mode 100644 sound/soc/codecs/ad1938.h > Could you break this patch into smaller chunks. This should make it easier to review and apply. Thanks Liam

1 1

[alsa-devel] RFC: new TLV types for dB range with min/max
by Takashi Iwai 19 Jun '09

19 Jun '09

Hi, while I was checking bug reports regarding USB mixer dB ranges, I found that my old code might not work always properly. In usbmixer.c, /* USB descriptions contain the dB scale in 1/256 dB unit * while ALSA TLV contains in 1/100 dB unit */ scale[2] = (convert_signed_value(cval, cval->min) * 100) / 256; scale[3] = (convert_signed_value(cval, cval->res) * 100) / 256; Since the step size may have a rounding error, this can accumulate to a significant amount at the max value. A simple way to avoid this is to just give min and max values instead of min and step values, and interpolate the middle. For that, I create two new TLV types. Why two? Since the mute bit can't be packed into an integer (the dB range can be both positive and negative values) unlike the step size, I provided here both with and without mute, thus two. The kernel patch is attached below. This and a patch to usb-audio can be found in topic/tlv-minmax branch of sound-unstable GIT tree. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git topic/tlv-minmax I already wrote and test it with the modified alsa-lib, and the result looks good. If anyone has suggestions or objections to this, please let me know. If this change is OK, I'm going to merge this later for the next, 2.6.32 kernel. thanks, Takashi --- From 085f30654175a91c28d2b66b9ea6cceab627fed0 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Tue, 16 Jun 2009 13:57:07 +0200 Subject: [PATCH] ALSA: Add new TLV types for dBwith min/max Add new types for TLV dB scale specified with min/max values instead of min/step since the resolution can't match always with the one a device provides. For example, usb audio devices give 1/256 dB resolution while ALSA TLV is based on 1/100 dB resolution. The new min/max types have less problems because the possible rounding error happens only at min/max. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- include/sound/tlv.h | 14 ++++++++++++++ sound/core/vmaster.c | 8 ++++++-- 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/include/sound/tlv.h b/include/sound/tlv.h index d136ea2..9fd5b19 100644 --- a/include/sound/tlv.h +++ b/include/sound/tlv.h @@ -35,6 +35,8 @@ #define SNDRV_CTL_TLVT_DB_SCALE 1 /* dB scale */ #define SNDRV_CTL_TLVT_DB_LINEAR 2 /* linear volume */ #define SNDRV_CTL_TLVT_DB_RANGE 3 /* dB range container */ +#define SNDRV_CTL_TLVT_DB_MINMAX 4 /* dB scale with min/max */ +#define SNDRV_CTL_TLVT_DB_MINMAX_MUTE 5 /* dB scale with min/max with mute */ #define TLV_DB_SCALE_ITEM(min, step, mute) \ SNDRV_CTL_TLVT_DB_SCALE, 2 * sizeof(unsigned int), \ @@ -42,6 +44,18 @@ #define DECLARE_TLV_DB_SCALE(name, min, step, mute) \ unsigned int name[] = { TLV_DB_SCALE_ITEM(min, step, mute) } +/* dB scale specified with min/max values instead of step */ +#define TLV_DB_MINMAX_ITEM(min_dB, max_dB) \ + SNDRV_CTL_TLVT_DB_MINMAX, 2 * sizeof(unsigned int), \ + (min_dB), (max_dB) +#define TLV_DB_MINMAX_MUTE_ITEM(min_dB, max_dB) \ + SNDRV_CTL_TLVT_DB_MINMAX_MUTE, 2 * sizeof(unsigned int), \ + (min_dB), (max_dB) +#define DECLARE_TLV_DB_MINMAX(name, min_dB, max_dB) \ + unsigned int name[] = { TLV_DB_MINMAX_ITEM(min_dB, max_dB) } +#define DECLARE_TLV_DB_MINMAX_MUTE(name, min_dB, max_dB) \ + unsigned int name[] = { TLV_DB_MINMAX_MUTE_ITEM(min_dB, max_dB) } + /* linear volume between min_dB and max_dB (.01dB unit) */ #define TLV_DB_LINEAR_ITEM(min_dB, max_dB) \ SNDRV_CTL_TLVT_DB_LINEAR, 2 * sizeof(unsigned int), \ diff --git a/sound/core/vmaster.c b/sound/core/vmaster.c index 257624b..3b9b550 100644 --- a/sound/core/vmaster.c +++ b/sound/core/vmaster.c @@ -353,7 +353,8 @@ static void master_free(struct snd_kcontrol *kcontrol) * * The optional argument @tlv can be used to specify the TLV information * for dB scale of the master control. It should be a single element - * with #SNDRV_CTL_TLVT_DB_SCALE type, and should be the max 0dB. + * with #SNDRV_CTL_TLVT_DB_SCALE, #SNDRV_CTL_TLV_DB_MINMAX or + * #SNDRV_CTL_TLVT_DB_MINMAX_MUTE type, and should be the max 0dB. */ struct snd_kcontrol *snd_ctl_make_virtual_master(char *name, const unsigned int *tlv) @@ -384,7 +385,10 @@ struct snd_kcontrol *snd_ctl_make_virtual_master(char *name, kctl->private_free = master_free; /* additional (constant) TLV read */ - if (tlv && tlv[0] == SNDRV_CTL_TLVT_DB_SCALE) { + if (tlv && + (tlv[0] == SNDRV_CTL_TLVT_DB_SCALE || + tlv[0] == SNDRV_CTL_TLVT_DB_MINMAX || + tlv[0] == SNDRV_CTL_TLVT_DB_MINMAX_MUTE)) { kctl->vd[0].access |= SNDRV_CTL_ELEM_ACCESS_TLV_READ; memcpy(master->tlv, tlv, sizeof(master->tlv)); kctl->tlv.p = master->tlv; -- 1.6.3.2

2 1