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

[alsa-devel] [PATCH 01/10] ASoC: build fix for snd_soc_info_bool_ext
by Mark Brown 13 May '08

13 May '08

From: Philipp Zabel <philipp.zabel(a)gmail.com> I suspect that snd_ctl_boolean_mono should have been snd_ctl_boolean_mono_info instead. This fixes the build for magician. Signed-off-by: Philipp Zabel <philipp.zabel(a)gmail.com> Signed-off-by: Liam Girdwood <lg(a)opensource.wolfsonmicro.com> --- include/sound/soc.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index e6ea6f7..d3c8c03 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -238,7 +238,7 @@ int snd_soc_info_volsw(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo); int snd_soc_info_volsw_ext(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo); -#define snd_soc_info_bool_ext snd_ctl_boolean_mono +#define snd_soc_info_bool_ext snd_ctl_boolean_mono_info int snd_soc_get_volsw(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol); int snd_soc_put_volsw(struct snd_kcontrol *kcontrol, -- 1.5.5.1

3 18

[alsa-devel] Acer Aspire 8920g / snd-hda-intel / ALC889
by Andy Green 13 May '08

13 May '08

Hi folks - I have a new 8920g on Fedora development running 2.6.25 which has $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.16rc2 (Thu Jan 31 16:40:16 2008 UTC). I get a decent looking set of alsa things in /proc/asound $ cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xfc300000 irq 22 and dmesg says that model=acer was selected reasonably enough. I can play audio down the logical sound devices, including cat /dev/urandom > /dev/dsp and the interrupt count goes up in /proc/interrupts. Alsamixer shows a bunch of things and I twiddled them all to no avail. There has never been even a click from the speakers or headphone jack on this machine. At least three funnies on this machine: 1) It is confused if it has ALC889 or ALC883 in there $ grep ALC /proc/asound/* -R /proc/asound/card0/codec#0:Codec: Realtek ALC889 <==== 889 /proc/asound/card0/pcm2c/sub0/info:id: ALC883 Analog <=== 883... /proc/asound/card0/pcm2c/sub0/info:name: ALC883 Analog /proc/asound/card0/pcm2c/info:id: ALC883 Analog /proc/asound/card0/pcm2c/info:name: ALC883 Analog /proc/asound/card0/pcm0c/sub0/info:id: ALC883 Analog /proc/asound/card0/pcm0c/sub0/info:name: ALC883 Analog /proc/asound/card0/pcm0c/info:id: ALC883 Analog /proc/asound/card0/pcm0c/info:name: ALC883 Analog /proc/asound/card0/pcm0p/sub0/info:id: ALC883 Analog /proc/asound/card0/pcm0p/sub0/info:name: ALC883 Analog /proc/asound/card0/pcm0p/info:id: ALC883 Analog /proc/asound/card0/pcm0p/info:name: ALC883 Analog /proc/asound/Intel/codec#0:Codec: Realtek ALC889 <=== 889 /proc/asound/Intel/pcm2c/sub0/info:id: ALC883 Analog /proc/asound/Intel/pcm2c/sub0/info:name: ALC883 Analog /proc/asound/Intel/pcm2c/info:id: ALC883 Analog /proc/asound/Intel/pcm2c/info:name: ALC883 Analog /proc/asound/Intel/pcm0c/sub0/info:id: ALC883 Analog /proc/asound/Intel/pcm0c/sub0/info:name: ALC883 Analog /proc/asound/Intel/pcm0c/info:id: ALC883 Analog /proc/asound/Intel/pcm0c/info:name: ALC883 Analog /proc/asound/Intel/pcm0p/sub0/info:id: ALC883 Analog /proc/asound/Intel/pcm0p/sub0/info:name: ALC883 Analog /proc/asound/Intel/pcm0p/info:id: ALC883 Analog /proc/asound/Intel/pcm0p/info:name: ALC883 Analog /proc/asound/oss/sndstat:0: ALC883 Analog (DUPLEX) /proc/asound/oss/sndstat:0: Realtek ALC889 /proc/asound/pcm:00-02: ALC883 Analog : ALC883 Analog : capture 1 /proc/asound/pcm:00-00: ALC883 Analog : ALC883 Analog : playback 1 : capture 1 2) from dmesg ALSA sound/pci/hda/hda_intel.c:1810: chipset global capabilities = 0x4401 ALSA sound/pci/hda/hda_intel.c:749: codec_mask = 0x3 ALSA sound/pci/hda/hda_codec.c:2211: hda_codec: model 'acer' is selected ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Headphone Playback Volume, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Speaker Playback Volume, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Mono Playback Volume, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Line-Out Playback Volume, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Speaker Playback Switch, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave Mono Playback Switch, skipped ALSA sound/pci/hda/hda_codec.c:1073: Cannot find slave IEC958 Playback Switch, skipped 3) there is a funny embedded capacitive volume control thing on this device, whether it gates output by itself or is just a bunch of special keyboard keys, I dunno. Any ideas, more information needed? -Andy

2 14

[alsa-devel] basic question on .pointer function
by Harsha priya gupta 13 May '08

13 May '08

Hi, It would be really helpful if someone can help me understand why do we need to implement .pointer and what does it need to do? I am facing an issue to write a driver in this .pointer function. Please help Also if someone can point me to a document where all the playback_ops are defined, it would be really helpful -- -Harsha

2 3

[alsa-devel] Pulseaudio alsa configure hook
by Sjoerd Simons 13 May '08

13 May '08

Hi, The attached patch extends the alsa pulse plugin set with a alsa configuration hook. Allowing one to specify some configuration parameters that only come into effect when pulseaudio is running. For example a configution file like: @hooks [ { func on_pulse_is_running pcm.!default { type pulse } ctl.!default { type pulse } } ] will redirect the default alsa pcm and ctl to pulse iff pulse is running. (Assuming you defined the hook function correctly ofcourse) This is usefull for distributions that don't want to force their users to switch completely to pulseaudio, but have things a bit more dynamic :) The solutions isn't optimal though. It will mean that every program loading accessing alsa will try to make an (extra) connection to pulse to decide what to do. But i think it's the best we can do for now (or at least that i can do with my minimal knowledge of alsa). A nicer solution would be a way to always specify the pulse plugin as default and have a sort of fallback for when that fails. Comments on the patch appreciated :) Sjoerd PS: I'm not on alsa-devel, so please keep me in the CC -- GREAT MOMENTS IN HISTORY (#7): April 2, 1751 Issac Newton becomes discouraged when he falls up a flight of stairs.

2 3

[alsa-devel] [PATCH 2.6.26-rc2] ASoC: Fix wrong enum count for jack_function in N810 machine driver
by Jarkko Nikula 13 May '08

13 May '08

Fix this typo and avoid similar errors by using ARRAY_SIZE macro. Signed-off-by: Jarkko Nikula <jarkko.nikula(a)nokia.com> --- sound/soc/omap/n810.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/omap/n810.c b/sound/soc/omap/n810.c index 83b1eb4..6533563 100644 --- a/sound/soc/omap/n810.c +++ b/sound/soc/omap/n810.c @@ -188,8 +188,8 @@ static const char *audio_map[][3] = { static const char *spk_function[] = {"Off", "On"}; static const char *jack_function[] = {"Off", "Headphone"}; static const struct soc_enum n810_enum[] = { - SOC_ENUM_SINGLE_EXT(2, spk_function), - SOC_ENUM_SINGLE_EXT(3, jack_function), + SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(spk_function), spk_function), + SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(jack_function), jack_function), }; static const struct snd_kcontrol_new aic33_n810_controls[] = { -- 1.5.5.1

3 2

[alsa-devel] ARM S3C2410: Trigger start problems
by ing. Davide Rizzo 13 May '08

13 May '08

I experienced a curious problem. My platform is a S3C2410 with a PCM3006 codec connected through I2S. The soc trigger function calls 3 other triggers functions: - first the codec function - then the platform function (that starts dma) - last the the i2s trigger function (that starts i2s peripheral). The dma start function programs and starts the dma peripheral, but the transfer doesn't start because the i2s peripheral isn't started yet. The s3c2410 specific dma start programs the 1st transfer, but before programming the 2nd start it waits about 30ms (2^18 count) in a closed loop for 1st transfer to start. After that delay anyway it fails to program the 2nd transfer. After that, when the i2s trigger function is called the 1st samples' group starts, but nobody preprograms the 2nd sample group in the dma peripheral. When the 1st group ends the dma interrupt service routine is called , but it's too late and the 1st samples' group is repeated twice. I tested 2 solutions: - In the soc trigger function, call the i2s trigger function BEFORE the platform trigger function. I don't know if this solution could broke other platforms, but it's the more correct way to solve the problem. - (platform specific): In arch/arm/plat-s3c24xx-dma.c, at the end of s3c2410_dma_getposition() function, insert a call to s3c2410_dma_started(). That function is periodically called by alsa-lib when playing, and permits dma to program the 2nd buffer before (but it's not guaranteed) the 1st group is completed. With this solution, the programming of DMA till waits for the closed loop. I think this is a patch, but not the correct solution. I wonder if other architectures that use DMA suffer the same problem, so that the 1st proposed solution could help them, too. Davide

2 1

Re: [alsa-devel] Problem with aloop
by Benjamin van den Hout 13 May '08

13 May '08

Gustavo da Silva Serra wrote: Well, I discovered that only xinelib has this problem. Xmms and > alsaplayer, for example, don't have this issue. I am testing VLC and it > seems to work fine. I am not surprised, since the xine source code that > deals with alsa is huge and ugly, it must be very hard to mantain that. > Thanks for your reply! I did some more testing and I can reproduce it as well with the 8bit mode, it occurrs less frequently. When I switch back to 16 bit it takes only a few tries with aplay to get the hiccups. So it seems it is a bit more tricky than I initially thought. Xine can be a strange beast some times, so that's why I used aplay as well. Anybody have some more ideas how to tackle this problem or point me in the right direction so I can solve it myself? It seems I am so close to a working solution... Kind regards, Benjamin

2 1

[alsa-devel] [PATCH] ASoC: build fix for snd_soc_info_bool_ext
by Philipp Zabel 13 May '08

13 May '08

I suspect that snd_ctl_boolean_mono should have been snd_ctl_boolean_mono_info instead. This fixes the build for magician. Signed-off-by: Philipp Zabel <philipp.zabel(a)gmail.com> --- include/sound/soc.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index e6ea6f7..d3c8c03 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -238,7 +238,7 @@ int snd_soc_info_volsw(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo); int snd_soc_info_volsw_ext(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo); -#define snd_soc_info_bool_ext snd_ctl_boolean_mono +#define snd_soc_info_bool_ext snd_ctl_boolean_mono_info int snd_soc_get_volsw(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol); int snd_soc_put_volsw(struct snd_kcontrol *kcontrol, -- 1.5.5.1

3 2

Re: [alsa-devel] [PATCH 1/1] [ASOC]: AD1980 audio codec ASOC driver
by Takashi Iwai 13 May '08

13 May '08

At Mon, 12 May 2008 18:45:12 +0800, Bryan Wu wrote: > diff --git a/sound/soc/codecs/ad1980.c b/sound/soc/codecs/ad1980.c (snip) > +static int ad1980_add_controls(struct snd_soc_codec *codec) > +{ > + int err, i; > + > + for (i = 0; i < ARRAY_SIZE(ad1980_snd_ac97_controls); i++) { > + err = snd_ctl_add(codec->card, snd_soc_cnew( \ The backslash isn't needed. > +static unsigned int ac97_read(struct snd_soc_codec *codec, > + unsigned int reg) > +{ > + u16 *cache = codec->reg_cache; > + > + if (reg == AC97_RESET || reg == AC97_INT_PAGING || \ > + reg == AC97_POWERDOWN || reg == AC97_EXTENDED_STATUS \ > + || reg == AC97_VENDOR_ID1 || reg == AC97_VENDOR_ID2) Ditto. Maybe a switch is a better choice here. > + return soc_ac97_ops.read(codec->ac97, reg); > + else { > + reg = reg >> 1; > + > + if (reg > (ARRAY_SIZE(ad1980_reg))) Isn't it reg >= ARRAY_SIZE(ad1980_reg) ?? > +static int ac97_write(struct snd_soc_codec *codec, unsigned int reg, > + unsigned int val) > +{ > + u16 *cache = codec->reg_cache; > + > + soc_ac97_ops.write(codec->ac97, reg, val); > + reg = reg >> 1; > + if (reg <= (ARRAY_SIZE(ad1980_reg))) And reg < ARRAY_SIZE(ad1980_reg) thanks, Takashi

1 0

[alsa-devel] PCM plugin transfer callback size issue
by Ben C 13 May '08

13 May '08

Hello, I'm writing a PCM external filter type plugin. However, due to the processing I must handle fixed size each time. I can only handle 256 samples at a time. In the transfer callback, there would be no problem if the size is say 1024 each time, I just loop it. But the problem is that sometimes it comes back with other numbers. One instance, it came back with 1114. So I change my code to ONLY process 1024, and return 1024 at the conclusion of the transfer callback, to see if ALSA is smart enough to handle the fact that I didn't process everything. Well, ALSA is smart enough, except the next transfer call, it only sent me the 90 samples that I didn't process. But since I can't process 90 samples, it doesn't help me either; I needed ALSA to combine that 90 samples with the next block of incoming PCM data. My questions: 1) Is there some sort of configuration I can do to constraint the number of samples? 2) I could even manage the extra samples myself with an internal buffer to combine with the next block. But how do I tell ALSA to give me the next block? If I only processed 1024 samples out of 1114, I could store the 90 samples for next time, but if I lie to ALSA and say I did all 1114, wouldn't it try to process 1114 samples instead of 1024? Thanks, Ben ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

1 0