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

[alsa-devel] plughw vs default / per-application volume changer
by antony k 09 Aug '12

09 Aug '12

Hello, I am new to ALSA and I cant figure out 2 things. a) if and why should I prefer the "plughw:0,0" over the "default" device name. I am developing a simple audio player which is based on the latter. I made this choice because when I was using plughw:0,0 with other audio programs(flash player,vlc) open in the background I would get the "Device is busy" error code. With default, it's fine. b) can I have an application specific volume changer? So far I have managed to tweak the master volume of the "default" device which has a global effect. Im guessing a) and b) are connected. Thanks for your time

2 1

Re: [alsa-devel] adding an external dsp under soc-dsp framework
by Mark Brown 09 Aug '12

09 Aug '12

On Wed, Aug 08, 2012 at 10:49:19PM +0300, Ziv Haziz wrote: > Looking at the littlemill driver on kernel 3.4.7 the device name > "Baseband" and his dai link doesn't contain platform device can be > triggered without side effects? Yes, this is the most common case for DAI links that don't involve a CPU in modern smartphones.

1 0

Re: [alsa-devel] [PATCH 3/4] ARM: OMAP3: Switch to use the unified audio driver (omap-twl4030) for selected boards
by Peter Ujfalusi 09 Aug '12

09 Aug '12

On 08/08/2012 04:06 PM, Igor Grinberg wrote: > Well, yes I know we will need to adjust the user space. > I wanted to change that for a long time and did not get to it... > Now, with your patches, it seems like the best time for doing this. Done for the v2. You will have card named "cm-t3x". -- Péter

1 0

[alsa-devel] [PATCH] ALSA: hda - Fix pop noise in headphones on S3 for Asus X55A, X55V
by David Henningsson 09 Aug '12

09 Aug '12

To turn off pin control for the pin was tested, and helped against this issue. BugLink: https://bugs.launchpad.net/bugs/1034779 Tested-by: Chih-Hsyuan Ho <chih.ho(a)canonical.com> Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_via.c | 8 ++++++++ 1 file changed, 8 insertions(+) Alsa-info at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1034779/+attachment/32… diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 80d90cb..c9484fe 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1752,6 +1752,14 @@ static int via_suspend(struct hda_codec *codec) { struct via_spec *spec = codec->spec; vt1708_stop_hp_work(spec); + + if (spec->codec_type == VT1802) { + /* Fix pop noise on headphones */ + int i; + for (i = 0; i < spec->autocfg.hp_outs; i++) + snd_hda_set_pin_ctl(codec, spec->autocfg.hp_pins[i], 0); + } + return 0; } #endif -- 1.7.9.5

2 1

[alsa-devel] [PATCH] ALSA: hda - Fix pop noise in headphones on S3 for Asus X55A, X55V
by David Henningsson 09 Aug '12

09 Aug '12

To turn off pin control for the pin was tested, and helped against this issue. BugLink: https://bugs.launchpad.net/bugs/1034779 Tested-by: Chih-Hsyuan Ho <chih.ho(a)canonical.com> Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_via.c | 8 ++++++++ 1 file changed, 8 insertions(+) Alsa-info at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1034779/+attachment/32… diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 80d90cb..c9484fe 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1752,6 +1752,14 @@ static int via_suspend(struct hda_codec *codec) { struct via_spec *spec = codec->spec; vt1708_stop_hp_work(spec); + + if (spec->codec_type == VT1802) { + /* Fix pop noise on headphones */ + int i; + for (i = 0; i < spec->autocfg.hp_outs; i++) + snd_hda_set_pin_ctl(codec, spec->autocfg.hp_pins[0], 0); + } + return 0; } #endif -- 1.7.9.5

2 2

[alsa-devel] [PATCH] ALSA: hda/realtek - Keep analog bypass muted on ALC892
by Thierry Reding 09 Aug '12

09 Aug '12

Unmuting the analog bypass causes any input to be directly bypassed to the outputs, which is usually not expected by the user. Signed-off-by: Thierry Reding <thierry.reding(a)avionic-design.de> --- Note that this patch could be generalized to include all codec variants that have this second channel. As I don't have access to all the data sheets I'll leave that decision up to somebody with more hardware available. sound/pci/hda/patch_realtek.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 4f81dd4..54d0917 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -3752,8 +3752,15 @@ static void alc_auto_set_output_and_unmute(struct hda_codec *codec, if (nid_has_mute(codec, mix, HDA_INPUT)) { snd_hda_codec_write(codec, mix, 0, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)); - snd_hda_codec_write(codec, mix, 0, AC_VERB_SET_AMP_GAIN_MUTE, - AMP_IN_UNMUTE(1)); + /* + * On ALC892, the second entry in the connection list is the + * analog bypass. Unmuting it will cause any inputs to be + * directly forwarded to the corresponding outputs. + */ + if (codec->subsystem_id != 0x10ec0892) + snd_hda_codec_write(codec, mix, 0, + AC_VERB_SET_AMP_GAIN_MUTE, + AMP_IN_UNMUTE(1)); } /* initialize volume */ nid = alc_look_for_out_vol_nid(codec, pin, dac); -- 1.7.11.4

2 4

Re: [alsa-devel] [PATCH V4 12/16] ALSA: HDA: Make hda sound card usable for Loongson.
by Takashi Iwai 09 Aug '12

