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

[alsa-devel] additional problem
by David Henderson 22 Jul '11

22 Jul '11

Hi gang! I've successfully been able to compile the alsa-utils package with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having now is that the compiled binaries are looking for those directories during run-time and not just compile-time. Does anyone have any thoughts on using those directories for package creation, but that the software doesn't use the '/opt/staging/alsa' prefix during run-time? Thanks, Dave

4 25

[alsa-devel] [PATCH V2 0/4] Add Samsung internal dma driver support
by Sangbeom Kim 21 Jul '11

21 Jul '11

I2S in samsung audio subsytem has a small internal dma(idma). IDMA can be used in low power audio mode and I2S0 secondary fifo data tranfer. In this patchsets, idma driver is added. Original code is made by jassi brar on SMDKV210 After idma driver merge, I will submit low power audio support with idma driver and samsung dsp driver. Changes since v1: 1. Change idma_new by new pcm_new api 2. Add handling different idma address 3. As jassi comments, Modify the idma driver This patchset contains followings o To Jassi Brar, Mark Brown and Liam Girdwood, [PATCH V2 1/4] ASoC: SAMSUNG: Modify I2S driver to support idma [PATCH V2 2/4] ASoC: SAMSUNG: Add I2S0 internal dma driver o To Kukjin Kim [PATCH V2 3/4] ARM: SAMSUNG: Add platform device for idma [PATCH V2 4/4] ARM: SAMSUNG: Add IRQ_I2S0 definition Thanks SB Kim

4 8

Re: [alsa-devel] model needed for Clevo P150HM (Realtek ALC892)
by Takashi Iwai 18 Jul '11

18 Jul '11

