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

[alsa-devel] Testers wanted: New SB X-Fi driver
by Ge-org Brohammer 23 May '09

23 May '09

Good day I compiled and installed alsa-lib-1.0.20 and alsa-utils-1.0.20 and then your driver on ubuntu Jaunty 64 bit. I have the X-FI Music PCI card and it seems to split the outputs into separate cards? This is the output from aplay -l **** List of PLAYBACK Hardware Devices **** card 0: XFi [Creative X-Fi], device 0: Front/WaveIn [Front/WaveIn] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 card 0: XFi [Creative X-Fi], device 1: Rear [Rear] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 card 0: XFi [Creative X-Fi], device 2: Center/LFE [Center/LFE] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 card 0: XFi [Creative X-Fi], device 3: Surround [Surround] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 card 0: XFi [Creative X-Fi], device 4: IEC958 Non-audio [IEC958 Non-audio] Subdevices: 1/1 Subdevice #0: subdevice #0 This a problem for me because I cannot play all the channels at once either front side rear, etc... Let me know if any extra info is required. Regards

1 0

[alsa-devel] force byte-swap at soc level before codec?
by Brad Parker 23 May '09

23 May '09

Hi I'm an ALSA SOC newbie. I created a new SOC driver for a new ARM chip but I'm having endian issues at the codec. I started with the pxa soc code since I am failure with the pxa* i2s hardware. The new code is working and data flows fine but due to hardware constraints the bytes arrive at the codec swapped. The codec claims S16_LE. The i2s layer claims S16_LE as does the pcm layer inside soc. The source data in user land is S16_LE. But when the i2s hardware (which I can't change) does dma the bytes go to the codec in reverse order. So, I need a byte swap somewhere. I verified this by sending constant data from user land via the oss compat layer (i.e. /dev/dsp). If I swap them in userland they come out on the scope at the codec in the correct order. Any know the simplest way to do this? I've tried a bunch of ways but nothing seems to work correctly. It seems like ALSA already handles this as long as I tell the right thing from below. -brad

2 1

[alsa-devel] [PATCH 1/1] hdsp: right firmware path
by Raphaël Doursenaud 23 May '09

23 May '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From: Raphaël Doursenaud <rdoursenaud(a)free.fr> Correct firmware path to reflect actual location. This was causing hotplug to fail. Inspired by the emu10k1 module. Signed-off-by: Raphael Doursenaud <rdoursenaud(a)free.fr> - --- sound/pci/rme9652/hdsp.c | 22 ++++++++++++++-------- 1 files changed, 14 insertions(+), 8 deletions(-) diff --git a/sound/pci/rme9652/hdsp.c b/sound/pci/rme9652/hdsp.c index 314e735..48f5434 100644 - --- a/sound/pci/rme9652/hdsp.c +++ b/sound/pci/rme9652/hdsp.c @@ -59,11 +59,17 @@ MODULE_LICENSE("GPL"); MODULE_SUPPORTED_DEVICE("{{RME Hammerfall-DSP}," "{RME HDSP-9652}," "{RME HDSP-9632}}"); + +#define MULTIFACE_FILENAME "hdsploader/multiface_firmware.bin" +#define MULTIFACE_REV11_FILENAME "hdsploader/multiface_firmware_rev11.bin" +#define DIGIFACE_FILENAME "hdsploader/digiface_firmware.bin" +#define DIGIFACE_REV11_FILENAME "hdsploader/digiface_firmware_rev11.bin" + #ifdef HDSP_FW_LOADER - -MODULE_FIRMWARE("multiface_firmware.bin"); - -MODULE_FIRMWARE("multiface_firmware_rev11.bin"); - -MODULE_FIRMWARE("digiface_firmware.bin"); - -MODULE_FIRMWARE("digiface_firmware_rev11.bin"); +MODULE_FIRMWARE(MULTIFACE_FILENAME); +MODULE_FIRMWARE(MULTIFACE_REV11_FILENAME); +MODULE_FIRMWARE(DIGIFACE_FILENAME); +MODULE_FIRMWARE(DIGIFACE_REV11_FILENAME); #endif #define HDSP_MAX_CHANNELS 26 @@ -4928,15 +4934,15 @@ static int hdsp_request_fw_loader(struct hdsp *hdsp) switch (hdsp->io_type) { case Multiface: if (hdsp->firmware_rev == 0xa) - - fwfile = "multiface_firmware.bin"; + fwfile = MULTIFACE_FILENAME; else - - fwfile = "multiface_firmware_rev11.bin"; + fwfile = MULTIFACE_REV11_FILENAME; break; case Digiface: if (hdsp->firmware_rev == 0xa) - - fwfile = "digiface_firmware.bin"; + fwfile = DIGIFACE_FILENAME; else - - fwfile = "digiface_firmware_rev11.bin"; + fwfile = DIGIFACE_REV11_FILENAME; break; default: snd_printk(KERN_ERR "Hammerfall-DSP: invalid io_type %d\n", hdsp->io_type); - -- Raphaël Doursenaud -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoWurIACgkQaZKmNAdXaVVYYACdEyheX1+7sUbWURScDRFV66XV s4gAniZHnEfwRG012ZQmaDAhDhNXQf9Z =Ex8j -----END PGP SIGNATURE-----

2 2

[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