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

[alsa-devel] [PATCHv2 0/4] ASoC: tlv320dac33: Support for turning off codec
by Peter Ujfalusi 03 May '10

03 May '10

Hello, Changes since v1: - patch 1: Removed extra register writes - patch 4: - Let core to bring the codec to BIAS_OFF (set idle_bias_off) - dac33_set_bias_level only takes care of power and minimum initialization - PRE_DAPM widget event is replacing the dac33_pcm_pointer call to take care of the initialization needed before _every_ playback. There are few scenarios, which has to be taken care:: 1. Analog bypass caused BIAS_OFF -> BIAS_ON We need to power on the codec, and do the chip init, but we does not need to execute the playback related configuration 2. Playback caused BIAS_OFF -> BIAS_ON We need to power on the codec, and do the chip init, and also we need to execute the playback related configuration. 3. Playback start, while Analog bypass is on (BIAS_ON -> BIAS_ON) We need to execute the playback related configuration. The codec is already on. 4. Analog bypass enable, while playback (BIAS_ON -> BIAS_ON) Nothing need to be done. 5. Playback start withing soc power down timeout (BIAS_ON -> BIAS_ON) We need to execute the playback related configuration. The codec is still on. Since the power up, and the codec init is optimized, the added overhead in stream start is minimal. Withing this patch, the hard_power function is now only doing what it supposed to: only handle the powers, and GPIO reset line. The codec initialization and state restore has been moved out. --- Peter Ujfalusi (4): ASoC: tlv320dac33: Optimize power up, and restore ASoC: tlv320dac33: Revised module loading, and DAC33 ID read ASoC: tlv320dac33: Manage a pointer for snd_pcm_substream in private structure ASoC: tlv320dac33: Support for turning off the codec sound/soc/codecs/tlv320dac33.c | 235 ++++++++++++++++++++++------------------ 1 files changed, 129 insertions(+), 106 deletions(-)

3 6

[alsa-devel] [PATCHv3 0/2] ASoC: TWL4030: APLL/AIF ordering and DAPM updates
by Peter Ujfalusi 03 May '10

03 May '10

Hello, Changes since v2: apll_enable logic cleaned up. aif refcounting has been removed, aif handling simplified The new DAPM_OUTPUT and DAPM_INPUT widgets renamed Correct the APLL/AIF powering sequence. Also introducing DAPM outputs and input for keeping APLL/AIF enabled in case when no valid DAPM route selected during audio activity. The second patch removes the legacy OUTL/R. As a note: The APLL/AIF patch replaces the same patch in Liam's series. The OUTL/R removal can be applied after the OUTL/R reference has been removed from machine drivers (as in Lima's series). --- Peter Ujfalusi (2): ASoC: TWL4030: AIF/APLL fix in DAPM domain ASoC: TWL4030: Remove OUTL/R outputs sound/soc/codecs/twl4030.c | 86 ++++++++++++++++++++++++++++++------------- 1 files changed, 60 insertions(+), 26 deletions(-)

3 5

[alsa-devel] Reforming S3C I2S towards supporting I2Sv4
by Jassi Brar 02 May '10

02 May '10

Hello, I have prepared some patches that debug and modify the behaviour of extant S3C I2S support towards managing I2Sv4 controllers as well. Overall pic... For now the 'new' I2Sv4 CPU driver(s3c64xx-i2s-v4.c) is almost a copy of s3c64xx-i2s.c The driver will evolve as support for more features is added. Minor quirks in otherwise similar controllers are handled by defining a new field(feature) in 'struct s3c_i2sv2_info' that is meant to contain 1-bit flags for absence/presence of such quirks. The header with I2S register map and bit definitions has been copied to where the drivers are(sound/soc/s3c24xx/) since the header has nothing usable for platform code. Also, it will help avoid need for co-ordination between ASoC and S3C ARCH trees. For now, the header regs-s3c2412-iis.h is left intact but rendered useless by making ASoC drivers include the newly copied version of it (sound/soc/s3c24xx/regs-i2s-v2.h) Later the header could be dropped by patches to S3C PLAT tree. The patches apply against 'for-2.6.35' of http://www.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git Regards. Signed-off-by: Jassi Brar <jassi.brar(a)samsung.com>

6 16

[alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
by Timur Tabi 01 May '10

01 May '10

An upcoming change in the architecture of ALSA SoC (ASoC) will require the MPC8610 HPCD's ASoC fabric driver to register as a standard platform driver. Therefore, we need to call platform_device_register_simple() from the board's platform code. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- Kumar, the ASoC mainters are willing to pick up this patch, but they want an ACK from you first. Or, you could pick it up, since by itself it's harmless. arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c index 5abe137..66afff3 100644 --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c @@ -98,6 +98,9 @@ static int __init mpc8610_declare_of_platform_devices(void) /* Without this call, the SSI device driver won't get probed. */ of_platform_bus_probe(NULL, mpc8610_ids, NULL); + /* Register the platform device for the ASoC fabric driver */ + platform_device_register_simple("snd-soc-mpc8610-hpcd", 0, NULL, 0); + return 0; } machine_device_initcall(mpc86xx_hpcd, mpc8610_declare_of_platform_devices); -- 1.6.5