At Thu, 30 Jun 2011 08:30:10 +0200, Julian Sikorski wrote: > > W dniu 30.06.2011 07:26, Takashi Iwai pisze: > > At Wed, 29 Jun 2011 21:29:38 +0200, > > Julian Sikorski wrote: > >> > >> I also tried merging sound-2.6/master with Linus's tree, but this also > >> did not help. > > > > It's really strange. Are you sure that this is the kernel you > > modified properly? Before further debugging, check two things: > > > > - Run "git log sound/pci/hda/patch_realtek.c" and the first few > > entries, whether they come from sound git tree. For example, > > check the commit below is contained: > > > > commit 7ec9c6ccc6007b14a916021d4ba7ffbcc7822ae3 > > Author: Takashi Iwai <tiwai(a)suse.de> > > Date: Mon Jun 27 15:53:38 2011 +0200 > > > > ALSA: hda - Fix volume-init for ALC259 with invalid widget caps > > commit 0b0c8490670a77b937f502491ae9d5236aa4054a > Author: Takashi Iwai <tiwai(a)suse.de> > Date: Tue Jun 28 12:45:47 2011 +0200 > > ALSA: hda - Create snd_hda_get_conn_index() helper function > > Create snd_hda_get_conn_index() helper function for obtaining the > connection index of the widget. Replaced the similar codes used in > several codec-drivers with this common helper. > > Signed-off-by: Takashi Iwai <tiwai(a)suse.de> > > commit 4f574b7b1a1cc8aac617e938459e8f03a641e678 > Author: Takashi Iwai <tiwai(a)suse.de> > Date: Mon Jun 27 16:17:07 2011 +0200 > > ALSA: hda - More volume-init fixes for ALC267 codec > > More similar fixes like previous commits: handle the exceptional case > like ALC267 where no volume amp is found in ADC widget but in the > capsrc widget instead. > > Also minor checks for avoiding possible erros: no connection-select > when the pin has a single selection, and add beep verbs only when the > 0x1d is used for beep. > > Signed-off-by: Takashi Iwai <tiwai(a)suse.de> > > To be even more sure, I re-synced your branch again and built a new > kernel. I am attaching patch_realtek.c file being built. Fresh > alsa-info.sh is here: > http://www.alsa-project.org/db/?f=5051b2cb788b1db4273e06e98a78783dd0ec679f OK, then it's correct. > > > > - Confirm the running kernel is what you really built and installed. > > You can modify the suffix via $CONFIG_LOCALVERSION in .config file. > > Name it uniquely, rebuild, re-install and reboot. The new suffix > > should appear in the output of "uname -r". > > belegdol4 is the suffix I added: > $ uname -r > 3.0-0.rc5.git0.1.belegdol4.fc15.x86_64 > > > - Once when these are correct, check /proc/asound/card0/codec#0: > > the widget NID 0x02 should contain "Speaker Playback Volume" instead > > of "Headphone Playback Volume" with the latest driver. > > Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out > Control: name="Headphone Playback Volume", index=0, device=0 > > Perhaps I need to specify a correct model to enable this code? No, you shouldn't pass any model option. Could you apply the patch below to add some debug prints, and give the relevant kernel messages you get? Just grep lines with 'XXX'. Takashi --- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 7b96dce..3134555 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -18770,8 +18770,10 @@ static hda_nid_t alc_auto_look_for_dac(struct hda_codec *codec, hda_nid_t pin) static hda_nid_t get_dac_if_single(struct hda_codec *codec, hda_nid_t pin) { hda_nid_t sel = alc_go_down_to_selector(codec, pin); - if (snd_hda_get_conn_list(codec, sel, NULL) == 1) + if (snd_hda_get_conn_list(codec, sel, NULL) == 1) { + printk(KERN_DEBUG "XXX pin %x coupled with a single DAC\n", pin); return alc_auto_look_for_dac(codec, pin); + } return 0; } @@ -18783,6 +18785,7 @@ static int alc662_auto_fill_dac_nids(struct hda_codec *codec) bool redone; int i; + printk(KERN_DEBUG "XXX alc662_auto_fill_dac_nids called\n"); again: spec->multiout.num_dacs = 0; spec->multiout.hp_nid = 0; @@ -18813,6 +18816,7 @@ static int alc662_auto_fill_dac_nids(struct hda_codec *codec) * checking the hard-wired DACs */ redone = true; + printk(KERN_DEBUG "XXX redoing...\n"); goto again; } } @@ -18826,6 +18830,17 @@ static int alc662_auto_fill_dac_nids(struct hda_codec *codec) sizeof(hda_nid_t) * (cfg->line_outs - i - 1)); } + printk(KERN_DEBUG "XXX filled dacs: %x/%x/%x/%x/%x, hp %x, ext %x/%x/%x\n", + spec->private_dac_nids[0], + spec->private_dac_nids[1], + spec->private_dac_nids[2], + spec->private_dac_nids[3], + spec->private_dac_nids[4], + spec->multiout.hp_nid, + spec->multiout.extra_out_nid[0], + spec->multiout.extra_out_nid[1], + spec->multiout.extra_out_nid[2]); + return 0; } @@ -18877,6 +18892,7 @@ static int alc662_auto_create_multi_out_ctls(struct hda_codec *codec, mix = alc_auto_dac_to_mix(codec, pin, nid); if (!mix) continue; + printk(KERN_DEBUG "XXX create mixer ch %d pin %x dac %x mix %x\n", i, pin, nid, mix); name = alc_get_line_out_pfx(spec, i, true, &index); if (!name) { /* Center/LFE */ @@ -19026,6 +19042,7 @@ static int alc_auto_fill_multi_ios(struct hda_codec *codec, dac = alc_auto_look_for_dac(codec, nid); if (!dac) continue; + printk(KERN_DEBUG "XXX added multi-io pin %x, dac %x\n", nid, dac); spec->multi_io[num_pins].pin = nid; spec->multi_io[num_pins].dac = dac; num_pins++; @@ -19128,6 +19145,7 @@ static int alc_auto_add_multi_channel_mode(struct hda_codec *codec, if (cfg->line_out_type == AUTO_PIN_SPEAKER_OUT && cfg->hp_outs == 1) { /* use HP as primary out */ + printk(KERN_DEBUG "XXX swap primary out to HP\n"); cfg->speaker_outs = cfg->line_outs; memcpy(cfg->speaker_pins, cfg->line_out_pins, sizeof(cfg->speaker_pins));