09 Aug '12

At Thu, 9 Aug 2012 11:35:15 +0800, Chen Jie wrote: > > Hi, > > 2012/8/3 Takashi Iwai <tiwai(a)suse.de>: > > At Fri, 3 Aug 2012 18:36:40 +0800, > > Huacai Chen wrote: > >> > >> We write these quirks on 2.6.36 some time ago, and then we port them > >> to 3.x (3.2, 3.3, 3.4 and 3.5). As you say, PMON (BIOS for Loongson) > >> doesn't set the pins correctly. Anyway, I'll try your suggestions. > > > > Thanks. I guess it should work by just adding a new entry for your > > device in cxt_fixups[] containing the right default pin-configuration > > table, then point it in cxt5066_fixups[] with the corresponding PCI > > (or codec) SSID. > > > > > > Takashi > > I've found it is a little difficult to get proper pincfg values. The > original patch builds 'input/output path' manually, the new way does > it automatically as long as providing proper pincfgs for 'end points'. > > I tried to copy related pincfgs from a workable lemote a1004 > laptop(kernel with the original patch, read from > /proc/asound/card0/codec#0), didn't help much. It doesn't help because your old patch doesn't change the default pin-configuration values. It changes the pin-control values or amp values, but not the former one. > I guess the pincfgs are not correct, and on the platform, the pincfgs > are not touched by BIOS, so I have to calculate proper pincfgs, how? Just follow the HD-audio specification :) > HDA spec explains a pincfg as four bytes. For each byte, it has bits > indicate amp/in/out/vref/ept. No, you are referring to pin control bits. This has nothing to do with the pin default configuration. You must misunderstand the spec completely. Read section 7.3.3.31 (page 179) for details. Takashi > In the kernel side, it reads a pincfg and explains it as a 32bits > flag, indicating > connect/location/device/jack_connect_type/jack_color/misc/association/sequence. > > Why they differ? How to get proper pincfg values? > > > > Regards, > -- Chen Jie >

1 0

[alsa-devel] hw_params ignores ioplug's buffer size requirements
by Andrew Eikum 08 Aug '12

08 Aug '12

Hi folks, I've got either a bug or a misunderstanding in how ALSA handles ioplugs that provide hw_params restrictions. My understanding is that the snd_pcm_ioplug_set_param_* functions are supposed to restrict which hw_params settings a client may set. This seems to work for at least access and format. But I noticed that it's broken for buffer_bytes and periods at least. Attached is two source files demonstrating the problem. alsa-example.c is a dead-simple ioplug module. It sets some hw_params restrictions, and does basically nothing else. The important thing to notice is that it sets /only one/ allowable period size, period count, and buffer size, all of which are compatible with each other (256 byte period * 8 periods == 2048 byte buffer size). There is also test client, alsa-test.c, which attempts to violate those hw_params restrictions, and succeeds! The eventual call to the ioplug's example_hw_params() callback gets an invalid buffer_size parameter (it happens to be 512). Here is the output when run on my Arch Linux with alsa-lib 1.0.25: [aeikum@aeikum ioplug_buffer_bytes]$ ./alsa-test ALSA-example: Opening bytes: 512 ALSA-example: hw_params: 512 TEST FAILURE: buffer_size != 8812: 512 ALSA-example: stop ALSA-example: close [aeikum@aeikum ioplug_buffer_bytes]$ Am I misunderstanding the snd_pcm_ioplug_set_param_* methods, or is this a bug? I am seeing this behavior in the wild with a pulseaudio client that ignores my hw_params restrictions. Thanks for any insight, Andrew

2 2

[alsa-devel] [PATCH] test/latency.c: Fix string argument to getopt_long, so now it handles -E and -B
by Mario Domenech Goulart 08 Aug '12

08 Aug '12

Hi, Attached is a small patch for alsa-lib's test/latency.c to fix command line arguments handling. Best wishes. Mario -- http://parenteses.org/mario

2 1

Re: [alsa-devel] DT support for Davinci ASoC platform
by Daniel Mack 08 Aug '12

08 Aug '12

Hi Serkar, On 03.08.2012 11:09, Sekhar Nori wrote: > On 8/3/2012 2:02 AM, Daniel Mack wrote: >> On 05.07.2012 12:58, Daniel Mack wrote: >>> Hi Gururaja, >>> >>> On 04.07.2012 14:48, Hebbar, Gururaja wrote: >>>> All, >>>> >>>> Are there any plans or work going on for providing Device Tree Support for Davinci >>>> ASoC? >>>> >>>> I am planning to add DT support for TI AM335x (McASP) and I don't want to do duplicate >>>> task. >>> >>> That's good to know. But isn't there a dependency on the EDMA engine? Is >>> that part ported yet? >> >> May I ask whether you made any progress on that yet? > > Matt Porter from TI is working on DMA engine migration. This would still > be some time away since there is a bunch of work involved here. > > To make progress on Audio DT conversion Gururaja is doing an up port of > AM335x EDMA support from TI release to mainline kernel. If you are > interested in it, he can probably share that with you once he posts his > DT patches. As the DMA engine is also a requirement for the MMC controller, I would be interested in helping, in case help is required. Is there any repository with code that I can have a look at? Thanks, Daniel

1 0