Older blog entries for broonie (starting at number 92)

eBooks

Recently I’ve been using ebook readers rather a lot – mostly the Kindle DX, though I have given iBooks a spin as well. Obviously, as with MP3 players, the main win they offer is the ability to easily carry about an entire library without the inconvenience of the physical media. I’ve been reading an awful lot more than before since I started using them, mostly by virtue of it being very easy to keep several books on the go at once. What I’ve found especially good with the Kindle is the ease with which I can flip between devices, taking advantage of the tradeoffs between the different form factors.

Phones are obviously portable and these days have clear, easy to read screens (in most lights anyway) and are very light and easy to hold. They’re great if you’re stuck in a queue or on a bus but the small screen size and the fact that keeping the screen on for an extended period of time runs down the battery which isn’t always desirable. Computers are similar, trading off portability and convenience in the form factor for the larger form factor.

The iPad deals with the screen size issue without much impact on either the form factor or the battery life but the LCD display is hard to read in sunlight and can be hard on the eyes for extended use. E-Ink displays deal with those issues by swapping them for others that mean they can only work for eBooks so the devices aren’t at all general purpose. The first generation of displays had problems with frustratingly long refresh times and less than ideal contrast ratios but these have been largely addressed in current generations of device – current generation displays are beautiful.

Thus far I’ve pretty much just been reading copies of books I already have physical copies of so I’ve not really had a think about how I feel about any of the models for eBook publishing that are floating about out there, or about the DRM issues.

Syndicated 2010-08-27 23:47:07 from Technicalities

Editor (and other) customisations

A discussion the other night suggested that I’m quite unusual among geeks in doing vanishingly little customisation of my system – most of my systems have something very close to their default configuration, individual programs are usually at most a very few tweaks away from their upstream settings.

For Emacs all I tend to do is install revbufs, set Linux mode by default for C and turn on syntax highlighting and line number mode (sometimes the last two only get done when I start Emacs). For vim it’s just configuring a 72 column word wrap if my main use for vi on the system will be writing e-mail. For GNOME it’s putting a terminal launcher in one of the panels and setting focus follows mouse. All very trivial stuff done in five minutes.

The theory here is partly that I just can’t be bothered to spend more time on tweaking things (and the subsequent carrying around of those tweaks) and partly that it ensures that I’m not confused when I end up using a new system or someone else’s for whatever reason. I find it somewhat odd that this would be something you’d want to spend any time on.

Syndicated 2010-08-25 18:54:00 from Technicalities

ASoC updates in 2.6.35

Linux 2.6.35 has been a fairly interesting release from an ASoC point of view, with several notable framework enhancements:

• Support for keeping audio paths through the CODEC up during system suspend, primarily intended for use with devices where the Linux system is one of several independent systems running on the device and the other systems (like the cellular modem in a phone) can maintain useful audio paths even when the Linux system is inactive.
• Enhancements to the jack detection infrastructure, including the addition of notifiers on jack status changes (allowing better integration of physical jack detection with electronic methods) and snd_soc_dapm_force_enable_pin() (which allows DAPM managed supplies such as microphone biases to be forced on). For example, jack status change notifications can be used to enable microphone detection via bias current sense only when a microphone is physically present.
• Support for knot and continuous PCM rates in the core.
• SMDK6410 5.1 audio support, TI SDP4030 audio support, and basic support for playback on the 1133-EV1 PMIC module for Freescale i.MX31ADS systems (currently limited by the support for the SSI interface on the i.MX31).
• Support for DaVinci integrated voice CODECs, Philips UDA1345 CODEC, SuperH FSI2 interfaces, TI OMAP4, TWL6040 CODECs, WM9090 audio subsystem.

Syndicated 2010-08-03 07:08:40 from Technicalities

LPC 2010 – submit your papers now!

As Lennart just posted the Call for Papers for the 2010 Linux Plumbers Conference (LPC)closes this Monday (the 19th of July). The goal of LPC is to get people working on the various projects that make up the key Linux infrastructure where the kernel and application layers meet together so that everyone understands everyone else’s needs and all the components of the system can be made to work together as well as possible. This is the third year the conference has been run, with the previous two years having been very productive, and we hope that the event this year will be equally successful.

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.

Syndicated 2010-07-16 17:24:50 from Technicalities

ASoC updates in 2.6.34

Linux 2.6.34 was released today. This contains a fairly substantial batch of ASoC updates, including:

• 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, WM8994

Posted from Fresno, California, United States.

Syndicated 2010-05-17 04:03:43 from Technicalities

Network I/O

I’ve had the opportunity to use a bunch of different smartphone OSs for extended periods recently. They’ve all taken interestingly different tacks on some of the key stuff, normally all within the bounds of reasonable implementation decisions but with very different results and useful to different people.

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.

Syndicated 2010-03-27 12:17:59 from Technicalities

ASoC updates in 2.6.33

This has been another fairly quiet release for ASoC.  Aside from the
addition of virtual mux support to DAPM and some further preparatory
work for multi-CODEC cards the majority of changes have been driver
updates, including:

• 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.

Syndicated 2010-02-25 09:32:32 from Technicalities

Oh dear…

Subject: zlib_1.2.3.3.dfsg-16_amd64.changes REJECTED

Reject Reasons:
lib32z1: lintian output: 'embedded-zlib ./usr/lib32/libz.so.1.2.3.3',
+automatically rejected package.
lib32z1: If you have a good reason, you may override this lintian tag.

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

Syndicated 2009-12-09 13:10:43 from Technicalities

ASoC updates in 2.6.32

Linux 2.6.32 was released overnight. This has been a fairly busy release for ASoC, with changes including:

• 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.

Syndicated 2009-12-03 10:02:43 from Technicalities

Setting up regulator consumers with dev_name

The Linux kernel regulator API requires that each system sets up the connections between the various voltage and current regulators in the system and the devices they supply, known as consumers within the regulator API. This is done using the struct device for the consumer device as the key for consumer access. This works well for things like platform devices which are generally always allocated at system startup but is not really usable with buses like I2C which only allocate the struct device late on during system startup.

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 9e41f08b9558c0a783826892335088a028d49ca1.

Syndicated 2009-09-16 12:29:13 from Technicalities