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

Re: [alsa-devel] explicit commandline control of speakers vs headphone output
by Eric Holstege 27 Aug '10

27 Aug '10

Thanks for the info. (FYI, I have a Windtop 2200 All-in-one touchscreen, on which I'm building an appliance with, among other things, VOIP phone and answering machine capability). I want the user to be able to "put the call on speaker" even if the mic/headphone handset is plugged in. Can amixer override this automuting. Is it that the driver just sets the speakers to mute *at the time* the headphone is plugged in, or does it force them mute *so long as* the headphone is plugged in? Or, regarding the pin_configs possibility, I guess I somehow edit /sys/devices/pci0000:00/0000:00:08.0/sound/card0/hwC0D0/init_pin_configs (or maybe user_pin_configs?). Could one point me to documentation on what the bits mean? Mine are: 0x11 0x411111f0 0x12 0x411111f0 0x14 0x01014010 0x15 0x411111f0 0x16 0x99130120 0x17 0x411111f0 0x18 0x01a19850 0x19 0x99a3095f 0x1a 0x411111f0 0x1b 0x99130130 0x1c 0x411111f0 0x1d 0x4004022b 0x1e 0x01451140 0x1f 0x411111f0 Regards -Eric David Henningsson wrote: > 2010-08-27 20:46, Eric Holstege skrev: > >> Thanks, Clemens; >> >> How were you able to determine that from the "amixer scontents" output. >> >> Although I can't disable *automatic* speaker mute on headphone >> insertion, can I explicitly unmute them again (e.g. with amixer sset or >> cset)? >> >> If not.... >> "cat /proc/asound/card*/codec*" says it is the Realtek ALC888. >> Does this mean I have to somehow patch the kernel sound module file >> .../linux-source-2.6.*/sound/pci/hda/patch_realtek.c >> to fix this somehow? >> > > So in the long run, I think it would be better to leave all auto-muting > to userspace. Then stuff like pulseaudio could to advanced decision of > how to handle input events. But that's the long way. > > There are certainly ways to disable auto-muting for Realtek ALC888, look > along the lines of "speaker_automute" and "unsol_event". It is also > possible that you could tweak your user_pin_config to trick your HP out > into a Line Out. That way it won't automute, and you don't have to > recompile your kernel. > > As a side note: The VIA HDA driver, I believe, have an option for > turning automute off. But it also sets "mute" on a misnamed control at > the same time, tricking PA into believing that you want to mute all > output. So PA is "helpful" and mutes everything else as well. :-/ > >

1 0

Re: [alsa-devel] explicit commandline control of speakers vs headphone output
by Eric Holstege 27 Aug '10

27 Aug '10

Thanks, Clemens. Here it is: Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 31 Mono: Playback 19 [61%] [-18.00dB] [on] Simple mixer control 'Headphone',0 Capabilities: pswitch penum Playback channels: Front Left - Front Right Mono: Front Left: Playback [on] Front Right: Playback [on] Simple mixer control 'Speaker',0 Capabilities: pswitch penum Playback channels: Front Left - Front Right Mono: Front Left: Playback [on] Front Right: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 253 [99%] [0.40dB] Front Right: Playback 253 [99%] [0.40dB] Simple mixer control 'Front',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [0.00dB] [on] Front Right: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'Surround',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [0.00dB] [on] Front Right: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'Center',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 31 Mono: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'LFE',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 31 Mono: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'Line',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'CD',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 25 [81%] [3.00dB] [on] Front Right: Playback 25 [81%] [3.00dB] [on] Simple mixer control 'Mic',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Mic Boost',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 0 [0%] Front Right: 0 [0%] Simple mixer control 'IEC958',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [off] Simple mixer control 'IEC958 Default PCM',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'Beep',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 31 Front Left: Capture 25 [81%] [21.00dB] [on] Front Right: Capture 25 [81%] [21.00dB] [on] Simple mixer control 'Capture',1 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 31 Front Left: Capture 0 [0%] [-16.50dB] [on] Front Right: Capture 0 [0%] [-16.50dB] [on] Simple mixer control 'Channel Mode',0 Capabilities: enum Items: '2ch' '4ch' '6ch' Item0: '2ch' Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Mic' 'Front Mic' 'Line' 'CD' Item0: 'Mic' Simple mixer control 'Input Source',1 Capabilities: cenum Items: 'Mic' 'Front Mic' 'Line' 'CD' Item0: 'Mic' Regards -Eric Clemens Ladisch wrote: > Eric Holstege wrote: > >> My specific sound HW is "nVidia Corporation MCP79 High Definition Audio >> (rev b1)" >> > > This is the HDA controller, which can be combined with any HDA codec, > which actually controls mixing. > > Please show the output of "amixer scontents". > > > Regards, > Clemens > > >

2 1

[alsa-devel] using plug for sample format conversion
by Adam Rosenberg 27 Aug '10

27 Aug '10

>> I am trying to use plug to play audio files that are S16_LE but my >> hardware only supports S32_LE. It is not working. Here is an example >> of the problem using speaker-test. First I use S32_LE and it works as >> expected. I then try S16_LE but it fails. Does this mean the plug >> plugin cannot convert between these sample formats? >> >> Thanks, >> Adam >> > >Please use latest version of speaker-test and alsa-lib. > >and post struct snd_pcm_hardware of you driver > I am using the latest release of uClinux for Blackfin BF537 and do not know how to configure and install the latest version of alsa-lib and alsa-utils. I am starting to understand how struct snd_pcm_hardware is used by the ALSA PCM code but you are correct to assume I may have something wrong. Here is the struct: static struct snd_pcm_hardware ourCS42448PcmHw = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER ), .formats = SNDRV_PCM_FMTBIT_S32_LE, .rates = SNDRV_PCM_RATE_48000, .rate_min = 48000, .rate_max = 48000, .buffer_bytes_max = 32768, .channels_min = 1, .channels_max = 2, .period_bytes_max = 32768, .periods_min = 1, .period_bytes_min = 8, .periods_max = 4096, }; Can you tell me how to configure and install the latest ALSA and whether the snd_pcm_hardware is correct? Thanks, Adam Adam Rosenberg Software Engineer Alcorn McBride Inc. 3300 South Hiawassee Building 105 Orlando, FL 32835 (407) 296 - 5800 ext. 5490

