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

[alsa-devel] dmix and sounds less than 64kb
by Aaron "Caustik" Robinson 25 Jul '07

25 Jul '07

We have been having one heck of a time tracking down the cause of some ALSA audio playback issues. It appears that any time we play a very short sound (<64kb), either the sound doesn't play at all, or only a fragment of it plays. We haven't had much luck finding a solution to this issue, then I found this thread on the history of this email group: http://mailman.alsa-project.org/pipermail/alsa-devel/2007-April/000526.html Our problem is pretty much exactly like his issues relating to <64k sounds. My question is - has anybody else run into this problem? To the OP of the above thread, if you're still listening - did you ever find a solution to your problem? I'd be very interested to hear any help you can provide. Thanks much, caustik

3 9

[alsa-devel] Testing play and record simultaneously.
by Pharaoh . 25 Jul '07

25 Jul '07

Very naive questions. 1. I want to test the recording using arecord, but how will I make sure that the data is actually being recorded? I mean is there any way of storing the data recorded, say in a file? Off course there must be some way, its just that I dont know it. Can some one throw some light on this? 2. Also, I want to test my card in full duplex mode as well, i.e. playing and recording simultaneously. How can test this using aplay and arecord? -Pharaoh.

2 1

[alsa-devel] [PATCH] CA0106 SPI DAC powerdown
by Trent Piepho 25 Jul '07

25 Jul '07

Here are three patches for the CA0106 SPI DAC. The first patch powers down the DACs (other than the front dac) when they are not in use. The front dac serves as the output for the line-in pass-through / capture feedback, so it's not powered down. The second patch adds a bunch of symbol names for SPI registers, and converts the existing init sequence from magic numbers to these names. The sequence doesn't change at all. The third patch cleans up some unnecessary repeated sets to the same registers in the SPI init sequence. Of course, I have tested all these patches and they work.

2 1

[alsa-devel] How do I tell ALSA that my driver supports every possible sample rate?
by Timur Tabi 25 Jul '07

25 Jul '07

I'm building an ASOC driver, and I want to tell ALSA that my PCM and my I2S drivers support every possible sample rate, because it's the codec that determines the real limitations. What SNDRV_PCM_RATE_xxx bit-pattern do I specify that will always match? -- Timur Tabi Linux Kernel Developer @ Freescale

4 14

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