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

Re: [alsa-devel] support for Medion laptops
by albox＠free.fr 25 Jul '07

25 Jul '07

Realtek published a driver using ALSA 1.0.14-4. It seems that they added a new model for medion ("medion-md2"). I tried this model but it doesn't work either on my laptop. I sent them an email to know more about that. Does anybody has more information ? I updated the bug report : https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3160 Thanks

1 0

[alsa-devel] YMFPCI: IEC958 volume does not work anymore (2.6.18->2.6.21)
by Jan Zuchhold 24 Jul '07

24 Jul '07

Hello, i'm using a Hoontech Soundtrack Digital-XG (YMF744) and after i've upgraded to kernel 2.6.21, i can't control the IEC958 volume (using "Wave volume") any longer. It seems to be always at maximum volume. The volume control of the analog output port works fine. This is working in 2.6.18, that i've used before. Something must have changed in between. Is there anything I can do to help to get this working again? Thanks alot, Jan

2 2

Re: [alsa-devel] snd-hda-intel, AD 1988b: SPDIF output not working correctly, volume low for analog output
by Takashi Iwai 24 Jul '07

24 Jul '07

At Mon, 23 Jul 2007 23:02:57 +0200, Matthias Dahl wrote: > > Hello Takashi. > > On Friday 20 July 2007 15:47:55 Takashi Iwai wrote: > > > This is expected behavior. The PCM volume is implemented via softvol > > plugin, and it creates dynamically at the first run. But, usually, > > it's restored via alsactl at the next boot. > > It is. Thanks for the info. > > > Yes, it'll involve with patch_analog.c deeply. Basically you need to > > modify init verb table and the mixer element table. Check the AD1988B > > datasheet, and try to assign the different PIN (and corresponding > > mixer / selector widgets) in init verb and mixer tables. Then, > > rebuild driver, and try the driver until you get the complete mapping > > of pin widgets. > > I am currently a bit limited in time (end of semester exams) but after a few > hours of playing around (and reading the specs) I figured the following: > > 1) From time to time no analog output is routed to the spdif anymore. The only > clue I could get is the "IEC958 Playback Default" which is set to > > 06820002 [... many more zeros ...] > > and thus restored to that value after reboots. When things work like they > should (analog output is routed to spdif), its value is > > 04820002 [... many more zeros ...] > > Manually setting it to this value naturally solves the problem. I have yet > to figure out how to trigger this problem?! It seems to happen rather > randomly. In both cases, ac3 passthrough works just fine btw. Maybe some apps change the IEC958 status bits and doesn't restore the original value at close. (Or interrupting via ctrl-C may cause it.) You can see the meaning of these bits via iecset utility included in alsa-utils package. > 2) I have come a step closer in solving the analog-to-spdif volume/distortions > problem... at least I hope. > > The following patch fixes the volume problem for me. Without it, I had to > set the IEC958 volume somewhere around 58... increasing it would result in > noticable clipping and even short audio gaps (noise). > > Honestly, I don't quite understand the purpose of the code I removed in the > first place. From what I figured reading the specs and the code, the spdif > in is mixed with the spdif out stream... but that's all I could gather. But > still it doesn't seem quite right to me. > > --- patch_analog.c.orig 2007-07-23 22:44:25.000000000 +0200 > +++ patch_analog.c 2007-07-23 22:45:15.000000000 +0200 > @@ -2037,12 +2037,8 @@ > static struct hda_verb ad1988_spdif_init_verbs[] = { > /* SPDIF out sel */ > {0x02, AC_VERB_SET_CONNECT_SEL, 0x0}, /* PCM */ > - {0x0b, AC_VERB_SET_CONNECT_SEL, 0x0}, /* ADC1 */ > - {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, > - {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)}, > /* SPDIF out pin */ > {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE | 0x27}, /* 0dB */ > - {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0) | 0x17}, /* 0dB */ > > { } > }; > > The audio distortions in the background have become a little less noisy > but are still there. (a bass-like pumping, some white noise and sometimes > some high frequency tone) But the volume works just fine now... (iec958 > vol at 100%) and the audio sounds somewhat "clearer"! So, the culprit looks like the analog loopback. Could you try the patch below, and make sure that you set "PCM" as the "IEC958 Playback Source"? thanks, Takashi diff -r c2078875c0cd pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Tue Jul 24 12:10:34 2007 +0200 +++ b/pci/hda/patch_analog.c Tue Jul 24 12:47:42 2007 +0200 @@ -1889,16 +1889,19 @@ static int ad1988_spdif_playback_source_ struct hda_codec *codec = snd_kcontrol_chip(kcontrol); unsigned int sel; - sel = snd_hda_codec_read(codec, 0x02, 0, AC_VERB_GET_CONNECT_SEL, 0); - if (sel > 0) { + sel = snd_hda_codec_read(codec, 0x1d, 0, AC_VERB_GET_AMP_GAIN_MUTE, + AC_AMP_GET_INPUT); + if (!(sel & 0x80)) + ucontrol->value.enumerated.item[0] = 0; + else { sel = snd_hda_codec_read(codec, 0x0b, 0, AC_VERB_GET_CONNECT_SEL, 0); if (sel < 3) sel++; else sel = 0; + ucontrol->value.enumerated.item[0] = sel; } - ucontrol->value.enumerated.item[0] = sel; return 0; } @@ -1910,17 +1913,32 @@ static int ad1988_spdif_playback_source_ int change; val = ucontrol->value.enumerated.item[0]; - sel = snd_hda_codec_read(codec, 0x02, 0, AC_VERB_GET_CONNECT_SEL, 0); if (!val) { - change = sel != 0; - if (change || codec->in_resume) - snd_hda_codec_write(codec, 0x02, 0, - AC_VERB_SET_CONNECT_SEL, 0); + sel = snd_hda_codec_read(codec, 0x1d, 0, + AC_VERB_GET_AMP_GAIN_MUTE, + AC_AMP_GET_INPUT); + change = sel & 0x80; + if (change || codec->in_resume) { + snd_hda_codec_write(codec, 0x1d, 0, + AC_VERB_SET_AMP_GAIN_MUTE, + AMP_IN_UNMUTE(0)); + snd_hda_codec_write(codec, 0x1d, 0, + AC_VERB_SET_AMP_GAIN_MUTE, + AMP_IN_MUTE(1)); + } } else { - change = sel == 0; - if (change || codec->in_resume) - snd_hda_codec_write(codec, 0x02, 0, - AC_VERB_SET_CONNECT_SEL, 1); + sel = snd_hda_codec_read(codec, 0x1d, 0, + AC_VERB_GET_AMP_GAIN_MUTE, + AC_AMP_GET_INPUT | 0x01); + change = sel & 0x80; + if (change || codec->in_resume) { + snd_hda_codec_write(codec, 0x1d, 0, + AC_VERB_SET_AMP_GAIN_MUTE, + AMP_IN_MUTE(0)); + snd_hda_codec_write(codec, 0x1d, 0, + AC_VERB_SET_AMP_GAIN_MUTE, + AMP_IN_UNMUTE(1)); + } sel = snd_hda_codec_read(codec, 0x0b, 0, AC_VERB_GET_CONNECT_SEL, 0) + 1; change |= sel != val; @@ -2039,10 +2057,9 @@ static struct hda_verb ad1988_spdif_init {0x02, AC_VERB_SET_CONNECT_SEL, 0x0}, /* PCM */ {0x0b, AC_VERB_SET_CONNECT_SEL, 0x0}, /* ADC1 */ {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}, - {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)}, + {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)}, /* SPDIF out pin */ {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE | 0x27}, /* 0dB */ - {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0) | 0x17}, /* 0dB */ { } };

