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

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

[alsa-devel] [PATCH] New snd-hda-intel model/pin config for hp dv7-4000
by Steven Eastland 09 Aug '10

09 Aug '10

This provides a new model and pin config for the snd-hda-intel 92HD83XXX codec for hp laptop model dv7-4000, enabling the subwoofer. Signed-off-by: Steven Eastland <seastland at gmail.com> --- --- alsa-kernel/pci/hda/patch_sigmatel.c 2010-07-20 14:06:12.000000000 -0600 +++ alsa-kernel/pci/hda/patch_sigmatel.c 2010-07-26 13:04:55.000000000 -0600 @@ -94,6 +94,7 @@ STAC_92HD83XXX_PWR_REF, STAC_DELL_S14, STAC_92HD83XXX_HP, + STAC_HP_DV7_4000, STAC_92HD83XXX_MODELS }; @@ -1628,10 +1629,17 @@ 0x40f000f0, 0x40f000f0, }; +static unsigned int hp_dv7_4000_pin_configs[10] = { + 0x03a12050, 0x0321201f, 0x40f000f0, 0x90170110, + 0x40f000f0, 0x40f000f0, 0x90170110, 0xd5a30140, + 0x40f000f0, 0x40f000f0, +}; + static unsigned int *stac92hd83xxx_brd_tbl[STAC_92HD83XXX_MODELS] = { [STAC_92HD83XXX_REF] = ref92hd83xxx_pin_configs, [STAC_92HD83XXX_PWR_REF] = ref92hd83xxx_pin_configs, [STAC_DELL_S14] = dell_s14_pin_configs, + [STAC_HP_DV7_4000] = hp_dv7_4000_pin_configs, }; static const char *stac92hd83xxx_models[STAC_92HD83XXX_MODELS] = { @@ -1640,6 +1648,7 @@ [STAC_92HD83XXX_PWR_REF] = "mic-ref", [STAC_DELL_S14] = "dell-s14", [STAC_92HD83XXX_HP] = "hp", + [STAC_HP_DV7_4000] = "hp-dv7-4000", }; static struct snd_pci_quirk stac92hd83xxx_cfg_tbl[] = {

2 2

[alsa-devel] codec support request: Conexant ID 5068
by Cristopher Camacho Leandro 09 Aug '10

09 Aug '10

Hi all, The codec (Conexant ID 5068) required by my sound card (Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)) is not present yet in ALSA, I would highly appreciate if you guys could add support for it. You guys might find the information collected by the alsa-info.sh script on http://www.alsa-project.org/db/?f=8f8001d873d5c10c293eac1c94f2ede0b73cd865 Thanks a lot in advance for looking into this. Cheers, Cristopher

3 5