91Èȱ¬

I've been bravely promising a change of audio quality for the 91Èȱ¬'s (UK national) radio online streams; and I'm very aware I owe you an update. It's a peculiar thing, writing a blog post that I know will be read by thousands of people who have part-funded the work I do. So, where we have problems, I want you to know about them - as well as our successes.

First, a recap. Project Coyopa, as you're aware from previous postings, is designed to give better audio quality for 91Èȱ¬ radio. It, variously, takes audio from the broadcast chain rather than re-encoding our satellite feeds; it enables many more formats and bitrates; and it completely re-engineers the system to be much more reliable - both for live and on-demand. Above is a big fan thing from the "P" chain of Coyopa installed in Broadcasting House. (In 91Èȱ¬ engineering there are two sets of equipment like this: the "P" chain and the "Q" chain. There's an interesting history in why we use P and Q, but the point of mentioning that there's a P chain is that there'll also be a Q chain - so we've one set of machines we can use while the others are undergoing upgrades or testing).

We've hit a few bumps along the road, but we're nearly there. Over the next few weeks, you'll spot one or two of our radio stations' live online feeds suddenly leaping in audio quality, as we test out Coyopa and our distribution chain. The tests will be brief but carefully worked out to avoid any reliability issues - we're starting testing with Windows Media, which silently skips any feeds that don't work, meaning we can simply add the new Coyopa feeds to the 'playlist' of live streams that is available. One of the things we're testing is whether the increase in bitrate has a negative effect on our users.

Now, a little has been written about our apparent reluctance to "up the bitrate" of our live streams, and I wanted to debunk a few theories.

First, we're not deliberately keeping online bitrates low to sell a few more DAB sets: we don't care how people listen to the radio, as long as they listen (though if you're on analogue still, you're not getting all the new stations the 91Èȱ¬ is broadcasting, so choose digital where you can).

Second, the bitrate really does matter - many online radio listeners are using congested corporate networks, and working while they listen (where 'working' also means browsing Facebook, downloading lolcats, etc). This is rather different from TV, which it would appear mainly uses home networks which are much less congested; our peak periods for radio have historically been daytimes (9.30am and 3.00pm are fairly standard peaks for all live online radio providers in the UK). And we really do need to get this right - our research points to a very low threshold for rebuffering. Generally, it would seem (looking at figures for listen-again) that almost everyone will tune out of a station, or a piece of listen-again content, that rebuffers more than once or twice. "Hai, plz cn I has no rebuffrn k thnx bye" would seem to be what our listeners are asking for, albeit most of our listeners don't speak . And while our new infrastructure will shortly allow automatic bandwidth detection (so you'll get a high bitrate if your system is capable of it), that's not available yet for our radio streams, and we want to ensure that we choose the right default for the highest amount of users - to give tons of different bitrates would be poor value, and it's you that's paying for all of this, after all.

On rebuffering, you might be interested to know that the current Flash player monitors how many times it rebuffers, so we've got useful data to watch. Irrespective of Coyopa, we're spotting that for some listeners the current amount of rebuffering is unacceptable, and we're trying to understand why this might be. I'd love to give you good news on this, and hopefully will be able to report back shortly.

The third thing to mention is that we are looking at live radio differently than on-demand not because of some hidden agenda, but simply because of these reliability issues and recognising that there are a lot of choices of delivery of live radio - FM, DAB, Freesat or Sky, Freeview, cable, etc. It's entirely possible that, following our tests, we'll plump for the same bandwidth for both on-demand and live; but we're keeping our options open.

So, that's live radio. Better sounding listen-again is already here thanks to iPlayer, but Coyopa will be ready to deliver this in mid-October. This is not particularly a technical piece of work - Coyopa's actually delivering these files already as part of our testing; instead, it's ensuring that the right people have been trained and that we have as short a time as possible maintaining two systems (the previous one is called 'Bob', incidentally, for reasons unknown to me).

Now, on to current iPlayer issues. iPlayer's teething problems have got substantially better since my last report, but here are a few open issues we're aware of:

• A problem with the satellite receivers we use meant that some programmes had gaps in them recently. We switched to an alternative feed for a bit, which had the effect of putting 91Èȱ¬7 in mono among other things, but the satellite receivers now seem happy. We're sorry about that. Coyopa will fix that.
• Generation of Real Audio files for a small amount of programmes has sometimes failed. We think we've got to the bottom of why this happens, and issues are rather fewer of late. Again, apologies to you - particularly PM fans - if this has spoilt your enjoyment. In the majority of cases, Coyopa will fix that too.
• Listeners in live Windows Media format within iPlayer might notice, in a minority of cases, that they get kicked off at precisely 15 minutes after they start listening. A fix is on the way shortly; it would appear from preliminary tests that it might be related to Internet Explorer, and that it's potentially related to the recent Windows XP SP3 update, or similar for Vista. It's early days, so we might be wrong here - but we're working on it; latest information I have is that we might have a fix next week. Coyopa will, eventually, fix that as we add AAC-family flash streaming.

I hope that this blog posting, lengthy though it is, sheds some light on what we're doing. The 91Èȱ¬'s a complicated beast, and it's taking its time to achieve the things I wanted to. I'm sorry things are slower than you might expect - but just as it's important to do things quickly, it's important to do them right, too.