6 54

[alsa-devel] Relation between SND_PCM_IOPLUG_HW_PERIODS and SND_PCM_IOPLUG_HW_BUFFER_BYTES ?
by Stefan Schoenleitner 30 Apr '10

30 Apr '10

Hi, what is the relation between SND_PCM_IOPLUG_HW_PERIODS and SND_PCM_IOPLUG_HW_BUFFER_BYTES ? While SND_PCM_IOPLUG_HW_BUFFER_BYTES is the setting of the hardware buffer size, I'm not sure exactly what SND_PCM_IOPLUG_HW_PERIODS is. I suppose it is the number of periods the hardware buffer can take ? Hence the SND_PCM_IOPLUG_HW_PERIODS value is actually derived from the size of the hardware buffer ? Or is it rather the number of periods the ioplugin can receive at once ? Please enlighten me, cheers, Stefan

1 0

[alsa-devel] [PATCH 0/4] ASoC: tlv320dac33: Support for turning codec off
by Peter Ujfalusi 30 Apr '10

30 Apr '10

Hello, The following series adds support for turning the tlv320dac33 codec off in BIAS_STANDBY (and obviously in BIAS_OFF). Since the driver already had mechanics for supporting turned off codec in register writes, the needed changes are mainly in the BIAS/stream handling. As part of the series further optimization has been done to codec initialization, resume. The following scenarios has been tested, and verified (I think these are covering all cases): 1. Analog bypass caused BIAS_STANDBY -> BIAS_ON We need to power on the codec, and do the chip init, but we does not need to execute the playback related configuration 2. Playback caused BIAS_STANDBY -> BIAS_ON We need to power on the codec, and do the chip init, and also we need to execute the playback related configuration. 3. Playback start, while Analog bypass is on (BIAS_ON -> BIAS_ON) We need to execute the playback related configuration. The codec is already on. 4. Analog bypass enable, while playback (BIAS_ON -> BIAS_ON) Nothing need to be done. 5. Playback start withing soc power down timeout (BIAS_ON -> BIAS_ON) We need to execute the playback related configuration. The codec is still on. 6. Analog bypass enable withing soc power down timeout (BIAS_ON -> BIAS_ON) Nothing need to be done. This series applies on top of Liam's: git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git for-2.6.35 branch --- Peter Ujfalusi (4): ASoC: tlv320dac33: Optimize power up, and restore ASoC: tlv320dac33: Revised module loading, and DAC33 ID read ASoC: tlv320dac33: Manage a pointer for snd_pcm_substream in private structure ASoC: tlv320dac33: Support for turning off the codec in BIAS_STANDBY sound/soc/codecs/tlv320dac33.c | 236 +++++++++++++++++++++++----------------- 1 files changed, 137 insertions(+), 99 deletions(-)

2 13

[alsa-devel] PCM multi A/V Sync bug on SMP system
by Keith Chew 30 Apr '10

30 Apr '10

Hi I have a SB Audigy Value card with 5.1 channel output. This is defined in my asound.conf: --------------------------- pcm.multi { type multi slaves { a.pcm "dmixerrear" a.channels 2 b.pcm "dmixerfront" b.channels 2 c.pcm "dmixercenter" c.channels 2 } bindings { 0.slave a 0.channel 0 1.slave a 1.channel 1 2.slave b 2.channel 0 3.slave b 3.channel 1 4.slave c 4.channel 0 5.slave c 5.channel 1 } } pcm.dmixerfront { type dmix ipc_key 1024 slave { pcm "hw:0,0" channels 2 } } pcm.dmixerrear { type dmix ipc_key 1025 slave { pcm "hw:0,1" channels 2 } } pcm.dmixercenter { type dmix ipc_key 1026 slave { pcm "hw:0,2" channels 2 } } --------------------------- Playing a video with "mplayer -ao alsa:device=multi ..." works fine, I can hear the 6-channel audio without any A/V sync issues. However, this is on a uniprocessor system. On an SMP system, the A/V sync gets out of sync from the start and drifts quite quickly. I have narrowed it down to the pcm_multi component giving this problem. On an SMP system, using just "mplayer -ao alsa ..." gives no A/V sync issues (because it is not using multi) on the 6 channels. Moreover, I have also tried "mplayer -ao alsa:device=dmixerfront ...", "mplayer -ao alsa:device=dmixercenter ..." and "mplayer -ao alsa:device=dmixerrear ...", all giving no A/V sync issues on the individual devices. Please advise how can I track down this problem in code, happy to make changes and test. PS: I need multi to work, so that I can add additional options like softvol on top of it. Regards Keith

2 3

[alsa-devel] How to retrieve the final data being played by HW
by Yu Hang 30 Apr '10

