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

[alsa-devel] ASoC updates for 2.6.31
by Mark Brown 22 May '09

22 May '09

The following changes since commit e24805dd85283ac0912b9c400768a4d171b400ff: Atsushi Nemoto (1): ASoC: Add TXx9 AC link controller driver (v3) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.31 Mark Brown (2): ASoC: Make snd_soc_read() and snd_soc_write() functions ASoC: WM9081 mono DAC with integrated 2.6W class AB/D amplifier driver Peter Ujfalusi (5): ASoC: TWL4030: Change DAPM routings and controls for DACs and PGAs ASoC: TWL4030: Move the Headset pop-attenuation code to PGA event ASoC: TWL4030: Add support for platform dependent configuration ASoC: SDP4030: Use the twl4030_setup_data for headset pop-removal ASoC: TWL4030: Differentiate the playback streams include/sound/soc.h | 17 +- include/sound/wm9081.h | 25 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/twl4030.c | 285 ++++++--- sound/soc/codecs/twl4030.h | 5 + sound/soc/codecs/wm9081.c | 1532 ++++++++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/wm9081.h | 787 +++++++++++++++++++++++ sound/soc/omap/sdp3430.c | 7 + 9 files changed, 2559 insertions(+), 105 deletions(-) create mode 100644 include/sound/wm9081.h create mode 100644 sound/soc/codecs/wm9081.c create mode 100644 sound/soc/codecs/wm9081.h

2 1

[alsa-devel] bootup message "Control name ... truncated to ..." - what to fix?
by Andreas Mohr 22 May '09

22 May '09

Hi all, On my i8k, I'm getting this on bootup (2.6.30-rc5): ALSA sound/core/control.c:232: Control name 'Sigmatel Surround Phase Inversion Playback Switch' truncated to 'Sigmatel Surround Phase Inversion Playback ' I would quickly have submitted a patch for this (and similar items), problem is: - what to fix: control name or struct definition? - "Sigmatel Surround" might be a relatively important prefix, thus removing "Sigmatel " from relevant names possibly not a good idea andi@note:/usr/src/linux-2.6.30-rc5/sound$ find . -name "*.c" -o -name "*.h"|xargs grep "Sigmatel Surround" ./pci/ac97/ac97_patch.c:AC97_SINGLE("Sigmatel Surround Phase Inversion Playback Switch", AC97_SIGMATEL_DAC2INVERT, 3, 1, 0); ./pci/ac97/ac97_patch.c: snd_ac97_rename_vol_ctl(ac97, "Headphone Playback", "Sigmatel Surround Playback"); ./pci/ca0106/ca0106_mixer.c: "Sigmatel Surround Phase Inversion Playback ", ./pci/emu10k1/emu10k1x.c: * the PCM Playback Volume, Sigmatel Surround Playback Volume and sound/core/control.c/snd_ctl_new1(): if (ncontrol->name) { strlcpy(kctl.id.name, ncontrol->name, sizeof(kctl.id.name)); if (strcmp(ncontrol->name, kctl.id.name) != 0) snd_printk(KERN_WARNING "Control name '%s' truncated to '%s'\n", ncontrol->name, kctl.id.name); } include/sound/asound.h: struct snd_ctl_elem_id { unsigned int numid; /* numeric identifier, zero = invalid */ snd_ctl_elem_iface_t iface; /* interface identifier */ unsigned int device; /* device/client number */ unsigned int subdevice; /* subdevice (substream) number */ unsigned char name[44]; /* ASCII name of item */ unsigned int index; /* index of item */ }; I suppose (well, DAMN sure) that name is only 44 bytes due to exactly 64-byte cacheline-compatible struct alignment status. Note that status quo is pretty bad, since in another file already: ./pci/ca0106/ca0106_mixer.c: "Sigmatel Surround Phase Inversion Playback ", . IOW we already violate official mixer control name specs (by omitting "Switch" - see ControlNames.txt) simply in order to obey the 44-byte limit. Given that snd_ctl_elem_id 64 byte is a rather hard and arguably important limit, I'd suggest changing the names, but how? Unfortunately Sigmatel Surround PhaseInvert Playback Switch doesn't fit the bill either, since it's one char too long. Thus it will probably be Surround Phase Inversion Playback Switch (and thus changing "Sigmatel Surround" at all affected controls) Thanks, Andreas Mohr

2 3

