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

[alsa-devel] [PATCH] Fix ALC662 DAC mixer mutes
by Herton Ronaldo Krzesinski 13 Mar '08

13 Mar '08

Currently ALC662 doesn't suport amp mute for AmpOut in nids 0x02, 0x03, 0x04 (see block diagram in ALC662 datasheet page 3, does M correspond to mute?). The result is that currently mute for "Front Playback Switch", "Surround Playback Switch", "Center Playback Switch" and "LFE Playback Switch" mixer items doesn't work (tested on Asus P5GC-MX motherboard with 3stack-6ch model). The solution I found for this is to mute the proper inputs in 0x0c, 0x0d, 0x0e audio mixers. Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com> diff -p -up linux-2.6.24/sound/pci/hda/patch_realtek.c.orig linux-2.6.24/sound/pci/hda/patch_realtek.c --- linux-2.6.24/sound/pci/hda/patch_realtek.c.orig 2008-03-11 13:45:07.000000000 -0300 +++ linux-2.6.24/sound/pci/hda/patch_realtek.c 2008-03-11 14:01:57.000000000 -0300 @@ -13004,13 +13004,13 @@ static struct hda_channel_mode alc662_5s static struct snd_kcontrol_new alc662_base_mixer[] = { /* output mixer control */ HDA_CODEC_VOLUME("Front Playback Volume", 0x2, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE("Front Playback Switch", 0x02, 0x0, HDA_OUTPUT), + HDA_CODEC_MUTE("Front Playback Switch", 0x0c, 0x0, HDA_INPUT), HDA_CODEC_VOLUME("Surround Playback Volume", 0x3, 0x0, HDA_OUTPUT), - HDA_CODEC_MUTE("Surround Playback Switch", 0x03, 0x0, HDA_OUTPUT), + HDA_CODEC_MUTE("Surround Playback Switch", 0x0d, 0x0, HDA_INPUT), HDA_CODEC_VOLUME_MONO("Center Playback Volume", 0x04, 1, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME_MONO("LFE Playback Volume", 0x04, 2, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE_MONO("Center Playback Switch", 0x04, 1, 2, HDA_INPUT), - HDA_BIND_MUTE_MONO("LFE Playback Switch", 0x04, 2, 2, HDA_INPUT), + HDA_CODEC_MUTE_MONO("Center Playback Switch", 0x0e, 1, 0x0, HDA_INPUT), + HDA_CODEC_MUTE_MONO("LFE Playback Switch", 0x0e, 2, 0x0, HDA_INPUT), HDA_CODEC_MUTE("Headphone Playback Switch", 0x1b, 0x0, HDA_OUTPUT), /*Input mixer control */ @@ -13027,7 +13027,7 @@ static struct snd_kcontrol_new alc662_ba static struct snd_kcontrol_new alc662_3ST_2ch_mixer[] = { HDA_CODEC_VOLUME("Front Playback Volume", 0x02, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("Front Playback Switch", 0x02, 2, HDA_INPUT), + HDA_CODEC_MUTE("Front Playback Switch", 0x0c, 0x0, HDA_INPUT), HDA_CODEC_MUTE("Headphone Playback Switch", 0x1b, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME("CD Playback Volume", 0x0b, 0x04, HDA_INPUT), HDA_CODEC_MUTE("CD Playback Switch", 0x0b, 0x04, HDA_INPUT), @@ -13044,13 +13044,13 @@ static struct snd_kcontrol_new alc662_3S static struct snd_kcontrol_new alc662_3ST_6ch_mixer[] = { HDA_CODEC_VOLUME("Front Playback Volume", 0x02, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("Front Playback Switch", 0x02, 2, HDA_INPUT), + HDA_CODEC_MUTE("Front Playback Switch", 0x0c, 0x0, HDA_INPUT), HDA_CODEC_VOLUME("Surround Playback Volume", 0x03, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("Surround Playback Switch", 0x03, 2, HDA_INPUT), + HDA_CODEC_MUTE("Surround Playback Switch", 0x0d, 0x0, HDA_INPUT), HDA_CODEC_VOLUME_MONO("Center Playback Volume", 0x04, 1, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME_MONO("LFE Playback Volume", 0x04, 2, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE_MONO("Center Playback Switch", 0x04, 1, 2, HDA_INPUT), - HDA_BIND_MUTE_MONO("LFE Playback Switch", 0x04, 2, 2, HDA_INPUT), + HDA_CODEC_MUTE_MONO("Center Playback Switch", 0x0e, 1, 0x0, HDA_INPUT), + HDA_CODEC_MUTE_MONO("LFE Playback Switch", 0x0e, 2, 0x0, HDA_INPUT), HDA_CODEC_MUTE("Headphone Playback Switch", 0x1b, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME("CD Playback Volume", 0x0b, 0x04, HDA_INPUT), HDA_CODEC_MUTE("CD Playback Switch", 0x0b, 0x04, HDA_INPUT), -- []'s Herton

1 1

[alsa-devel] Hardware and software period size
by Mathieu Monney 13 Mar '08

13 Mar '08

Hi all, I'm currently developping a layer between ALSA and a VoIP library for an embedded device. The device cannot have a different period size than 1024 for playback and 8 for capture (I don't know why :-( ). So my problem is that the VoIP library ask me to have a period size different of the hardware period size. So I decided to read/write to the sound device using the provided software period size rather than the hardware period size.. Is it a good idea? It seems to work but I have some sound quality issues :-( ! Thank you Mathieu

1 0

Re: [alsa-devel] [Alsa-user] Metallic recording in cs46xx on Thinkpad T22
by Rene Herman 13 Mar '08

13 Mar '08

On 11-03-08 08:24, Gadi Oron wrote: > I am trying to record sound on an old Thinkpad T22 that uses the cs46xx > sound driver. > > Each time you start to record you have a 10% chance of having the > recording completely distorted and having a metallic sound. When you > look at the waveform it looks as though there are small segments with > sharp transitions between them, a little like if these segments were > moved a little from their correct place. No insights, but I confirm the bug with a TerraTec DMX XFire 1024 (CS4624). Rene.

3 8

[alsa-devel] Trigger problems while writing Alsa Shim
by bruce＠azbarclay.com 13 Mar '08

13 Mar '08

I am writing a shim from alsa to our own sound card drivers. I was able to get the init driver working and our sound card recognized. Things seem to be set up correctly. When I do aplay to my device (USB device works find), it calls my copy callback twice and then it calls the trigger and fails. The call that fails is in pcm_write (writei_func) with a -5. I know that my callback returns zero but there must be something else under the covers since that gets to be zero. Any help would be appreciated. T

2 1

Re: [alsa-devel] ALSA utility aplay/arecord error
by Saurav SAHU 13 Mar '08

13 Mar '08

Hi all The platform on which I am trying to perform ALSA playback and record with USB sound device is based on a MIPS CPU running Linux kernel 2.6.14. The kernel uses non-coherent DMA in the configuration: CONFIG_DMA_NONCOHERENT=y CONFIG_DMA_NEED_PCI_MAP_STATE=y CONFIG_CPU_BIG_ENDIAN=y CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y CONFIG_BOOT_ELF32=y CONFIG_MIPS_L1_CACHE_SHIFT=5 I have attached the kernel .config file for further information. So far, I have not succeeded in hearing sound with 'aplay', or capturing sound with 'arecord'. If there have been any similar issues reported on ALSA usage with MIPS CPU based on non-coherent DMA in the past, please let me know. Also, if there have been any patches developed for successful resolution of this issue on similar platform/configuration, it would be very useful for me. Thanks & Regards Saurav ----- Original Message ----- From: Saurav Sahu To: alsa-user(a)lists.sourceforge.net Sent: Friday, March 07, 2008 4:33 PM Subject: Re: ALSA utility aplay/arecord error I have been able to resolve the previously reported errors by setting the environment variable for ALSA configuration file on the target filesystem of the embedded platform. However, I do not hear any audio from USB sound device with speaker-test or aplay: Upon using arecord for recording, I get an error: Is this problem related to a low-level driver issue which may not be working well on target platform? Could there be a DMA related issue as the samples don't seem to be transferred to the USB audio device. ----- Original Message ----- From: Saurav Sahu To: alsa-user(a)lists.sourceforge.net Sent: Thursday, March 06, 2008 4:28 PM Subject: ALSA utility aplay/arecord error Hello I am working towards using ALSA for playback and capture on an embedded platform running Linux. The kernel uses ALSA driver version 1.0.10rc1. I had manually built and installed ALSA library (v1.0.10) and ALSA utilities (v1.0.10) for the target platform filesystem. I have a USB audio device (C-Media) connected to the USB port of the board and it seems to be successfully successfully detected by the driver. However, when I run ALSA utilities like aplay, arecord or speaker-test, I observe errors opening the hardware device which may be related to the configuration on the filesystem. Are these errors from ALSA utility/library due to the detection of hardware, ALSA configuration files or something else related to my target device filesystem? Thanks in advance for any help. Do let me know if you need any more details. Best Regards Saurav

2 1

[alsa-devel] [PATCH] asihpi - new checkpatch = more changes
by Eliot Blennerhassett 13 Mar '08

13 Mar '08

Signed-off-by: Eliot Blennerhasssett <linux(a)audioscience.com> * HPI version 3.09.15 * Updating to latest version of checkpatch resulted in some more warnings to clean up. * A few whitespace cleanups * Removed DBG_TXT and DBG_CHAR macros --- patch attached -- Eliot Blennerhassett www.audioscience.com

2 1

[alsa-devel] Hda-intel: AC_VERB_SET_PIN_WIDGET_CONTROL appears to do nothing for HDMI device
by Ben Firshman 13 Mar '08

13 Mar '08

This is on 1.0.16. Forgive me if I appear clueless, I have only been working on this for the past few hours. In an attempt to get HDMI audio working on the AppleTV, I have added this line to the presets in patch_atihdmi.c: { .id = 0x10951390, .name = "SI1390 HDMI", .patch = patch_atihdmi }, The device is detected fine: ben@mythfrontend:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: ALC882 Analog [ALC882 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 1: ALC882 Digital [ALC882 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 3: ATI HDMI [ATI HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 ben@mythfrontend:~$ and I can send audio to the device, but it doesn't work. I presume this because this is doing nothing: static struct hda_verb atihdmi_basic_init[] = { /* enable digital output on pin widget */ { 0x03, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT }, {} /* terminator */ }; ben@mythfrontend:~$ cat /proc/asound/card0/codec#1 Codec: Generic 1095 SI1390 HDMI Address: 1 Vendor Id: 0x10951390 Subsystem Id: 0xffffffff Revision Id: 0x100000 No Modem Function Group found Default PCM: rates [0x0]: bits [0x0]: formats [0x0]: Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x6211: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x5]: PCM AC3 Node 0x03 [Pin Complex] wcaps 0x40738d: Stereo Digital Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0894: OUT Detect R/L Pin Default 0x98460010: [Fixed] SPDIF Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Connection: 1 0x02 "Pin-ctls: 0x00:" should be reading "Pin-ctls: 0x40: OUT" should it not? What is wrong? Thanks Ben

2 4

[alsa-devel] aplay doesnt work - new problem`
by Pharaoh . 13 Mar '08

13 Mar '08

I am trying to run my pcm external io type plugin on an arm based board. I have no kernel alsa driver and the user space plugin is supposed to take care of talking to DSP using shared memorty and send sound data. Since, I dont have kernel space ALSA driver, do I need to enable kernel ALSA support in .config? I am facing following problem, #aplay ALSA lib conf.c:2852:(snd_config_hook_load) cannot access file /home/pharaoh/alsa/cards/aliases.conf ALSA lib pcm.c:2014:(snd_pcm_open_conf) Invalid type for PCM default definition (id: default, value: cards.pcm.default) aplay: main:550: audio open error: Invalid argument I can see that, aliases.conf is being searched at wrong place (its actually looking on my host machine), how can I fix this? -pharaoh.

2 4

[alsa-devel] driver development questions
by gmail zaq79324 12 Mar '08

12 Mar '08

Hi everyone, I'm currently developing an ALSA driver from scratch. It is almost done, but memory buffer management problem remains. I have tried in various way of debugging. But currently I'm almost giving it up. My target hardware has a small data buffer(2K+2K ring buffer). The driver fills the first half buffer(2K) and writes hardware port. After this the interrupt occurs to urge writting the second half buffer and hardware port. The second buffer is filled in the same way. The buffer filling scheme will repeat continuously until the end of the sound. Through my driver, aplay command can generate the sound within few seconds, but it stops before finishing completely. It seems to have the problem of buffer management. So I set xrun_debug option like as follows. echo 1 > /proc/asound/SM502I2S/pcm0p/xrun_debug And I got the following output. Does anyone know what the problem is and how to fix it? # ./bin/aplay --channels=1 --period-size=2048 sample.wav Playing WAVE 'sample.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo aplay: pcm_write:1266: write error: Input/output error ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -2048, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -2048, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -2048, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -512, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -2048, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1536, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? ALSA sound/core/pcm_lib.c:240: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 11025): wrong interrupt acknowledge? Regards, Tadashi

2 1

[alsa-devel] It's time to discuss how to get a Gadget Labs driver into the Alsa tree...
by Mike Mazarick 12 Mar '08

12 Mar '08

As discussed and posted to the Alsa Devel and Planet CCRMA lists back in December (when this was 'a dream' ), we currently have a working Gadget Labs Alsa driver. There are a few more 'features' that are being considered for development (multi card support, a control panel, etc) and more extensive testing and verification by novice users is desired. The main idea is that we intend to ask the main Alsa developers for information twice; first when we have a functional driver and second when we have one that is 'user tested' and is ready to go (ie. when there is a high degree of certainty that all the features are finished and it's use won't cause any major problems). We are now at the first crossroads. There is a small team of developers, Dave Marion and Rick Macri, with some assistance from Pete Mander on SVN setup (Dave and Rick finished before Pete got a chance to 'play'). We have set up a sourceforge page to centralize our effort. The developers and I believe the code currently in the SVN trunk (gl824) is suitable for identifying the appropriate steps to get it from the project SVN repository into the Alsa Hg tree. The project main page is here: https://sourceforge.net/projects/wavepro-driver/ The source code is in an SVN repository here: http://wavepro-driver.svn.sourceforge.net/viewvc/wavepro-driver/ There is a very short web page listed for development: http://wavepro-driver.sourceforge.net/ There is a private mailing list of about 16 people that is tracking what is going on. The group email address is: wavepro-driver-developers(a)lists.sourceforge.net (however, you may have to be subscribed to mail something to the list; I'm not sure). If you are subscribed, there is an archive available here: https://sourceforge.net/mailarchive/forum.php?forum_name=wavepro-driver-deve lopers Our goal is to have this driver included in Alsa so that an end user could have this type of card in their system, and everything would automagically work like all other cards. The only way this can happen is if the driver was included as part of Alsa. The key 'next' questions are: 1. When are the next couple of releases of Alsa planned? How much time before the release date should all drivers be 'in the Hg tree'? 2. Does the code that is currently in the Gadget Labs SVN repository meet the coding and syntax standards of Alsa? We've tried to make it meet the standards, and it is fairly easy to change at this stage if you happen to spot something that is inconsistent with what you'd recommend. 3. We have not modified Alsa to make this driver automatically; there is a 'Makefile' included currently. We currently 'modprobe snd_rawmidi' and 'modproble snd_pcm' and then 'insmod gl824.ko' to get it installed. The required changes to Alsa are fairly trivial and would be the same for every other sound card. Please let us know if there is something that should happen besides what is in the GL repository. 4. One of the key reasons that this driver was able to be developed and tested in 2-3 months of part time effort is because there is already complete source available for a Windows driver, complete with new firmware and vhdl source (see 'External' in the repository). The Windows developer is a member of our mailing list and has been encouraging/helping our effort. However, he didn't bother with GPL licensing (it's a 'Mostek/Waldemar' license instead, but the source is readily available). There may be a few header files that he wrote and the PLD firmware is definitely from his development. Will everything (including the firmware) need to be GPLv2 before it can be included in the alsa tree? 5. What is needed for support? What would you like us to be available to do going forward? 6. How can we make your life a little easier by modifying our software? What would you like to see that you don't see? Although we will diligently try to get a broader base of testing to happen, we will tell you realistically that there are probably very few users who are likely to test this out. I don't know of the exact number of Gadget Labs cards that were produced, but the best guess is ~5,000 cards before the manufacturer went bankrupt in 2001. We feel the effort of creating a linux driver has been advertised in most of the appropriate places, but the mailing list that is tracking this is only 16 people, with 4 main participants. In other words, I don't think this will be a 'SoundBlaster' or 'Audigy' with thousands of people giving feedback on how it works. However, I do believe that this will be a very viable and cost effective solution for some people who want an 8 channel in/out, 24 bit, 48 khz, semi-professional soundcard solution with midi. Although the soundcard does not support DMA directly (a limitation of the PLX9052 interface chip), Rick has developed an innovative scheme of using a user buffer and dumping the result into a kernel ring buffer that provides as little as 2ms latency. You may also find the method/architecture for development of interest to you (see web page and SVN listings). Please provide some of the key information you need so that we can work together most effectively. Answering some the questions above would be a good way to start. We would welcome your feedback so that we can incorporate into the GL project codebase. After your feedback has been incorporated in the code and testing is completed, we will be pinging you again (the second time) to let you know we are ready to put the code in the alsa tree. Regards, Mike Mazarick mazarick(a)bellsouth.net

2 1