3 37

[alsa-devel] Major reworks on patch_via.c (TESTERS WANTED)
by Takashi Iwai 15 Jul '11

15 Jul '11

Hi, as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it. The current development is found in sound git tree topic/via-cleanup branch: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git You can pull into the latest Linus tree from topic/via-cleanup branch: # this is the vanilla tree % cd linux-2.6 % git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \ topic/via-cleanup A good thing is that a fair amount of code reduction is done there: % git diff HEAD..topic/via-cleanup --stat sound/pci/hda/patch_via.c sound/pci/hda/patch_via.c | 5892 +++++++++++---------------------------------- 1 files changed, 1453 insertions(+), 4439 deletions(-) But, the driver isn't tested with real machines, yet. That is, I need testers with real machines. Could VIA machine owners take a look at these commits and test it if possible? Especially, I'd like to know whether the headphone auto-mute works in this form or not. FWIW, the branch was merged to sound-unstable tree, so you can build from alsa-driver-unstable snapshot tarball if you'd like to build external modules without the kernel tree and git-merge. ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-uns… Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me know. It'd be very helpful for debugging, since I can check it via hda-emu with alsa-info.sh output. For now, I have the files of only VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs. The alsa-info.sh outputs of other VIA codecs would be greatly appreciated. thanks, Takashi

5 18

[alsa-devel] What is correct way to put conditional stuff in ASoC codec driver?
by Ashish Chavan 11 Jul '11

11 Jul '11

Hi, I am working on updating ASoC codec driver for Dialog's DA7210 codec (sound/soc/codec/da7210.c). This update would be a major functionality update in nature. In fact we already have a feature complete driver for this codec but there are two main issues with that driver, (1) It was developed(and tested) for a quite old kernel version (2.6.28) (2) It was written in custom(non standard) way and not suitable for direct submission to kernel Our final goal is to pull in all missing features from this custom driver in to existing mainline driver. I have already created few patches for basic functions but I am bit confused at one point. Some of the features supported by this codec have inter dependency, e.g. ALC can be used only if NOISE SUPRESSION is disabled. So ideally, all controls related to ALC should be either disabled or not added at all, if NOISE SUPRESSION to be used. There are few other features having similar kind of dependency. I just want to know what is the correct way to handle this in ASoC codec driver? Looking at the existing codec drivers, it seems that having conditional defines is not common here. As We just want to support static configuration of such features, is it a good idea to add sub menu options in driver's Kconfig to enable/disable such features and use them within code? Any pointer(s) to existing code are most welcome. Thanks, -- Ashish ---------------------------------------------------------------------------- || Linux Is User Friendly, It's Just Selective About Who It's Friends Are || ----------------------------------------------------------------------------

2 11

[alsa-devel] [PATCH] Acer aspire 3830TG and Conexant 506c/20588
by David Henningsson 11 Jul '11

11 Jul '11

The new Conexant 5066 auto-parser is barely finished and already we might need a quirk system for it... Anyway, in this bug, the internal speaker is not working (and was not working before the auto-parser either). I'm attaching two patches that are quite simple, and at least the first one (add ID 506c) I think should be applied right away. The problem: The internal speaker is at node 0x1f and you need to turn on EAPD on node 0x1b for the speaker to sound. Now I'm not sure how to fix this in the best way. An "init verb" quirk, or a "use EAPD from this pin" quirk? Try to copy-paste realtek's quirk system, and if so, refactor it into hda_codec.c, or write something new? What are your ideas? Alsa-info reference: https://launchpadlibrarian.net/73966502/alsa-info Bug reference: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/783582 -- David Henningsson http://launchpad.net/~diwic

2 10

[alsa-devel] Jack event API - decision needed
by David Henningsson 09 Jul '11

09 Jul '11