3 3

[alsa-devel] [PATCH] ARM: S3C64XX: Fix fallthrough bug in i2sv3 gpio configuration, improve logging
by Dimitris Papastamos 27 Aug '10

27 Aug '10

If the platform device id is 1, the code will fallthrough the case and incorrectly return -EINVAL. Add a break to avoid fallthrough. Make logging slightly more verbose by including the device id. This is a fix for a change in ASoC multi-component as well. Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- arch/arm/mach-s3c64xx/dev-audio.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c index f094258..3838335 100644 --- a/arch/arm/mach-s3c64xx/dev-audio.c +++ b/arch/arm/mach-s3c64xx/dev-audio.c @@ -43,8 +43,10 @@ static int s3c64xx_i2sv3_cfg_gpio(struct platform_device *pdev) s3c_gpio_cfgpin(S3C64XX_GPE(2), S3C64XX_GPE2_I2S1_LRCLK); s3c_gpio_cfgpin(S3C64XX_GPE(3), S3C64XX_GPE3_I2S1_DI); s3c_gpio_cfgpin(S3C64XX_GPE(4), S3C64XX_GPE4_I2S1_D0); + break; default: - printk(KERN_DEBUG "Invalid I2S Controller number!"); + printk(KERN_DEBUG "Invalid I2S Controller number: %d\n", + pdev->id); return -EINVAL; } @@ -184,7 +186,8 @@ static int s3c64xx_pcm_cfg_gpio(struct platform_device *pdev) s3c_gpio_cfgpin(S3C64XX_GPE(4), S3C64XX_GPE4_PCM1_SOUT); break; default: - printk(KERN_DEBUG "Invalid PCM Controller number!"); + printk(KERN_DEBUG "Invalid PCM Controller number: %d\n", + pdev->id); return -EINVAL; } -- 1.7.2.2