[alsa-devel] more on appl_ptr and DMA overrun at end of stream
by Jon Smirl 22 May '09

22 May '09

I've been reading Lennart's article on glitch free audio.... On my scatter/gather DMA hardware I generate an interrupt at the end of each period. On the last period this causes ALSA to issue a trigger(STOP). However, there is a latency from when that interrupt is generated and when ALSA does the trigger(STOP). During that latency my hardware starts playing the next buffer (which contains stale data). Playing stale data causes a noise burst. I fixed this by programming my DMA hardware to not overrun appl_ptr. There's another solution. ALSA already knows the stream ends mid-period and pads out the partial period with silence. If it simply padded out the next period with silence too the overrun problem would become non-audible and there would time to process trigger(STOP). If padding out two periods at end of stream is possible, it then becomes possible for me to turn off interrupts in my audio driver. -- Jon Smirl jonsmirl(a)gmail.com

3 5

[alsa-devel] [PATCH 0/1] ASoC: TWL4030: change the streams names for playbacks
by Peter Ujfalusi 22 May '09

22 May '09

Hello, rename the HiFi and Voice playback streams to have unique names to aid DAPM to correctly pick the active playback streams on the twl4030 codec. --- Peter Ujfalusi (1): ASoC: TWL4030: Differentiate the playback streams sound/soc/codecs/twl4030.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-)

2 2

[alsa-devel] [PATCH 0/2 take2] SoC: TWL4030 and SDP3430 HS ramp configuration
by Peter Ujfalusi 22 May '09

22 May '09

Hello, I have found few typos in the patches, resending... he following series adds support for platform dependent Headset pop removal configuration for the twl4030 codec. Platform drivers can fill the twl4030_setup_data structure and pass it with snd_soc_device->codec_data to the codec driver. As an example - based on the feedback for the ramp_delay value variations - the sdp3430.c board is updated to pass the correct ramp settings. If you know for the other platforms using the twl4030 codec the correct HS ramp configuration, please update those files... Mark: This series needs the DAPM restructuring and HS pop removal related patches for twl4030 codec. --- Peter Ujfalusi (2): ASoC: TWL4030: Add support for platform dependent configuration ASoC: SDP4030: Use the twl4030_setup_data for headset pop-removal sound/soc/codecs/twl4030.c | 22 +++++++++++++++++++--- sound/soc/codecs/twl4030.h | 5 +++++ sound/soc/omap/sdp3430.c | 7 +++++++ 3 files changed, 31 insertions(+), 3 deletions(-)

2 6

[alsa-devel] Disabling HFL/R outputs in twl4030
by Lopez Cruz, Misael 22 May '09

22 May '09

It seems that there is no way to disable handsfree L/R outputs for twl4030 codec. That means that: - handsfree amplifiers are turned-on even if we are not interested in routing through handsfree - if the selected input of the handsfree mux is an active DAC (streaming) sound will be produced on hf outputs and the only way to silence them is routing from a different DAC, which doesn't seem like the right solution Currently, handsfree amplifiers are turned-on when the HandsfreeL/R muxes are powered by the framework. I was thinking in adding a dapm switch to select whether or not handsfree amplifiers should be powered, but the switch probably is not the correct approach to handle this situation. Maybe a regular kcontrol could be the answer. -Misa

3 5

[alsa-devel] Releasing a handle without closing ?
by Werner Van Belle 22 May '09

22 May '09

Hello, I have an intruiging problem. I have two processes: a parent and a child. The parent forks off the child (as can be expected, the opposite would be somewhat unsettling), after it allocated and started to write to a pcm device. As can be expected, the child will also have a link to this dsp device. The problem now is that the child wants to release the pcm handle without closing it. Is there any particular function offering such possibility ? Wkr,- -- Dr. Werner Van Belle http://werner.yellowcouch.org/

1 0

[alsa-devel] [patch] ALSA: fix audio on HP TX25xx series notebooks
by Chuck Ebbert 22 May '09

22 May '09

