This year I’ll be joining Lennart Poettering in helping to organize the audio track, with my particular focus being on the needs of embedded systems. Embedded audio is currently undergoing a rapid evolution, especially for mobile phones, so there’s a lot of exciting work to be done to make sure that the software stack can readily meet the needs of practical applications. Things like the move from analogue to digital audio routing within devices and the increasingly rich audio feature sets provided by systems like smartphones are driving rapid development in this area that has an impact over the full software stack from device drivers up to the application layer.

If you are involved with implementing or deploying the Linux audio infrastructure please join us there to discuss the work that needs doing and help improve the Linux audio experience even further, and please also submit a proposal.

• Support for turning CODEC biases off completely when idle, providing power savings for modern devices with ground referenced outputs where this can be done quickly at runtime without pops and clicks.
• Support for disabling physical writes to the device in the generic cache control code, allowing devices to be completely powered off when idle while still providing their control to userspace through the standard register interfaces.
• Support for tuning the time ASoC waits before powering things down after playback has finished (in order to involve issues between tracks or similar) at runtime or from the machine driver.
• New drivers for DA7210, DB1200 I2S and AC97 controllers, i.MX3x SSI ports, OMAP4 McPDM ports, S3C64xx AC97 controller, SH SIU (Sound Interface Unit), WM2000, WM8904, WM8912, WM8955, WM8978, and WM8994

One of the most interesting decisions I’ve noticed is the model that things have for handling network I/O. At one end of the scale you’ve got iPhone OS which does very little network I/O off-line – it will fetch mail in the background and there’s MobileMe sync but that’s about it. Everything else is triggered by direct user action and is generally visible to them. Even with the mail there’s an element of interactivity – it will notify the user about mail before it’s actually been downloaded, for example. At the other end of the scale the Blackberry does its level best to mask the existence of the network – any updates go on in the background, with the fact that there’s any interaction with a remote system being hidden everywhere except with things like unsent messages. Both these are reasonable choices.

The iPhone model flows from the same place as the decision not to allow background apps, trading interactive performance and a degree of usability (especially where the network is slow or intermittent) for a tight control on things that incur power and bandwidth costs. This avoids surprises, especially given the number of third party apps out there, ensuring that the system always behaves as expected.

The Blackberry avoids the user being troubled by the vagaries of spotty connectivity but also means resources get consumed without user interaction, which can impact performance all round without it being clear to users what the device has been spending resources on. Then again, it’s much less common to use anything except the standard application set on a Blackberry and that is highly optimized for its function – there’s less to be worried about.

I’m not sure I’d say either approach is better – they’re not solving quite the same problem and they’re certainly part of very different systems – so it’s interesting to consider the differences. Personally I find waiting for the network annoying, but then I’m a pretty technical user so the drawbacks in terms of understanding power consumption aren’t so important for me as they will be for many other users.

• New CODEC drivers for ADS117x, AK4671, TLV320DAC33, TPA6130A2, WM8711 and WM8727.
• Support for the PCM port on Samsung SoCs.
• Substantial improvements to DMA performance and reliability on MPC5200 and DaVinci.
• Capture support for the FSI port on SH.

I guess I should’ve actually reported the lintian bug rather than just ignoring the bogus warning.

• Redone power sequencing code, giving shorter power sequences which
  should reduce the effect of any artifacts that exist.
• Reporting of power management decisions via debugfs, enabling much
  easier diagnosis of path setup problems.
• Beginning of work to factor out the register access and caching code
  from the individual CODEC drivers into a shared file.  This needs to
  be rolled out over more CODEC drivers.
• New CODEC drivers for AD1836, AK4642, MAX9877, WM8523, WM8776, WM8961, WM8974 and WM8993
• New CPU support for multi-channel Blackfin SPORT, DaVinci McASP, i.MX2x SSI, and OMAP 1510 McBSP.

To help work with these buses Linux 2.6.32 will follow the clock API and allow the use of the dev_name() for the device instead. A new field dev_name has been added to struct regulator_consumer_supply which should be used instead of dev – this is now the preferred mechanism. It is a simple string and so does not depend on any other initialization.

For those backporting the relevant commit is 744ea1d0b59bf084f19559b8f199b644fbb0899c.

• DAPM supply widget, for automatically managing things like charge pumps and gateable clocks which may be used by more than one widget.
• Core support for setting up constraints for symmetric sample rates (for systems with a shared LRCLK).
• Support for a range of new CODECs: STAC9766, WM8940, WM8960, WM8988, and WM9081
• New CPU support too: MPC5200 AC97 and the I2S interface of the Stretch S6000.

Plus lots of updates and fixes to existing code, especially to the OMAP and TWL4030 drivers.

It’d be nice if it were free software (but again, not the most complex problem). More of an issue are the political and licensing issues that mean it’s BBC only for the forseeable future.

There’s a few  workflows for dealing with this. My preferred one is to track the appearance of my patches in Stephen Rothwell’s linux-next tree, which tracks individual development trees destined for merge into Linus’ tree. I create a git branch based on the current state of this tree then apply the patches I’m submitting on top of that. This lets me spot any potential merge conflicts that they’ll create but the main function is to allow me to come back to the branch later and track which of the patches has shown up in one of the trees that Stephen tracks. To do this I rebase the branch onto the current state of linux-next:

git rebase --onto next/master old-master

where ‘old-master’ is the last linux-next commit in the branch. This will flag up any merge issues that have come up due to changes in other trees and will also handle patches that are already present in one of the trees in -next by dropping my local version. The end result is a branch based on the new linux-next with all the patches that were not yet applied in it. I can see what still needs to be looked at by examining the log

git shortlog next/master..

and take any appropriate action, such as following up with the relevant maintainer or trying to find out what’s going on with the subsytem if it looks like the subsystem maintainers are inactive.

One possible problem with this approach is that a patch may be applied and then subsequently dropped – this is rare but it can happen. I deal with that by also keeping a normal unrebased development branch whch has the changes in Linus’ tree merged  into it periodically and incremental patches for any review updates that occur during the submission process. By looking at the diff between that and other trees I can see any changes that have got lost along the way.