3 3

[alsa-devel] ice1712 and the delta 1010
by David Santamauro 27 Aug '10

27 Aug '10

Hi all, this is my first post as I was guided here from the linux audio user list to follow up on a problem I've been having with my delta 1010. Background: Since upgrading my audio PC to 64-bit, the delta 1010 analog inputs emit a constant 'hiss' -36 -30dB. Analog outputs and digital ins and outs are fine. The delta 1010 from a hardware perspective is fine as I tested it on the same pc hardware under windows7 64-bit. So far, I have tested it in a 32-bit fedora, 32-bit windows vista and 64-bit windows7 all successfully. This problem arises only in 64-bit fedora. My kernel: Linux 2.6.31.12-1.rt21.1.fc12.ccrma.x86_64.rt My alsa packages and versions: alsa-lib.x86_64 1.0.23-1.fc12 alsa-lib-devel.x86_64 1.0.23-1.fc12 alsa-tools.x86_64 1.0.22-1.1.fc12.ccrma alsa-utils.x86_64 1.0.23-3.fc12 My modinfo: $ modinfo snd_ice1712 filename: /lib/modules/2.6.31.12-1.rt21.1.fc12.ccrma.x86_64.rt/kernel/sound/pci/ice1712/snd-ice1712.ko license: GPL description: ICEnsemble ICE1712 (Envy24) author: Jaroslav Kysela <perex(a)perex.cz> srcversion: 0B183929429B4C5102B7D09 alias: pci:v00001412d00001712sv*sd*bc*sc*i* depends: snd-pcm,snd,snd-i2c,snd-mpu401-uart,snd-ice17xx-ak4xxx,snd-cs8427,snd-ak4xxx-adda,snd-ac97-codec vermagic: 2.6.31.12-1.rt21.1.fc12.ccrma.x86_64.rt SMP preempt mod_unload parm: index:Index value for ICE1712 soundcard. (array of int) parm: id:ID string for ICE1712 soundcard. (array of charp) parm: enable:Enable ICE1712 soundcard. (array of bool) parm: omni:Enable Midiman M-Audio Delta Omni I/O support. (array of bool) parm: cs8427_timeout:Define reset timeout for cs8427 chip in msec resolution. (array of int) parm: model:Use the given board model. (array of charp) parm: dxr_enable:Enable DXR support for Terratec DMX6FIRE. (array of int) So, my question is simply: has this been reported before, in particular regarding the 64-bit ice1712 module? I'm pretty convinced it is a software/driver 32/64-bit issue based on my observations above and confirmation of the same problem under the same conditions by another user, but am willing to be corrected. I'm a pretty competent C/C++ coder but a novice coder in the linux audio world so I'd be willing to learn and help from a driver perspective given the right direction -- at the least help debug the problem (if it is even at the driver level). Thanks for any input. David

2 5

Re: [alsa-devel] explicit commandline control of speakers vs headphone output
by Eric Holstege 27 Aug '10

27 Aug '10