30 Apr '10

I'm studying ALSA lib and trying to write a plugin that can perform AEC function. I have to retrieve the data being played and use it as reference. I've read pcm_dmix.c and found dmix just simply mixes data into HW mmap buffer (destination buffer). My problem is, there might be several dmix instances, which doesn't know if there is other dmix instance. So how can I know the mixed data is exactly the data being played. For example, the 1st instance had mixes the data into destination buffer, but 2nd instance haven't complete the mix operation. Would the data in destination buffer be playing by HW? Or there is some mechanism to guarantee the data will be played after all mix operation is done.

2 3

[alsa-devel] asoc: problem with snd_soc_dai_set_fmt()
by Timur Tabi 30 Apr '10

30 Apr '10

There is a problem with snd_soc_dai_set_fmt(): int snd_soc_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) { if (dai->driver && dai->driver->ops->set_fmt) return dai->driver->ops->set_fmt(dai, fmt); else return -EINVAL; } Let's say the DAI driver has not defined a .set_fmt() function. This means that if the fabric driver does this: ret = snd_soc_dai_set_fmt(cpu_dai, machine_data->dai_format); if (ret < 0) { dev_err(dev, "could not set CPU driver audio format\n"); return ret; } It's going to think that the DAI driver *rejected* the DAI format. What this means is that I cannot make this function optional. I have to define this function in my CPU driver. May I propose this: int snd_soc_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) { if (dai->driver && dai->driver->ops->set_fmt) return dai->driver->ops->set_fmt(dai, fmt); else return 0; } -- Timur Tabi Linux kernel developer at Freescale

3 5

[alsa-devel] Wrote MIDIcat program, to connect ALSA MIDI to standard input/output
by Josh Lehan 30 Apr '10

30 Apr '10

Hi! A few months ago, I posted about a program to send untimed MIDI data to the ALSA sequencer. Using amidi(1) wasn't acceptable, since it only talks to "RawMIDI" devices. Using aplaymidi(1) wasn't acceptable either, because it required .MID files, and I simply wanted to send untimed MIDI data, similar to what would be produced if you hooked up a hardware MIDI keyboard and just started playing. I needed something more general, that would simply connect to the ALSA sequencer, and let me send arbitrary MIDI bytes to a sequencer destination of my choice. Unfortunately, no program existed that would simply do this. I'm pleased to announce that I've written such a program, It's called MIDIcat, as it works on the same principle as "cat" and other similar programs (Netcat, and so on). It hooks up standard input, and standard output, to the ALSA sequencer. This makes it easy to pipe data around. It's an ALSA sequencer client. Any data that is received on standard input will be forwarded into ALSA. You can choose another client as a destination, or you can just start the program passively and use ALSA's "subscription" mechanism to route the data later. Similarly, any MIDI data that comes from ALSA, will be forwarded along, and provided on standard output. This makes it easy to make many small "one-liner" command lines that are useful for testing and playing around with MIDI data in general. As an example, this plays Middle C: echo "90 3C 7F" | midicat --hex --port "TiMidity" The --hex option makes things more human-readable: standard input and output are hex digits, separated by spaces, instead of just raw binary data. The --port option has the usual ALSA sequencer meaning. Change it to target your synthesizer (I'm using the TiMidity softsynth). Here's another example for output (both of these commands block, so run them in two separate terminal windows): midicat --verbose --hex vkeybd --addr 129:0 The --verbose option prints out some more useful information at startup, such as the ALSA sequencer client:port number it got. That can later be passed into another program, such as vkeybd. If you play notes with vkeybd, you see the corresponding MIDI data appear on standard output. Standard input and standard output can both run at the same time (it's multithreaded). Here's some more elaborate examples: MIDI "panic button", sends "All Sound Off" to each channel: perl -e 'use bytes;for($i=0;$i<16;$i++){print chr(176+$i).chr(120).chr(0);}' | midicat --port "TiMidity" Another MIDI "panic button", sends individual "Note Off" commands: perl -e 'use bytes;for($i=0;$i<16;$i++){for($j=0;$j<128;$j++){print chr(128+$i).chr($j).chr(127);}}' | midicat --delay 10 --port "TiMidity" The --delay option inserts a slight delay between each MIDI command, to avoid flooding ALSA with too much data at once. Here's a fun one, sending random data into the MIDI subsystem and seeing what happens. DO NOT run this on a real synthesizer, there's the risk of composing a random SysEx command that could mess up your settings! It's fun to watch with aseqview(1): aseqview & cat /dev/urandom | midicat --delay 500 --port "MIDI Viewer" If you sent random data to a device that plays audio, you'll probably next want to use the "panic button" commands above...! Hope this illustrates some of the examples and possibilities. I'm working on writing some more documentation. The --help option is supported, there's a help output that shows you all of the available options. For now, the program is available here, on my Web server: http://krellan.com/midicat If you're interested, try it, and let me know what you think! Josh Lehan

2 1