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

[alsa-devel] Problem with underrun on new CS42448 x2 driver
by Adam Rosenberg 28 Aug '10

28 Aug '10

I am trying to write a driver for the Blackfin BF537 processor on a custom board that has two CS42448 CODECs connected to SPORT0. I am using TDM and there are 8 channels per frame on each data line (primary and secondary). My DMA buffer must interleave the data for the two data lines (for a total of 16 channels of data per frame). I have completed all of this and the driver will sometimes work properly but I am having underrun problems. I would like to use snd_async_add_pcm_handler as it is used in the /test/pcm.c example but it seems as though an underrun occurs at regular intervals causing the PCM prepare function to be called again (this results in a tone that sounds good but only for a short time before it stops and then starts again). There is plenty of time for the data to be transferred. I feel as though the driver is not calling snd_pcm_period_elapsed fast enough. At the moment, I call snd_pcm_period_elapsed from within a callback function that occurs every time a DMA period elapse occurs. I have been working on this for quite a while now. Is there someone who can look at the driver code for me or provide detailed information on when ALSA expects to have snd_pcm_period_elapsed get called to avoid an underrun? The other thing that is strange is that I have to explicitly set the period size for aplay to work. For example: aplay --period-size=1024 test.wav which gives me a period time of 21333 but when I use this period time with the /test/pcm.c sample that is provided the tone still does not sound right (although it does seem to improve) I am about ready to bypass ALSA entirely but I hate the idea of breaking from standards (not to mention having to rewrite an entire audio interface). Any help would be greatly appreciated! You can check out the driver here: http://www.alcorn.com/ftp/swap/ami_cs42448.zip Thank you, Adam Adam Rosenberg Software Engineer Alcorn McBride Inc. 3300 South Hiawassee Building 105 Orlando, FL 32835 (407) 296 - 5800 ext. 5490

3 8

[alsa-devel] xine AC3 dropout problem - Please help!
by VDR User 27 Aug '10

27 Aug '10

Hi. Xine seems to have a problem with ac3 audio dropping out frequently, which ruins the ability to watch hdtv for example. I have made a sample which exhibits this problem, which plays just fine in mplayer so I assume that means root causes such as a buggy system scheduler can be ruled out. The sample also plays fine on my main Windows desktop as well. Adjusting things such as engine.buffers.audio_num_buffers in xine's config has no affect. It has been suggested that the problem may be xine not properly handling a stream error. If anyone can and is willing to take a look at this and hopefully resolve the problem once and for all, that would be great. The sample is 20MB so it can't be attached to this post. Until I can find a better place to host the sample, I've temporarily uploaded it to: http://rapidshare.com/files/415479559/xine_ac3_dropout_bug.tar.bz2 System details are: debian testing stable kernel 2.6.35.3 (quiet notsc clocksource=hpet) gcc 4.4.4-8 alsa-base 1.0.23+dfsg-1 alsa-utils 1.0.23-2 xine-lib-1.2 hg r11577 xine-ui hg r3054 VDR-1.7.15 mplayer-nogui 2:1.0~rc3++svn20100804-0.0 I recently tried the notsc and clocksource=hpet kernel options, which also had no affect. I want to reiterate that the dropout problem only occurs in xine. The error I see in the xine log when the dropout occurs is: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed (-32). Best regards, Derek

2 2

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