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

[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

[alsa-devel] Impossible to enter bugs on bugtracker for ALSA firmware
by Tim Jackson 13 May '08

13 May '08

It's impossible to enter bugs on the bugtracker for ALSA firmware - the bugtracker says that the "Category" field is not completed - but there are no options for that dropdown! I think this is a bug in Mantis 1.1.0 as I have seen it on other installations. Workaround is to create a category "Default"...

1 0

[alsa-devel] Mono streams
by Nagar, Mrigendra 12 May '08

12 May '08

Hi, I have recently started working on ALSA libraries. I am facing following problems. It would be great help If some one can help me out. 1) Mono streams: If I try to play A MONO streams. It plays Faster. My driver configuration is i) Blocking mode ii) Access mode is interleaved iii) No of channels are set to 1 2) Buffer under run while playing Mono stream. i) Blocking mode i) Hardware buffer size is 65536 ii) Periods is set to 64 I always encounter buffer under run If I try to decode and play a stream frame by frame. Frame size is constant and it is 2048. If I club two frames and Try to play it. It plays well. In second case buffer size becomes 4096. My question is: Is there any optimal buffer size. Which one should set to have smooth payout? Regards, Mrigen

2 1