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

[alsa-devel] Questions about /dev/snd and /proc/asound (new ASoC driver)
by Simon Tremblay 12 Aug '08

12 Aug '08

Hi, I have some issues with /dev/snd. First I should explain what I try to do. I am developing a driver for TLV320AIC23B codec and want to use it on a AT91RM9200-based board. I read documentation in sound/soc and created a codec driver (tlv320aic23b) and a machine driver (for my board). I think it's all I have to do since AT91 is supported and tlv320aic23b works with i2c and I2S. When I load my module I obtain that output: # modprobe snd-soc-armus-tlv320aic23b ASoC version 0.13.1 AIC23B Audio Codec 0.1 <6>asoc: aic23b <-> at91-ssc1 mapping ok <6>armus_tlv320aic23b: MCLK rate 12000000Hz armus_tlv320aic23b: Codec in Master Mode (I activated debug in soc-core and in my machine driver (based mainly on eti_b1_wm8731 machine driver)). I think there is no error here for now... But there is no /dev/snd created. I don't know for now why... Maybe someone has an idea? I think all I have in /proc/asound is correct too: In /proc/asound I have this listing: lrwxrwxrwx 1 root root 5 Jan 1 00:02 ARMUSTLV320AIC2 -> card0 dr-xr-xr-x 4 root root 0 Jan 1 00:02 card0 -r--r--r-- 1 root root 0 Jan 1 00:02 cards -r--r--r-- 1 root root 0 Jan 1 00:02 devices -r--r--r-- 1 root root 0 Jan 1 00:02 modules -r--r--r-- 1 root root 0 Jan 1 00:02 pcm -r--r--r-- 1 root root 0 Jan 1 00:02 timers -r--r--r-- 1 root root 0 Jan 1 00:02 version cat cards: 0 [ARMUSTLV320AIC2]: aic23b - ARMUS_TLV320AIC23B ARMUS_TLV320AIC23B (aic23b) cat devices: 0: [ 0] : control 16: [ 0- 0]: digital audio playback 24: [ 0- 0]: digital audio capture 33: : timer cat modules: 0 snd_soc_tlv320aic23b cat pcm: 00-00: TLV320AIC23B PCM aic23b-PCM-0 : : playback 1 : capture 1 cat timers: G0: system timer : 7812.500us (10000000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE cat version (of alsa): Advanced Linux Sound Architecture Driver Version 1.0.15 (Tue Nov 20 19:16:42 2007 UTC). My Linux Kernel version (uname -a): Linux uclibc 2.6.24 #32 PREEMPT Thu Aug 7 16:20:06 EDT 2008 armv4tl unknown. When I try to use aplay it doesn't work. I have this error ouput from aplay: ALSA lib confmisc.c:769:(parse_card) cannot find card '' ALSA lib conf.c:3510:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:3510:(_snd_config_evaluate) function snd_func_concat returned error: No such device ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:3510:(_snd_config_evaluate) function snd_func_refer returned error: No such device ALSA lib conf.c:3982:(snd_config_expand) Evaluate error: No such device ALSA lib pcm.c:2144:(snd_pcm_open_noupdate) Unknown PCM default aplay: main:545: audio open error: No such device I think it's because I have nothing in /dev/snd. I'm right? Thank you, Simon Tremblay

3 3

[alsa-devel] Ideal fragment size and number range
by Rahul Iyer 12 Aug '08

12 Aug '08

Hi All For a reasonably responsive application, what would be the ideal fragment size and maximum fragment number range when set using SNDCTL_DSP_SETFRAGMENT (0xMMMMSSSS)? I understand the answer would correspond to the audio buffer size, but I am not certain about the formula involved here. Also for an hda-intel sound card what's the size of ring buffer (for both recording and playback)? Thanks ../rahul

1 0

[alsa-devel] ASoC suspend/resume
by Dmitry Baryshkov 12 Aug '08

12 Aug '08

Hi, I'm trying to clean up spitz ASoC driver: I need to put some GPIO pins to low during suspend and restore them during resume. What is the most logical place to do that? I can't find any suitable suspend hook. -- With best wishes Dmitry

2 1

[alsa-devel] [PATCH] spitz: MONO -> MONO1
by Dmitry Baryshkov 12 Aug '08

12 Aug '08

Correct route name to be MONO1 instead of MONO to follow recent fix in wm8750. Signed-off-by: Dmitry Baryshkov <dbaryshkov(a)gmail.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/pxa/spitz.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/pxa/spitz.c b/sound/soc/pxa/spitz.c index eefc25b..37cb768 100644 --- a/sound/soc/pxa/spitz.c +++ b/sound/soc/pxa/spitz.c @@ -297,7 +297,7 @@ static int spitz_wm8750_init(struct snd_soc_codec *codec) snd_soc_dapm_disable_pin(codec, "LINPUT3"); snd_soc_dapm_disable_pin(codec, "RINPUT3"); snd_soc_dapm_disable_pin(codec, "OUT3"); - snd_soc_dapm_disable_pin(codec, "MONO"); + snd_soc_dapm_disable_pin(codec, "MONO1"); /* Add spitz specific controls */ for (i = 0; i < ARRAY_SIZE(wm8750_spitz_controls); i++) { -- 1.5.6.3

3 3

[alsa-devel] HDA-Intel - Patch to support new AMD HDMI Audio
by Yang, Libin 12 Aug '08

12 Aug '08

Hi Takashi, This patch is to support new HDMI audio device. Would you please review it? Thanks a lot! --------------------------------------------------------------------- Signed-off-by: Libin Yang <libin.yang(a)amd.com> --- alsa-driver-1.0.17/alsa-kernel/pci/hda/hda_intel.c.orig 2008-08-12 15:33:37.000000000 +0800 +++ alsa-driver-1.0.17/alsa-kernel/pci/hda/hda_intel.c 2008-08-12 15:34:30.000000000 +0800 @@ -2268,6 +2268,7 @@ { PCI_DEVICE(0x1002, 0x793b), .driver_data = AZX_DRIVER_ATIHDMI }, { PCI_DEVICE(0x1002, 0x7919), .driver_data = AZX_DRIVER_ATIHDMI }, { PCI_DEVICE(0x1002, 0x960f), .driver_data = AZX_DRIVER_ATIHDMI }, + { PCI_DEVICE(0x1002, 0x970f), .driver_data = AZX_DRIVER_ATIHDMI }, { PCI_DEVICE(0x1002, 0xaa00), .driver_data = AZX_DRIVER_ATIHDMI }, { PCI_DEVICE(0x1002, 0xaa08), .driver_data = AZX_DRIVER_ATIHDMI }, { PCI_DEVICE(0x1002, 0xaa10), .driver_data = AZX_DRIVER_ATIHDMI }, Thanks & Regards, Libin

2 1

[alsa-devel] How to report error in _pointer function?
by Timur Tabi 11 Aug '08

11 Aug '08

In my driver, I can detect in the _pointer callback function whether or not the DMA engine has actually started. Sometimes, when I have a programming error, the DMA will not start, so my _pointer function calculates a crazy value for the current position. The number it returns causes ALSA to go haywire (see my post titled, "underrun!!! (at least 1786051083.613 ms long)". What is the best way to handle this? Is there a way I can tell ALSA, "hey, this is really screwed up, just abort playback and return an error to the app"? -- Timur Tabi Linux kernel developer at Freescale

2 9

[alsa-devel] [PATCH 1/2] spitz: MONO -> MONO1
by Dmitry Baryshkov 11 Aug '08

11 Aug '08

Signed-off-by: Dmitry Baryshkov <dbaryshkov(a)gmail.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/pxa/spitz.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/pxa/spitz.c b/sound/soc/pxa/spitz.c index 8f5c2ac..dff0f0e 100644 --- a/sound/soc/pxa/spitz.c +++ b/sound/soc/pxa/spitz.c @@ -303,7 +303,7 @@ static int spitz_wm8750_init(struct snd_soc_codec *codec) snd_soc_dapm_disable_pin(codec, "LINPUT3"); snd_soc_dapm_disable_pin(codec, "RINPUT3"); snd_soc_dapm_disable_pin(codec, "OUT3"); - snd_soc_dapm_disable_pin(codec, "MONO"); + snd_soc_dapm_disable_pin(codec, "MONO1"); /* Add spitz specific controls */ for (i = 0; i < ARRAY_SIZE(wm8750_spitz_controls); i++) { -- 1.5.6.3

4 13

[alsa-devel] clicking/noise when upsampling with ESI juli@
by Amaury De Ganseman 11 Aug '08

11 Aug '08

Hi, There's a problem, when I start to play a file the sound is bad during 1sec or less (clicking,cracking,...) or when I switch between tracks I hear clicks. Any idea ? Note: It works very well with OSS driver (last mercurial) Thanks for help. Here my asoundrc: defaults.pcm.rate_converter "speexrate_best" pcm.!default { type plug slave.pcm { type dmix ipc_key 1478 slave { pcm "hw:0,1" format S32_LE #period_time 0 period_size 2048 buffer_size 8192 rate 48000 } } #rate_converter "speexrate_best" #rate_converter "samplerate_best" }

1 0

[alsa-devel] Kill snd_assert()
by Takashi Iwai 11 Aug '08

11 Aug '08

Hi, as some people already mentioned, we have a pretty ugly macro, snd_assert(). Actually, this macro is sometimes useful, but the implementation including the code flow in arguments is really bad. I tried to kill this, either the following way: - replace snd_assert(cond, flow...); with if (snd_BUG_ON(!cond)) flow...; - use WARN_ON() if the check is needed essentially regardless of CONFIG_SND_DBEBUG value - remove snd_assert() for obviously unneeded code-paths The new snd_BUG_ON() macro takes the condition, and works like WARN_ON() if CONFIG_SND_DEBUG=y: prints the warning with stack trace, and returns the evaluated value. When CONFIG_SND_DEBUG=n, the macro returns always zero, so that the compiler will optimize out the unreached flows. Since snd_BUG_ON() takes the condition of a bug, it's a negative condition against snd_assert(). It follows BUG_ON() and WARN_ON(), and easier to understand, IMO. The patches are found on topic/remove-assert branch of my git tree: git://git.kernel.org/pub/scm/linux/kernel/tiwai/sound-2.6.git For gitweb, http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=shortlog;h=… I haven't merged this topic yet. If you have a big objection or a better implementation idea, please let me know. Takashi

2 3

[alsa-devel] [PATCH] wm8750: it's MONO1, not MONO
by Dmitry Baryshkov 11 Aug '08

11 Aug '08

Since first commit wm8750 contained output named MONO, but all routes mentioned MONO1. Correct MONO to be MONO1. Signed-off-by: Dmitry Baryshkov <dbaryshkov(a)gmail.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8750.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm8750.c b/sound/soc/codecs/wm8750.c index e23cb09..2e71394 100644 --- a/sound/soc/codecs/wm8750.c +++ b/sound/soc/codecs/wm8750.c @@ -348,7 +348,7 @@ static const struct snd_soc_dapm_widget wm8750_dapm_widgets[] = { SND_SOC_DAPM_OUTPUT("ROUT1"), SND_SOC_DAPM_OUTPUT("LOUT2"), SND_SOC_DAPM_OUTPUT("ROUT2"), - SND_SOC_DAPM_OUTPUT("MONO"), + SND_SOC_DAPM_OUTPUT("MONO1"), SND_SOC_DAPM_OUTPUT("OUT3"), SND_SOC_DAPM_INPUT("LINPUT1"), -- 1.5.6.3

3 3