« Previous | Main | Next »

Coyopa's guts

Post categories:

James Cridland James Cridland | 10:16 UK time, Monday, 23 March 2009

Coyopa, as any regular Radio Labs reader will know, is the new system for encoding BBC national radio stations for the iPlayer and internet media devices - both simulcast and on-demand. It's been running well in production since November, and is now producing all listen-again and most simulcast streams across our services.

If you're deeply interested in the technology we use, here's a quick delve into rather more detail about Coyopa. This isn't for the faint-hearted, particularly if your tolerance for TLAs is low. (What's a TLA? A Three Letter Acronym. LOL. FTW!)

We have used broadcast-engineering principles to implement the new encoding system - such as resilient system design with backups, multiple power supplies, keeping digital audio linear all the way to the encoder.

For simulcast - live streaming - we take the AES3 audio directly from the broadcast chain which feeds DSat/DTT. This is passed through an audio router (for resilience) and then directly into an AES3 sound card. The sound card implements protection limiting in a DSP and carries out other functions such as detecting audio silence (failure alarms). Up to four radio station versions (eg "Radio 2 UK") are encoded on each machine.

For Listen Again, the process is divided into two functions. Linear audio is recorded from the broadcast chain for each radio station, non-stop, and kept for up to seven days. Producers can schedule their radio programmes to be available for Listen Again, by selecting the times/days and repeat patterns (rather like a professional version of a consumer PVR). The system will let you schedule "in the past" too, using its internal store of audio. Users can also select which regions will hear the audio (UK/International) and allow programmes to be automatically published after the show (some programmes have to be edited before being allowed through for compliance or rights reasons). There are different rights restrictions for download (podcast) files, which Coyopa will begin producing later this year, and for streaming files. Producers can also re-edit the programme, particularly the start and end times, at any time to tidy up the audio that listeners hear.

When a programme is ready for encoding, it is sent to a set of sixteen encoding machines, allocated according to the current workload: Radio 3's Through the Night (nearly 6 hours) takes longer to encode than a fifteen-minute news bulletin, after all. Up to four files can be sent for encoding for each radio programme (UK/International, Streamed/Download), and the encoding system knows which formats/bitrates to use for encoding each file. After encoding, the many different encoded files are passed, using FTP, into a large store, which then clones the files to our content delivery partners.

The schedule of radio programmes compounds the encoding workload by having many programmes across the radio stations ending at about the same time; nevertheless, the whole process is designed to be automatic and fast.

The server hardware uses HP "Blade systems" - where each PC server is a plug-in module, with up to 16 in a, very heavy, chassis. Six power supplies share the load of the whole rack, fed from two different sources of mains power. These servers are used because as well as offering the performance, they are reliable, easy to maintain and allow a very high packing density. Each server has two 4-core processor chips which are needed to achieve the throughput for listen again encoding.

As you can see, Coyopa is rather more than a little machine with a sound-card!

I hope all that was interesting to some; and I'm indebted to my colleague David for working on this blog post with me.


  • Comment number 1.

    This is all well & good but all I want is 128kbit/s aac stream or above for BBC Local radio & other stations too. Radio 2 is 128k aac and I want the others to be too.

    I ask is this likely to happen in 2009?

  • Comment number 2.

    I'd be interested in the bitrates selected for each channel/programme - is this information published anywhere? How were the various bit rates selected?

    Also, the post infers that the bit rate might vary between programme types, e.g. 128kbps for music and 64kbps for news bulletins on the same channel. Is this the case?

  • Comment number 3.

    Interesting to read the inner workings of your (fairly heavy-duty) encoding systems. Looks like you're ready to cope with a fairly major throughput!

    Never heard of AES3 before, but I was at home with the other TLAs :)

  • Comment number 4.

    It's great to hear it's a serious resilient broadcast system - I'm sure the day will come when your on-line delivery becomes more important than your traditional broadcast delivery.

    However, if there's so much fault resilience, how come days of radio content go missing on the iPhone?

    Don't believe me? Try listening on-demand to anything from Friday. I've only tried Radio 4, but several things just aren't there: Feedback, Something Understood... I had to visit my PC(!) to catch the last two episodes of book of the week (from the foothills).

    Is Coyopa responsible for this? Or does it go somewhere else?

    btw, the iPlayer on-demand Radio 4 audio sounds quite rough on the iPhone, whereas Radio 3 programmes sound good (sometimes very good), so it's not faulty hardware at this end.


  • Comment number 5.

    Is this used for archiving as well, i.e. beyond the 7 days...

  • Comment number 6.

    "how come days of radio content go missing on the iPhone?"

    The incidence of this seems much higher of late.

    Wednesday 1st had some bits missing, Friday 3rd April had larger chunks missing and Monday 6th seems little better.

    It's not just the iPhone encodings. Book of the Week isn't quite the same when the opening episode just isn't available in "Listen Again" (at a time when there are "3 days left to listen" for Episode 2)! Even unofficial ra files don't seem to be present.

    Given that "Producers can schedule their radio programmes to be available for Listen Again, by selecting the times/days and repeat patterns" it seems that it can all go wrong due to human error/carelessness at a very early stage with no obvious feedback mechanism for frustrated listeners when stuff is simply missing.

  • Comment number 7.

    "Book of the Week isn't quite the same when the opening episode just isn't available in "Listen Again""

    Actually, I note that a substitute is presented at: https://www.bbc.co.uk/programmes/b006qftk

    However, I'm not convinced that Episode 3 of "The Decisive Moment" from 4th March is an entirely acceptable substitute.

    I can cope with the changes to R4's website style but had rather hoped that content wouldn't be trashed along the way.

  • Comment number 8.

    I love this kind of post - it's great when the engineering detail is talked about in the open. One question though (which may show my ignorance). What does "keeping digital audio linear all the way to the encoder" mean? Linear in what sense?

  • Comment number 9.

    @dumbledad - I think in this context, linear audio means uncompressed (in terms of bitrate, not loudness).


Copyright © 2015 BBC. The BBC is not responsible for the content of external sites. Read more.

This page is best viewed in an up-to-date web browser with style sheets (CSS) enabled. While you will be able to view the content of this page in your current browser, you will not be able to get the full visual experience. Please consider upgrading your browser software or enabling style sheets (CSS) if you are able to do so.