Hi, I'm still new in the community in that sense that I'm not sure how decisions are made. But I could use the outcome of such a decision. Background: I'm trying to pull together the missing pieces of jack detection on both kernel / plumbing / application layers, so that when you plug something in (headset, microphone etc), userspace is notified and can take appropriate actions (e g routing decisions). As part of that I wrote a udev patch a few days ago, which nobody commented on in alsa-devel [1], but was somewhat disliked by at least Kay Sievers who maintains udev [2], who preferred we would rewrite our input layer to do something else within ALSA. So before I proceed further I'd like to know if 1) We're continuing the path with /dev/input devices 2a) We'll rewrite these devices to be read-only ALSA mixer controls 2b) We'll rewrite these devices to be something within ALSA, but not exactly mixer controls. For options 2a) and 2b) I guess the existing /dev/input thing should be deprecated and/or removed. So part of decision should maybe be based on information about how widespread the usage of these devices are currently...? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2011-June/040916.html [2] e g http://www.spinics.net/lists/hotplug/msg04949.html

10 42

[alsa-devel] [PATCH] ALSA: hda-intel - add position_fix quirk for Gateway NV53A
by Dmitry Torokhov 04 Jul '11

04 Jul '11

Without this option internal microphone does not seem to be working. $ lspci -vvnn | grep -A10 Audio 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383] (rev 40) Subsystem: Acer Incorporated [ALI] Device [1025:036e] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin ? routed to IRQ 16 Region 0: Memory at d2300000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: HDA Intel -- 01:05.1 Audio device [0403]: ATI Technologies Inc RS880 Audio Device [Radeon HD 4200] [1002:970f] Subsystem: Acer Incorporated [ALI] Device [1025:036e] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 19 Region 0: Memory at d2210000 (32-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Signed-off-by: Dmitry Torokhov <dtor(a)mail.ru> --- sound/pci/hda/hda_intel.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 486f6de..4fbcea6 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2349,6 +2349,7 @@ static int azx_dev_free(struct snd_device *device) static struct snd_pci_quirk position_fix_list[] __devinitdata = { SND_PCI_QUIRK(0x1025, 0x009f, "Acer Aspire 5110", POS_FIX_LPIB), SND_PCI_QUIRK(0x1025, 0x026f, "Acer Aspire 5538", POS_FIX_LPIB), + SND_PCI_QUIRK(0x1025, 0x036e, "Gateway NV53A", POS_FIX_LPIB), SND_PCI_QUIRK(0x1028, 0x01cc, "Dell D820", POS_FIX_LPIB), SND_PCI_QUIRK(0x1028, 0x01de, "Dell Precision 390", POS_FIX_LPIB), SND_PCI_QUIRK(0x1028, 0x01f6, "Dell Latitude 131L", POS_FIX_LPIB),

2 2

[alsa-devel] Roland UM-ONE support
by xl600＠teamspode.org 02 Jul '11

02 Jul '11

I am in need of adding UM-ONE support. I believe this interface is simply a repackaged UM-1G, but ALSA 1.0.17 simply won't recognize it. Being new to this level of development, any clues as to how to add this interface support would be welcome. I'd first like to start off by assuming it will work as a UM-1G. If it doesn't, then I'll have to dig deeper. Thanks, Robert

3 3

[alsa-devel] PCM DMA only can fire ISR when it receives 4 samples more than the period, from McBSP port?
by Philip Chu 01 Jul '11

01 Jul '11

HI, I got a problem with my audio capture using McBSP 3 port on OMAP 3530. Linux kernel 2.6.32. For the very first audio data capture, when I expect to receive only one exact period of data through McBSP, PCM DMA ISR never comes. When I check the DMA pointer by using snd_pcm_update_hw_ptr_pos(), I found it was just trash value. If I ask the data sender to send 4 samples more than the period defined, DMA ISR gets fired, the it points to the exact period position, and I assume the extra 4 bytes just get lost? My McBSP is configured as a slave which needs the sender to provide Frame Sync, clocks etc, and those signals are designed to just kick in at the same time. Do the clock signal need to be present earlier than the Frame Sync? Anybody knows what the issue could be? Thanks in advance. Philip Chu

3 5