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:
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.
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:
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.
ASoC updates in 2.6.31
Linux 2.6.31 was released today. This was a fairly busy release for the ASoC subsystem, with updates including:
Plus lots of updates and fixes to existing code, especially to the OMAP and TWL4030 drivers.
Let’s hope people can make this work
The new PS3 firmware has an iPlayer client with fullscreen support. It’s not quite broadcast SD quality, never mind HD, but that’s a fairly straightforward problem to resolve and sitting using it last night I couldn’t help but think that this is exactly how TV should work. Full TV screen, on demand and a good UI.
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.
Chasing patches into Linux
One thing that often seems to cause problems for people who work over many different areas of the Linux kernel is the process of making sure that patches actually get reviewed and applied. Where the relevant subsystem is actively maintained it’s not a problem but that’s not always the case. Sometimes maintainers are busy or on holiday and miss things, sometimes there are other problems. In these cases the onus is on the patch submitter to spot the problem and make sure that something is done to ensure that the patch doesn’t get forgotten.
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.
In-kernel audio mixing
Ever since PulseAudio started to be deployed by distributions the most common complaint I’ve seen about ALSA is that unlike current versions of OSS it doesn’t provide mixing of audio from multiple applications inside the kernel. Of course what it really comes down to is that people want the system to transparently allow multiple applications to play audio simultaneously.
The reason ALSA does things the way it does is that the ALSA APIs that applications interact with are actually implemented by a library. This library provides a plugin based way of defining sound cards, one of the options for which is that the audio can be routed to or from some hardware, but sound can also be routed to other places like networked speakers. This architecture also allows plugins to provide signal processing – mixing is the example most people notice but things like soft volume controls (not all sound hardware provides volume control) or EQ are also possible.
This could all be implemented in kernel space but there’s some serious drawbacks in doing so. There are some substantial restrictions on what kernel space code is allowed to do, one of the most relevant being the fact that floating point instructions can’t be used. It’s harder to develop kernel code, if for no other reason than the fact that kernel code can crash the system. The main benefit that people expect from pushing things into the kernel is performance but with the facilities available in Linux there’s no real reason why performance would be better with a kernel mode implementation, kernel and user threads are both scheduled together and shared memory is available.
So why are people running into issues with PulseAudio? Obviously some of them are just bugs in PulseAudio – the much wider deployment that cones with being used as standard in distributions means much wider testing – but that’s not all of it, especially now PulseAudio has been in distributions for a while. The other major source of issues is that due to the need to adapt to the different needs of the applications that it is mixing together PulseAudio is a very demanding user of drivers. This means that switching to PulseAudio can expose bugs in the drivers, often bugs that have existed for years. There’s a natural tendency to blame PluseAudio when this happens but the fixes that are needed are in the drivers.
None of this is terribly helpful if you’ve been bitten by one of the bugs of course, but hopefully it goes some way towards explaining why this implementation has been chosen and why there have been problems.
Full quoting
There’s a long standing idea tha one should make an effort to trim out text from the original which is not germane to the new content in your reply. This is not just a bandwidth thing, it’s also about decreasing the effort required for the readers to parse the message – to locate the new text and refresh their memory of the relevant bits of the conversation. Unfortunately it seems that more and more people aren’t doing the cutting.
This causes issues for me mainly because I do a reasonable amount of my mail reading using my phone. It’s no fun wading through pages of diff on an undersized screen such as a mobile phone when the “content” you’re looking for is a one line comment somewhere in the middle. Even on a full size screen it’s often difficult to locate a small piece of new text, but there it needs a much bigger haystack to be an issue.
Please, if you’re one of the people who do this have pity on those of us Reading your messages on smaller devices!
The Corner
I recently finished David Simon and Ed Burns’ book The Corner, a piece of extended reporting about life around a Baltimore drug corner. There’s one thing about the way they write it which really gets me: every so often they’ll have a section explaining the absurdity of the situation they’ve been talking about, how futile it is. That’s all fairly run of the mill for this sort of investigative journalism. What lifts these sections in The Corner is that they then carry on drilling down, look at the alternatives, the other ways the people involved could act, and all too frequently conclude that crazy as the situation they’ve just described may be it’s one of the better possible outcomes. Letting children pass classes they clearly shouldn’t as a matter of routine may make a mockery of having exams but if there’s nothing to do other than advance them to the next year or keeping them back to disrupt the children the year below them then passing them is possibly the lesser evil.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