2 2

[alsa-devel] Query regarding ALSA control interface
by Pharaoh . 24 Jul '07

24 Jul '07

Hi I am writing a pcm control interface for my alsa driver. I am confused about how the switches are used. I have implemented simple cases like following and they are working well. static int audio_path_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo) { /*Count is 256 since the values can vary from 0-255. But values fall in this range only*/ uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; uinfo->count = 256; uinfo->value.integer.min = 0; uinfo->value.integer.max = 255; FN_EXIT; return 0; } static int audio_path_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { my_mixer_t *mixer_chip = snd_kcontrol_chip(kcontrol); ucontrol->value.integer.value[0] = mixer_chip->echo; ucontrol->value.integer.value[1] = mixer_chip->echo; return 0; } static int audio_path_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { my_mixer_t *mixer_chip = snd_kcontrol_chip(kcontrol); ----- ---- } Now, I have to implement a control which takes four different values..namely 0,1.100 and 101. In this case what shoud be the type of control? It should be ENUMERATED or INTEGER? I am confused here since the values are not exactly in a range. -pharaoh.

2 2

[alsa-devel] [PATCH] Patch for AICA
by Adrian McMenamin 24 Jul '07

24 Jul '07

I submitted this yesterday via lkml and it was accepted by the SH maintainer. Probably should have copied in the ALSA list too - though the change is so small and consequential of another issue I was dealing with I forgot. The change is necessary because of a fix in the SH DMA API (see http://lkml.org/lkml/2007/7/23/445 for the larger patch) Signed-off by: Adrian McMenamin ,adrian(a)mcmen.demon.co.uk> diff --git a/sound/sh/aica.h b/sound/sh/aica.h index 8c11e3d..d098baa 100644 --- a/sound/sh/aica.h +++ b/sound/sh/aica.h @@ -52,7 +52,7 @@ #define AICA_CHANNEL1_OFFSET 0x21000 #define CHANNEL_OFFSET 0x10000 -#define AICA_DMA_CHANNEL 0 +#define AICA_DMA_CHANNEL 5 #define AICA_DMA_MODE 5

3 2

[alsa-devel] [PATCH] Support for muting channels DAC with CA0106 - SB0570
by Trent Piepho 24 Jul '07

24 Jul '07

This patch adds mute controls for the analog output channels. It does this by sending SPI commands to the DAC on cards like the SB live 24-bit / Audigy SE that have an SPI DAC.

2 3

[alsa-devel] basic workflow when playing some sounddata
by Markus Franke 24 Jul '07

24 Jul '07

Dear Alsa-Developers, I am very new to Alsa driver development and have some problems to get a clue how the process of playing sounddata works. Let me explain my point of view and it would be nice if anybody could give some clarifications and corrections on it. Suppose I want to play a *.wav file from userspace with "aplay". After triggering all the configuration functions for PCM and the DAI at some point the chip_pcm_trigger() function get's called. As per "Writing Alsa Drivers" the TRIGGER_START command should now do something for "enabling the PCM engine". As per my understanding this could be for example to enable the interrupts of my DAI, which is (I2S over GSI) in my case. The interrupt handler by itself should call snd_pcm_period_elapsed() whenever a period of sounddata is copied to the device. Furthermore the so called "hw_pointer" should be updated in the interrupt handler, right? To make it easy I don't want to use DMA in the beginning. I simply want to copy the data to the hardware buffer of my DAI (I2S via GSI) and from there it is copied automatically to my codec. The question is now, at which place in the alsa framework I have to put the copy process of the sounddata. It should not be done in the interrupt handler because this would take to much time. But whereelse could this be done? Also I don't know the meaning of chip_pcm_pointer() callback. As far as I could figure out from the source, this function is called whenever snd_pcm_period_elapsed() is called, right? But what should be done exactly in this callback. Again I want to say that I don't want to use DMA at all by now. I've read already "Writing Alsa Drivers" but the questions above still remain for me and I am quite confused as you maybe noticed already from my questions above. ;-) It would be nice if anybody can give me a basic workflow which functions/callbacks are necessary for the playing part of an Alsa driver. Thanks in advance for any help, Regards, Markus

2 1

[alsa-devel] SuSE 9.1 on Toshiba Satellite A105 - S4004
by Neeraj Vaidya 24 Jul '07

24 Jul '07

Hi, I've installed this distro on my toshiba laptop. In YaST , when I try to configure the sound card , it says no sound card detected. To cut a long story short , I do not get any sounds to work on my laptop. Sound works beautifully on XP , but I am trying to migrate all of my routine activities to linux ;) I am a newbie to the ALSA mailing list. Have a feeling that something to do with ALSA configuration can help me sort out this problem. When I run lspci , I do not see any audio card as being detected. Can someone please help me out ? Also , send me some diagnostic steps , if not the entire solution , so that we can sort this out in a series of emails , if the entire solution can not be provided in one email. Thanks in Advance! -Neeraj --------------------------------- Get the freedom to save as many mails as you wish. Click here to know how.

2 1

[alsa-devel] [PATCH] s3c24xx-pcm: fix hw_params dma handling
by Arnaud Patard 24 Jul '07

24 Jul '07

Hi, While testing the recently merged driver for the neo1973, I found out that it was not working due to dma allocation failure. The problem is that there's only one dma channel available on s3c2410 and there may be more than one call to pcm_ops->hw_params(), resulting in dma request failures. This patch from Harald Welte fix this. Arnaud

3 2

[alsa-devel] Intel HDA digital out distortion
by Ingmar Stieger 24 Jul '07

24 Jul '07

Hi, a couple of weeks ago, I bought an ASUS mainboard with integrated Intel HDA and an AD1988B codec. Unfortunately, the digital / SPDIF output gets distorted with stock 1.0.14 drivers. It does not matter what the volume levels of the various mixers are set to. I think I might have found the source for this problem. Maybe it's only a workaround, but it solved the issue and digital out now works fine for me, so I thought I'd share. In patch_analog.c, in static struct hda_verb ad1988_spdif_init_verbs[], changeing the forth entry from {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)}, to {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)} mutes what might be an feedback loop from the analog inputs. The distortion is gone if the input to this widget is muted. On a side note, the settings for the ADCs with NID:08, 09, and 0F looks fishy, too. According to the functional diagram, those should have no amps, and thus should not be muteable. The driver mutes them anyway... I'd like to help somebody who really understands this stuff to solve the problem for good. What would the next step be ? Thanks, Ingmar

2 2