My specific sound HW is "nVidia Corporation MCP79 High Definition Audio (rev b1)" *== lspci*: 00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio (rev b1) Subsystem: Micro-Star International Co., Ltd. Device 4570 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23 Memory at fae78000 (32-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel *== lshal*: udi = '/org/freedesktop/Hal/devices/pci_10de_ac0' info.linux.driver = '*HDA Intel*' (string) info.parent = '/org/freedesktop/Hal/devices/computer' (string) info.product = 'MCP79 High Definition Audio' (string) info.subsystem = 'pci' (string) info.udi = '/org/freedesktop/Hal/devices/pci_10de_ac0' (string) info.vendor = 'nVidia Corporation' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'pci' (string) linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:08.0' (string) pci.device_class = 4 (0x4) (int) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 3 (0x3) (int) pci.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:08.0' (string) pci.product = '*MCP79 High Definition Audio*' (string) pci.product_id = 2752 (*0xac0*) (int) pci.subsys_product_id = 17776 (0x4570) (int) pci.subsys_vendor = 'Micro-Star International Co., Ltd.' (string) pci.subsys_vendor_id = 5218 (0x1462) (int) pci.vendor = 'nVidia Corporation' (string) pci.vendor_id = 4318 (0x10de) (int) Does the hardware support this (explicit control (e.g. via a script or commandline) of whether the sound is going to the speakers or to the headphone even when the headphone is plugged in.) If the hardware supports it, how would I, in fact, switch via commandline between the two outputs? Thanks in advance -Eric ----------------------- Eric Holstege wrote: > It appears that when I have a headphone plugged in, the speakers are > automatically disabled and the output sound is sent to the headphone. > > However, I want to explicitly control (e.g. via a script or > commandline - not a GUI) whether the sound from an (arbitrary) > application is going to the speakers or to the headphone even when the > headphone is plugged in. > (When I say "arbitrary application" that means I can't alter the code > of the application itself). > > Is this possible? > > (I have heard that ALSA mutes the speakers when it detects plugged-in > headphones. Is switching between them as simple as using e.g. > amixer(1) to unmute the speakers and mute the headphones and vice > versa, or is there more to it.) >

2 1

[alsa-devel] imx-ssi in master mode?
by Sven Zeisberg 27 Aug '10

27 Aug '10

Hi I found that the i.MX25 can not transfer multichannels frames through SSI when it is set up as slave. (when the i.MX25 SSI is set up as slave, the SSI is set to "normal" mode in which only one word per frame is transfered) Now I'm wondering if anybody has successfully used a codec with the i.MX25 SSI set up as Master. When we do this here, we can see that the i.MX25 is generating the bit clock but no frame sync. BR Sven

2 1

[alsa-devel] [PATCH] omap: rx51: Remove redefinition of rx51_aic3x_data
by Jarkko Nikula 26 Aug '10

26 Aug '10

Redefinition of rx51_aic3x_data got introduced when merging upstread changes for 2.6.36 and ASoC Multi-Component Support. This must go together with multi-component commit f0fba2a. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> Cc: Tony Lindgren <tony(a)atomide.com> --- arch/arm/mach-omap2/board-rx51-peripherals.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c index 897d960..11ce4b2 100644 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c @@ -710,10 +710,6 @@ static struct twl4030_platform_data rx51_twldata __initdata = { .vio = &rx51_vio, }; -static struct aic3x_pdata rx51_aic3x_data __initdata = { - .gpio_reset = 60, -}; - static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata = { .id = TPA6130A2, .power_gpio = 98, -- 1.7.1

3 2

[alsa-devel] How to transfer more than 2 channels between i.MX25 & AD1938 using SSI?
by Sven Zeisberg 26 Aug '10

26 Aug '10

Hi, has anybody succeeded to transfer more than 2 audio channels between i.MX25 and a CODEC throught the i.MX25 SSI Port? We have succeeded to set the CODEC (AD1938) as Master to the required mode (TDM with 8 Timeslots and 32 Bit per Timeslot). However, as soon as we start to play a wav file with aplay, we can see on the logic analyzer that the data format on the SSI lines is reset to a stereo mode (2 channels with frame sync changing level between channels). In the imx-ssi driver, I can see that .channel_max = 2 - therefore my question: does this driver support more than two channels at all? BR Sven

1 0

[alsa-devel] EEE PC 1001P Driver Issues
by Alison Gravley 26 Aug '10

26 Aug '10

ALSA Info is at: http://www.alsa-project.org/db/?f=49ae352709904da7e3201343ec639bdaf5c8563a Issues: When plugging in headhpones, it plays audio through both them and speaker. Have to manually mute one or the other. Built in Mic is also buggy and does not work reliably, though external ones through mic jack work ok. Have had same issues regardless of distro it seems. If you need any more information, feel free to ask. -- Alison

1 0