SlimLogic Ltd » Blogs

Multithreaded ALSA capture code with overrun debug

lrg — Wed, 03 Feb 2010 14:09:47 +0000

I’ve been working on some ASoC multi channel capture drivers lately and was in need of a nice analysis tool to show PCM data throughput and PCM buffering information when writing to slow-ish asynchronous memory cards.

SoC memory card controllers tend to write data in asynchronous bursts and usually compete for SoC CPU IO resources with the audio subsystem. This competition for SoC IO resources between the audio and memory card subsystems can often lead to problems for audio. The two most common audio problems are :-

Audio Controller FIFO overruns.
Audio DMA buffer overruns.

Audio FIFO overruns are caused when the DMA controller cannot empty the audio FIFO before the next incoming audio PCM sample is shifted into the already full FIFO. This ultimately causes the FIFO to lose some audio PCM data and potentially also lose left+right channel alignment. FIFO overruns can be minimised by using the largest FIFO possible and by setting the FIFO DMA IRQ watermark to a value that can tolerate high latency. This should be done by the driver and may depend on number of channels capture and rate.

Audio DMA buffer overruns can be caused when any userspace process reading (capturing) the PCM audio data from the ALSA driver does not manage to completely read the data (from the DMA circular buffer) before it is overwritten by new new data (by the DMA). DMA buffer overruns can be mostly eliminated by making sure our capture program can read from the ALSA driver without any hinderance. This can be achieved by having separate reader and writer threads.

I’ve posted some example ALSA multi threaded capture code here. It’s by no means complete and is a little rough around the edges but should be helpful to anyone debuging overrun or buffering issues. It can be built as follows:-

gcc capture.c -lasound -o capture

The program will capture audio data from the default ALSA device until it receives a CTRL-C signal where it dumps the buffering usage data.

ARM Cortex A9 Angstrom Console Image and Tool Chain

lrg — Fri, 22 Jan 2010 18:13:17 +0000

I’ve now managed to successfully build an Angstrom Linux console image and cross gcc tool chain for the ARM Cortex-A9 CPU found on some newer SoC boards. Although unfortunately I’ve not yet had a chance to test this image yet as I’m waiting on the delivery of my new Cortex A9 hardware.

The angstrom-2008.1.conf binutils, gcc and glibc versions used are
PREFERRED_VERSION_glibc ?= "2.10.1" PREFERRED_VERSION_glibc-initial ?= "2.10.1" ANGSTROM_GCC_VERSION_armv7a ?= "4.4.2" ANGSTROM_BINUTILS_VERSION_armv7a ?= "2.20"

Whilst the CPU tuning for Cortex A9 is
# Instead of using -mfpu=vfp[2] we can use -mfpu=neon to make use of gcc intrinsics[1] and vectorize loops with -ftree-vectorize[3] # [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html # [2] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html # [3] https://support.codesourcery.com/GNUToolchain/kbentry29

TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp" FEED_ARCH = "armv7a" PACKAGE_EXTRA_ARCHS += "armv4 armv4t armv5te armv6 armv7 armv7a" BASE_PACKAGE_ARCH = "armv7a"

All the Openembedded files required to build this too chain and image are available via git in the SlimLogic OE omap4 branch.

The repository URL is git://git.slimlogic.co.uk/oe.git for anyone interested in adding it as a remote.

Updated: Seven new Voltage regulator drivers for Linux

lrg — Thu, 27 Aug 2009 18:23:29 +0000

Updated: New regulator drivers for the Freescale MC13783, Motorola PCAP2, Wolfson WM831x, Texas Instruments TPS65023 and TPS6507x, Marvell 88PM8607 and ST-Ericsson AB3100 have been accepted into the Linux voltage regulator development tree and will be heading for the mainline kernel in the next merge window. This should approximately take place in the next month and mean the drivers will be included in Linux 2.6.32.

Linux Voltage Regulator for 2.6.30

lrg — Thu, 16 Apr 2009 11:37:55 +0000

The changes for 2.6.30 include a new twl4030 regulator driver, improved regulator init_data
handling, refcount fixes, some new voltage API functions and numerous minor fixes. Full change log:-

Adrian Hunter (1):
regulator: twl4030 VAUX3 supports 3.0V

Andrew Morton (1):
regulator: minor cleanup of virtual consumer

David Brownell (10):
regulator: minor cleanup of virtual consumer
regulator: add get_status()
regulator: enumerate voltages (v2)
regulator: get_status() grows kerneldoc
regulator: twl4030 regulators
regulator: twl4030 voltage enumeration (v2)
MMC: regulator utilities
twl4030-regulator: list more VAUX4 voltages
regulator: refcount fixes
twl4030-regulator: expose VPLL2

Jonathan Cameron (1):
Regulator: Push lock out of _notifier_call_chain + add voltage change event.

Liam Girdwood (1):
regulator: email – update email address and regulator webpage.

Mark Brown (16):
regulator: Pass regulator init data as explict argument when registering
regulator: Allow init data to be supplied for bq24022
regulator: Allow init_data to be passed to fixed voltage regulators
regulator: Make fixed voltage regulators visible in Kconfig
regulator: Mark attributes table for virtual regulator static
regulator: Hoist struct regulator_dev out of core to fix notifiers
regulator: Suggest use of datasheet supply or pin names for consumers
regulator: Allow regulators to set the initial operating mode
regulator: Fix get_mode() for WM835x DCDCs
regulator: Implement list_voltage() for WM8400 DCDCs and LDOs
regulator: Don’t warn on omitted voltage constraints
regulator: Implement list_voltage for WM835x LDOs and DCDCs
regulator: Allow boot_on regulators to be disabled by clients
regulator: Don’t warn if we failed to get a regulator
regulator: Don’t increment use_count for boot_on regulators
regulator: Support disabling of unused regulators by machines

Mike Rapoport (1):
regulator: add unset_regulator_supplies to fix regulator_unregister

Randy Dunlap (1):
regulator: fix header file missing kernel-doc