ALSA: fix audio on HP TX25xx series notebooks Fixes https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4121 Taken from https://bugzilla.redhat.com/show_bug.cgi?id=498060 Signed-off-by: Adam Williamson <awilliam(a)redhat.com> --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -12058,6 +12058,7 @@ SND_PCI_QUIRK(0x1028, 0x0253, "Dell OEM", ALC268_DELL), SND_PCI_QUIRK(0x1028, 0x02b0, "Dell Inspiron Mini9", ALC268_DELL), SND_PCI_QUIRK(0x103c, 0x30cc, "TOSHIBA", ALC268_TOSHIBA), + SND_PCI_QUIRK(0x103c, 0x30f1, "HP TX25xx series", ALC268_TOSHIBA), SND_PCI_QUIRK(0x1043, 0x1205, "ASUS W7J", ALC268_3ST), SND_PCI_QUIRK(0x1179, 0xff10, "TOSHIBA A205", ALC268_TOSHIBA), SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),

2 1

[alsa-devel] [PATCH 0/2]ASoC: TWL4030 and SDP3430 HS ramp configuration
by Peter Ujfalusi 22 May '09

22 May '09

Hello, The following series adds support for platform dependent Headset pop removal configuration for the twl4030 codec. Platform drivers can fill the twl4030_setup_data structure and pass it with snd_soc_device->codec_data to the codec driver. As an example - based on the feedback for the ramp_delay value variations - the sdp3430.c board is updated to pass the correct ramp settings. If you know for the other platforms using the twl4030 codec the correct HS ramp configuration, please update those files... Mark: This series needs the DAPM restructuring and HS pop removal related patches for twl4030 codec. --- Peter Ujfalusi (2): ASoC: TWL4030: Add support for platform dependent configuration ASoC: SDP4030: Use the twl4030_setup_data for headset pop-removal sound/soc/codecs/twl4030.c | 22 +++++++++++++++++++--- sound/soc/codecs/twl4030.h | 5 +++++ sound/soc/omap/sdp3430.c | 7 +++++++ 3 files changed, 31 insertions(+), 3 deletions(-)

1 2

[alsa-devel] Program blocks with alsa pulse plugin
by Cristian Morales Vega 21 May '09

21 May '09

I'm not sure where exactly the problem is, probably in the alsa pulse plugin? And not sure where alsa pulse plugin should be reported, ALSA or PA? Using http://byuu.org/bsnes/ through the ALSA API with PulseAudio at some point provokes the game to block with 100% CPU usage. Stopping it I get this backtrace: Program received signal SIGTSTP, Stopped (user). 0x00007ffff2b8a386 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff2b8a386 in poll () from /lib64/libc.so.6 #1 0x00007ffff72ac94c in snd1_pcm_wait_nocheck () from /usr/lib64/libasound.so.2 #2 0x00007ffff72accb7 in snd1_pcm_write_areas () from /usr/lib64/libasound.so.2 #3 0x00007ffff72ebf3a in snd_pcm_ioplug_writei () from /usr/lib64/libasound.so.2 #4 0x000000000043e1b8 in ruby::AudioALSA::sample (this=<value optimized out>, left=<value optimized out>, right=<value optimized out>) at lib/ruby/audio/alsa.cpp:101 #5 0x000000000043ed8b in ruby::AudioInterface::sample (this=0x74c520, left=<value optimized out>, right=<value optimized out>) at lib/ruby/ruby_audio.cpp:110 #6 0x00000000004a5b82 in SNES::sDSP::enter (this=0x8528c0) at dsp/sdsp/sdsp.cpp:199 #7 0x00000000004a309a in SNES::sSMP::op_read (this=0x851860, addr=4532) at smp/ssmp/timing/timing.cpp:8 #8 0x00000000004a2652 in SNES::sSMP::enter (this=0x851860) at smp/core/memory.hpp:2 #9 0x000000000043bec0 in ?? () at lib/libco/x86-64.c:31 #10 0x0000000000000000 in ?? () There are lots of snd_pcm_writei() (lib/ruby/audio/alsa.cpp:101) calls before bsnes blocks, and the only errors are some underruns that are "fixed" with snd_pcm_recover(). Just that at some point (easier to trigger with 150% or 200% emu speed) blocks. It's using the "safe ALSA" everywhere, so... This is with openSUSE 11.1. But also with openSUSE 11.1 + PA from multimedia:libs (0.9.14) and a recent GIT snapshot of ALSA from multimedia:audio:snapshot and multimedia:audio:KMP. There is a package for Fedora in rpmfusion, and they have a readme that states the problem also happens there. To avoid this bsnes dev created a native PA backend. I inform just in case this is triggering a bug, perhaps affecting other software, you are interested in fix... PS. ...obviously bsnes never blocks when using ALSA directly.

1 0