Here in the UK, Ö÷²¥´óÐã Sounds is now one of the most popular audio apps available, and just had its best quarter ever. We’re seeing around 3.5 million people a week listening to the Ö÷²¥´óÐã on Sounds across the app, website, connected TVs and voice-activated devices – more than we’ve ever seen before.

There are also millions of people who watch, listen and read Ö÷²¥´óÐã content outside the UK – we recently announced the Ö÷²¥´óÐã had reached an all-time record global audience of 468 million. Until now, Ö÷²¥´óÐã Sounds has only been available for those international listeners through the website, and people who’ve wanted to listen to the Ö÷²¥´óÐã through an app have had to use the old international version of the iPlayer Radio app. Now though, the time has come to turn off the old international iPlayer Radio app and transition those users over to Ö÷²¥´óÐã Sounds.

From today, the Ö÷²¥´óÐã Sounds app will begin to be made available to download on international app stores, available for devices capable of running iOS 11, Android 5 or Amazon OS 5 or above. People who currently use the iPlayer Radio app outside the UK will now begin seeing messages encouraging them to download the Ö÷²¥´óÐã Sounds app and switch over. At some point in the near future, the iPlayer Radio app will stop working, and listeners will need to get the Ö÷²¥´óÐã Sounds app to continue listening.

This change won’t affect the content international listeners can enjoy. They’ll still be able to listen to all their favourite Ö÷²¥´óÐã programmes, the wide range of Ö÷²¥´óÐã radio stations will be available to stream live, including the World Service. Popular radio programmes like The Archers, Desert Island Discs, and Radio 5’s Elis James and John Robins show will be available to listen to on-demand, as well as the wide range of hit podcasts from the Ö÷²¥´óÐã, including Grounded with Louis Theroux, That Peter Crouch Podcast and George the Poet’s fantastic Have You Heard George’s Podcast?

Ö÷²¥´óÐã Sounds will now also offer international listeners a personalised experience they didn’t get with iPlayer Radio, receiving tailored recommendations based on what they’ve been enjoying and the ability to pick up where they left off with their favourite shows. International listeners can also stream Ö÷²¥´óÐã Sounds to their Chromecast device, and enjoy the improved experience for Android Auto and Apple CarPlay, which offers a larger choice of content from the dashboard than the old iPlayer Radio app did.

These changes won’t impact people within the UK, and we’re excited that international listeners will now be able to get the much-improved experience Ö÷²¥´óÐã Sounds offers.

Here in the UK, we’re bringing the Ö÷²¥´óÐã Sounds TV app to more devices. Since first launching in March on Virgin Media and YouView, the Sounds TV app has also come to some Sony and Samsung TVs – giving people with those devices another way to listen to their favourite music, radio and podcasts from the Ö÷²¥´óÐã. From today, we’ll begin rolling out the TV app on Roku streaming devices, and we’ll be bringing it to more devices in the coming weeks.

We hope you enjoy this update, and that our international listeners enjoy the new Sounds experience. We’ll be bringing more updates in the future to make Sounds even better, and we’ll keep you posted.

Update: Since we last told you about the Ö÷²¥´óÐã Sounds on TV app, we’ve made some updates to the app and launched it on several new devices. The Sounds TV app now has search functionality, and viewers can now access their personalised My Sounds section on the TV app experience as well as on the mobile and web versions of Sounds.

We’ve also launched the Ö÷²¥´óÐã Sounds TV app on a number of new devices, including Now TV, Roku, Freesat, LG, Freeview Play, and Google TV, and as of today we’re bringing it to all Amazon Fire TV devices too, including sticks and smart TVs. Anyone with those devices will be able to find and add the app, and enjoy all of our best live and on-demand radio, music mixes, and fantastic podcasts like the new series of Grounded with Louis Theroux, Bex Smith’s women’s football podcast The Players and iconic rapper Eve’s new podcast Constantly Evolving.

Update #2:  The Ö÷²¥´óÐã Sounds TV app is now also available on Sky Q. You can find the app on the SkyQ screen, or just say “Launch Ö÷²¥´óÐã Sounds” into your Sky Q voice remote, and start easily listening to your favourite music, radio and podcasts from the Ö÷²¥´óÐã.

Eleanor van Heyningen, Chief of Staff to the Chief Technology and Product Officer and Asha Knight, Distribution Manager in Digital Partnerships, explain how in-car radio listening is evolving and the Ö÷²¥´óÐã's approaches to this. 

Earlier this month at the in Geneva, we spoke about the future of listening in cars. As one of the hottest topics in the radio world at the moment it seems like a good moment to set out how the Ö÷²¥´óÐã is thinking about this. In summary:

1. Radio listening in-car is really important for the Ö÷²¥´óÐã and it’s audiences;
2. We are completely committed to maintaining it for the next generation; and
3. It’s absolutely critical to work in partnership to achieve this aim.

Radio is at the heart of the Ö÷²¥´óÐã’s offer. We have 10 network radio channels, 6 Nations radio channels and 40 local channels listened to by a total of 33.5m people in the UK every week. In 2018, we launched Ö÷²¥´óÐã Sounds – the digital home for all audio from the Ö÷²¥´óÐã. Sounds now has over 3m weekly users and making sure Sounds is widely available and easily accessible at home, on the go and in cars is a top priority.

A lot to play for...

A large proportion of the time audiences spend with the Ö÷²¥´óÐã is in the car. Roughly a third of all radio listening takes place in the car, which represents around 13% of all time spent with the Ö÷²¥´óÐã by our UK audiences.

Encouragingly, since 2012 there has been a 17% growth in UK in-car radio listening, with other types of audio like streaming music and podcasts also seeing similar growth. For about half the time spent in cars, we’re not listening to anything. Of course some of this will always remain ‘silent’ because of very short journeys or the difficulty of reaching agreement between parents and children about what to listen to! But it shows that this is not a saturated space – there is a lot to play for.

We can’t take these conditions for granted. From the significant gaps between the time younger audiences spend with live radio compared to others, to the connected car and big tech’s role in it – the market is changing. Although the enduring popularity of radio in car gives us reason to believe that there is still a lot we can do to retain and grow our audiences, the changing market means that broadcasters are not the only ones in the game.

Strength in-cooperation

We’re constantly talking to audiences and learning from other broadcasters and car companies about how in car listening habits are developing. But, however much we know about audiences, it‘s clear that no broadcaster alone can do everything to meet modern audiences’ needs when it comes to in car listening.

Without some protection, broadcasters will lose the essential benefits that provided the foundation for the pre-digital market: prominence for radio in the infotainment space; editorial control over what and how content is delivered; direct attribution back to the content makers’ brand and – for commercial broadcasters – the ability to receive revenue directly from advertising.

In addition, in the emerging, fractured market broadcasters are at risk of losing probably the most important key to success in the digital world: the ability to gather and use audience data.

The best way to counter these risks is to work together as an industry in delivering high quality hybrid radio experiences into cars, direct to a fully connected dashboard.

Hybrid radio moves seamlessly from broadcast to IP, allowing the listener to enjoy the best available signal quality and stay tuned-in whether they are receiving DAB, FM or IP. It has the potential to allow listeners to enjoy on demand content as easily as live by providing easy links into apps like Ö÷²¥´óÐã Sounds. As we transition gradually to all IP-world, we need to take audiences with us.

Radioplayer

The Ö÷²¥´óÐã is a shareholder in a joint venture, , that aims to do just that. Radioplayer has been around since 2010. There are four UK shareholders, including the Ö÷²¥´óÐã and since 2014 it has licensed its technology to consortia of broadcasters in other territories.

Investing in Radioplayer is key in our aim to preserve radio in cars and build on demand in addition to linear while maintaining a direct relationship with our audience. Every country and every broadcaster is different, but we believe that we are all united by three core needs that Radioplayer meets:

• Providing a flexible, easy to scale, easy to customise metadata delivery system that has the potential to deliver the best API for radio, making it a unique one-stop-shop for car companies who want to offer their customers a great radio experience
• Complementing, not competing with broadcaster apps with a simple listening and discovery service that will develop to support our long-term strategies
• Offering the chance to work together to secure the future of radio in car, in turn bringing a better chance of preserving the essential benefits mentioned above: prominence, attribution, data.

We are actively encouraging our fellow broadcasters to talk to Radioplayer about how they can get involved.

Working together for listeners

We want to cater for people whether they are long-time radio devotees, first-time digitally-native car-owners or even very young passengers in the back seat. Whatever avenues we explore, we want to do it in co-operation with our fellow European broadcasters. We’re confident that linear radio remains a strong force, but we also know that we need great digital products that have amazing content and are intuitive to use.

Voice assistants, for example, have huge potential in the car, and the Ö÷²¥´óÐã recently announced plans to launch a digital voice assistant this year. We’re incredibly excited about the potential of this and other technologies, but we understand that consumers will only get the benefit of them if we work in close partnership with companies all along the supply chain.

We can provide more choice which is free from commercial and political influences in a way that respects listeners’ privacy and protects their data. These are characteristics that we want to preserve in-car, but we’ll struggle to do so if we are blocked from managing our own audience data, prevented from playing back our content within our own product or forced only to use voice assistants that don’t given prominence to our content.

We are encouraged by signs that tech companies are thinking about inter-operability. We also want to open up more conversations with car manufacturers to understand their needs and ensure that, however they develop, accessible radio in a connected dashboard will be central to their offer.

Of course, our resources aren’t limitless – far from it. There are more pressures on the licence fee than ever before and we face tough choices about where we can invest and grow. We intend to work pragmatically with our broadcasting colleagues, car and technology partners, striving for standardisation and seeking a level-playing field for cooperation.

There should be no doubt that ensuring a thriving, innovative future for radio is a high priority for the Ö÷²¥´óÐã, and making sure people can listen in cars in both traditional and new ways is a big part of that. The only way we can achieve that long-term success is to work together as a united radio industry, in close cooperation with both tech and car companies, guided – always – by the best interests of audiences.

Datalab was assigned this brilliant and fun challenge and began collaborating with the Sounds team, using a multidisciplinary group made up of data scientists, engineers, editorial specialists and product managers.

The team had some prior experience building personalised recommendations for our video clip app Ö÷²¥´óÐã+. For Ö÷²¥´óÐã+, the recommender was purely content based, using existing metadata information such as genres (e.g. Drama/Medical) or brands (e.g. Glastonbury Festival). This would probably have been a good approach if our content had been labelled for the express purpose of personalisation. However, the Ö÷²¥´óÐã’s production workflows were designed to meet the needs of broadcast systems, and we didn’t always have all the labels we would have wanted for recommendations.

come with the enticing promise of combining content-based recommendations with collaborative filtering.

Using a standard content-based approach, if a user had listened to podcasts from the genre ‘Health & Wellbeing’ the system would recommend a new episode from Radio 1’s Life Hacks but it could also recommend Radio 4’s Inside Health, which has a very different tone of voice. By contrast, collaborative filtering matches programmes based on what similar users have enjoyed — so if they listen to Radio 1’s Life Hacks, they might be recommended Radio 1 comedy. This model relies on ‘adjacent’ content similar to the recommendations found in shopping websites where ‘customers who bought this also bought that’. This approach often leads to better recommendations for established content, but is less effective for fresh content that hasn’t been consumed by significant numbers of people. Since the Ö÷²¥´óÐã continuously produces new content throughout the day this recommendation strategy by itself would be limiting.

Factorisation machines are a smart way to combine both. They have been around a few years, and open source toolboxes exist to support them. Our team programs primarily in Python, so we wanted a toolbox that integrates with that. Obviously, we also wanted it to be fast, give superior results and be easy to use (more on that later…).

We stored user-item interactions (i.e. the programmes a specific user has listened to) in a BigQuery table. The programme items with the corresponding genre and brand metadata were in a different table, and both needed to be assembled in the correct format for the factorisation machines. Our first choice of toolbox was xlearn. The code seemed relatively mature, running a first test example was easy, and the toolbox offers a variety of different flavours in terms of learning algorithm. But it was hard to get the data into the correct format and, even now that we have a version up and running, we’re still not sure we got everything right — mainly because the initial results are nowhere near as good as we had wanted (and expected) them to be!

The quality of recommendations can be subjective and we needed a way to test them before making them live anywhere on the Ö÷²¥´óÐã’s websites or apps. Predicting past behaviour is one way of doing this, but also comes with all sorts of problems: users only click on what they see, a piece of content might be brilliant, but if it does not appear in the results, the user will not see it and cannot click on it. Recommending the most popular items generally gives good numbers (as by definition these items get the most clicks), but rarely leads to recommendations of fresh content. In practical terms, it’s also a lot of work to set up if your data is stored in ways that were not devised with the ease of access for data scientists in mind…

So we decided to test the results using qualitative evaluation, asking about 20 editorial and other non-technical people to judge our new recommendations against those from an existing provider. We didn’t tell them which set came from which recommender! We used the individual history of the internal test participants to generate the recommendations by both providers and asked for their preference and general feedback.

Most of our test users preferred the recommendations we currently have live to our first set of test recommendations and we weren’t keen on them either, so we knew we had more work to do.

With the overall infrastructure set-up, it was quite easy to swap out the toolbox we’ve used for the factorisation machines. We had previously looked at and it had a much simpler data format, so we decided to give it a go. We were able to compute new recommendations and run another qualitative experiment in less than two weeks. Our recommendations looked much better, and our test users agreed! However, these are still first results. We don’t feel we’ve fully solved the problem of recommending popular items versus programmes that are strongly tailored towards a specific user’s interests, and are looking into ways to improve this.

We are happy with the results so far, but there is still a lot of work to do to bring the recommender into production. The infrastructure needs decidedly more work to make it robust and able to scale, and we’d like to do more testing. Having a variety of offline metrics should help us to optimise parameters, and test new algorithms without having to go back to our testing panels every few days. We’re also still looking at a simple content-based recommender to have another baseline, so more results hopefully soon.

We also still have some more fundamental questions that we hope our practical work will help us to answer. For example, can we use the same approach for recommending entertainment as for news, or do we need specialised systems for each domain? And what if we change the medium and move from audio and video to text, or new interfaces like voice controlled devices? Even if the overall editorial guidelines do not change, we might need different technical approaches to be able to achieve them. But we also want to avoid starting from scratch for every new recommender we build, and we’re still trying to figure out how best to do that. In summary, there is lots to do, but it’s exciting and we’re enjoying the challenge!

Want to work with us?

This feature will be available to anyone who has linked their Ö÷²¥´óÐã account to their Alexa account - you can do this by clicking on the Settings button for the Ö÷²¥´óÐã skill in the Alexa app.

Continue Listening is just the latest in a number of changes we’ve made to the skill since it first launched.

Accessing all your favourite content

You can easily find Ö÷²¥´óÐã Sounds radio stations, podcasts and on-demand programmes simply by saying the name of the station or show. For example, say “Alexa, ask the Ö÷²¥´óÐã to play six music” or “Alexa, ask the Ö÷²¥´óÐã for Woman’s Hour”. You can also ask for any of Ö÷²¥´óÐã Sounds Music Mixes like “Handpicked by 6 Music” or “The Takeover Mix”.

Finding out track and artist information

It is now possible to ask Alexa for information about the track that’s currently playing on our live radio stations, just by saying “Alexa, ask the Ö÷²¥´óÐã what’s playing?”. Ö÷²¥´óÐã radio is a popular way for people to discover new music and this will make it much quicker and easier to find out what it is you are listening to.

Using our audio player controls

In response to many audience requests, we have worked hard to allow easy navigation between and within podcast and on-demand programmes. To navigate between episodes in a series, just say “Alexa, next” or “Alexa, previous”. If you miss something when listening to an on-demand episode and you want to go back, just say “Alexa, ask the Ö÷²¥´óÐã to rewind 30 seconds”. Or if you want to skip forward to find the section you are interested in, just say “Alexa, ask the Ö÷²¥´óÐã to fast forward 5 minutes”.

We hope that these new features will make it easier for you to quickly and easily play and control your favourite Ö÷²¥´óÐã Sounds content using your smart speaker. We’ll continue to listen to your feedback - it’s vital for helping us prioritise new features to build and release.

We’re also introducing support for Apple CarPlay and Android Auto, enabling drivers to safely enjoy Ö÷²¥´óÐã Sounds whilst behind the wheel. This support was available for iPlayer Radio, but for Sounds we’ve built and improved upon the experience, offering drivers a larger choice of content from the dashboard.

Listeners will have four main sections to explore: My Sounds, which brings your Bookmarks, Subscriptions and your Latest list into one handy place, just as it does on the app; Browse, which provides a route to explore music mixes and recommendations; Stations which lets you listen to our live radio stations; and Downloads, where, as you’d expect, you’ll find everything you’ve downloaded on the app.

To use the new in-car experience, Android owners can either connect to a compatible car display or download and run the Android Auto app on any Android phone running Android 5.0 or above, while iPhone owners will need an Apple CarPlay-equipped vehicle.

These updates are the latest in a number of changes we’ve made to the app since it first launched. We recently introduced live rewind and live restart on the Ö÷²¥´óÐã Sounds app, which means listeners can now restart any live programme and listen to it from the beginning, or rewind to any point in the live programme and pick it up from there. They can also pause a live stream and later resume from where they left off or jump back to live. It’s been a really popular feature on the web, but is a new feature for the Ö÷²¥´óÐã Sounds app, one that wasn’t available on the Ö÷²¥´óÐã iPlayer Radio app.

We’ve also added the popular sleep timer feature from iPlayer Radio, so that people can make sure the programme or station they’re playing stops after their chosen amount of time. We’ve added a share button, so that people can easily share their favourite programmes on their social media.

Other updates we’ve made include autoplay, which automatically cues up other episodes in a series or a recommendation after the thing you’re listening to has finished, we’ve started displaying the shows you’ve been listening to and how far through you are on the home screen, and Siri Shortcuts, which lets you set and use a personal phrase to launch Ö÷²¥´óÐã Sounds and quickly play your favourite Ö÷²¥´óÐã stations.

And we’re not done yet. There’s lots more functionality coming very soon to the Ö÷²¥´óÐã Sounds app, including Chromecast support, which we know some of our listeners are really keen on, showing more programme information for live and future programmes and a major revamp of categories, which will introduce sub-categories (e.g. crime drama), a new podcast category and different sort options. We’ll also soon be enabling listeners to open tracks they discover in our music mixes and on-demand programmes in Spotify or Apple Music.

As mentioned at the top of this post, feedback’s been an important part of making the Ö÷²¥´óÐã Sounds app what it is today, and it’ll continue to be vital in how we develop the app going forward. Please keep it coming, it’s invaluable.

One Star!

“Catastrophic”. “Disappointing”. “Pointless”. “Awful”. “Baffling and lacking”. “Useless compared to iPlayer Radio”.

Those are just some of the things users have been saying in reviews of the new Ö÷²¥´óÐã Sounds mobile app.

Reading one star reviews about something you work on requires an ability to avoid taking things personally &³¾»å²¹²õ³ó; even when they can become seemingly quite personal.

I’m the Software Engineering Team Lead on the Ö÷²¥´óÐã Sounds App team. It might sound strange, but I have a personal favourite one-star review. The wording is always different but the message is the same. It’s the review which says “this app was released too soon &³¾»å²¹²õ³ó; it’s not ready yet”.

Why is this my favourite? Because it manages to be entirely right while also being entirely wrong, and succinctly describes exactly what we’re trying to do.

Release Early, Release Often

An app is a culmination of thousands of decisions, big and small. Our first major decision was to make a new app for Ö÷²¥´óÐã Sounds instead of converting iPlayer Radio, which this team also built and is responsible for maintaining. We’d been tasked with making a new product to combine the best of the Ö÷²¥´óÐã Music and iPlayer Radio apps. Converting would have meant reworking nearly every part of iPlayer Radio’s codebase, fitting a round peg into a square hole. On top of that, when we released Sounds, iPlayer Radio users would have had to move immediately instead of having a transition period.

Another early decision was to get all the data the app needed from a single source &³¾»å²¹²õ³ó; the new ‘Experience API’ built by the Radio & Music Services (RMS) team, which — instead of the variety of different back-end services iPlayer Radio fetched information from.

Decisions like these freed us from assumptions made long in the past, as well as reducing the size of the problems we would need to solve and allowing us to focus on exactly what a mobile team should be focusing on: building the best, most reliable, most usable and most beautiful app we could build.

For our fresh start, we began with one simple aim: connect to a server and show either a green or a red box, depending on what response we got. It’s a simple concept, but immediately we had even more decisions to make.

We decided to write our new app entirely in Swift on iOS and in Kotlin on Android . These are modern programming languages which had only recently taken over from Objective-C and Java (as used in iPlayer Radio) as the standards for mobile development. We decided on an N-tier architecture for the app and MVVM(ish) for the UI layer. We made decisions about what frameworks we should use for making network requests, dependency injection techniques, a ‘bootstrapping’ system for the app so we could manage app startup logic in a single place. We created Services and Coordinators and Factories and Repositories and View Models.

Crucially, we made these early decisions together as a team, because we decided to ‘Mob Program’ through the initial stages of development. This meant all the engineers, Android and iOS, gathered around a single screen and worked together across both platforms for the first few weeks. We all learned together how our new app would work, we all agreed on how we should be writing code, and we could all help each other when problems arose. Even now, though mob programming across platforms is not as common, we are still able to collaborate as a whole team and help each other solve problems.

When we’d finished with our red and green boxes, we decided to make a release. We acted as if this would be the version that was going out to the public and we tested it thoroughly. That was Version 0.1. Version 0.2 brought the ability to sign in to a Ö÷²¥´óÐã account before you saw the green box. Version 0.3 added the first version of the Listen page, and in Version 0.4 we added the audio player. In a handful of weeks we’d gone from green and red boxes to a workable audio app. From there we just kept on iterating.

An app is never late. Nor is it early. It arrives precisely when it means to.

In June 2018, we released an app which did the most important things &³¾»å²¹²õ³ó; allowing you to discover, bookmark and listen to all sorts of Ö÷²¥´óÐã content &³¾»å²¹²õ³ó; but with some glaring and important omissions. Releasing to the public is a huge moment for an app, but thanks to the months we’d spent practicing making releases it didn’t feel like such a big deal. Rather than having to switch gear from ‘pre-release’ to ‘live maintenance’, we were ready to iterate again and release again.

In the four months since our initial version came out, we’ve released 10 new updates to the Ö÷²¥´óÐã Sounds app on each platform, an average of one update every two weeks. These were not small releases, either &³¾»å²¹²õ³ó; we’ve added big important features like downloads, station schedules and episode track listings, as well as fixing major issues such as remembering and displaying your progress through an episode throughout the entire app, not just in the Continue Listening section.

It’s not something everyone wants to admit, but some of the decisions we make turn out to be mistakes. Some of these mistakes are obvious from the moment we try prototyping them, some come out when we do usability testing, some take a while to shake out and mean revisiting things we thought were done. There’s mistakes in our codebase, mistakes in our UI, mistakes in our decisions about which features are most important. We can never really be sure until we hear from real users in the real world.

We’ve had lots of feedback from users about Sounds, some from users who really love the app, some from those that don’t. We use that feedback, especially the critical comments, to help prioritise and decide on what we should do next. It’s a balancing act, where we want to make sure the app works well for users moving over from iPlayer Radio, but works just as well for users who are new to radio entirely, and for younger audiences who we know were under-served by iPlayer Radio.

What we’ve done so far is just the beginning. We’re a team of radio, podcast and music enthusiasts who want to build the best audio app in the world. To do that, the important thing is not avoiding mistakes; it’s continually finding them, fixing them and learning from them.

So if we hadn’t released this app ‘too soon’, how would we know what to do next?

Five Star

Just to finish off, indulge me the opportunity to say a big thank you to the small team of hugely talented engineers, designers, testers and all the others involved in building this app. Everyone works exceptionally hard and deserves to feel incredibly proud of what we’ve built &³¾»å²¹²õ³ó; and what we’re going to build in the next update, and the next one, and the one after that. It’s a privilege to work with such a talented group of folks.

“Brilliant”. “Incredible”. “Cleverly designed and intuitive”. “More modern and usable than the app it’s replacing”. “Everything is so accessible”. “Sleek and simple”. “Top work from the Ö÷²¥´óÐã”.

Those are just some of the things users have been saying in reviews of the new Ö÷²¥´óÐã Sounds mobile app.

We designed Ö÷²¥´óÐã Sounds as a completely new web application. It’s built upon experience from developing and maintaining iPlayer Radio and Ö÷²¥´óÐã Music. It allowed us to re-evaluate architecture and take advantage of new web technologies.

Technology

Cloud infrastructure and performance

The web version of Ö÷²¥´óÐã Sounds was released to the existing iPlayer Radio audience as well as absorbing traffic from other parts of the Ö÷²¥´óÐã web estate. It is a cloud hosted application built to scale to handle a large number of requests, with the business logic encapsulated into the API layer and shared amongst clients.

As our applications migrate into the cloud from on premise infrastructure our engineering teams assume DevOps responsibilities. We often use for load testing, along with mock servers that provide upstream responses for specific scenarios. For Ö÷²¥´óÐã Sounds we developed new metrics and defined actionable alerting. This improved application availability making it more resilient and scalable than ever before.

To find out how Ö÷²¥´óÐã serves its web pages to the public, check out the post “”.

New stack

Building a new product provides an opportunity to start using new technology. Ö÷²¥´óÐã Sounds has been built using and with server-side rendering.

“Ö÷²¥´óÐã Sounds was built from the ground up, using Node.js, React, Redux and Express. The migration to Node.js wasn’t completely alien to us, as by 2017 we were already using it for client-side pipeline, such as Gulp, Sass, minifying and linting tasks. What was new was transitioning to server JavaScript using Express as web framework for Node.js. We chose it for its simplicity and minimal footprint, allowing us to get application setup quickly, but also providing engineers with freedom to define development style.”
— Jason Williams, Principal Software Engineer, Ö÷²¥´óÐã Sounds

We began by thinking about the UI components, and how they would be laid out. Our existing Radio network home pages (Radio 1, Radio 2 etc) were also built from UI components, but they were completely independent packages separately fetched to build the page. The problem with this approach was that modifying the components in the browser remained difficult, as they were composed server-side (using templates). We needed to change our approach.

Building Components with Atomic Design

By using React to build components we can render sections of the page server-side and then continue to modify them in the browser without duplication of code. Some of these components need to be reusable, so we needed a versatile, but consistent approach.

We used to break components up into distinct levels: atoms, molecules and organisms.

Here is an example using Radio 1’s Listen Live roundel on the homepage:

The process starts with the design of a component from our UX team. As you can see, they want to show the user what’s playing live on our radio networks.

We start to break this down by identifying the smallest discrete units of the design e.g. the ProgressBar, the live Label, a ResponsiveImage etc. These are atoms which we can compose to represent a single network, lets call it a NetworkItem molecule. Finally we can represent our networks in a scrollable list &³¾»å²¹²õ³ó; a Carousel organism.

Each component we then build and test separately, with API simplicity and reusability in mind. All that’s left is to hydrate the components with the data from our API and voila, it renders! The more reusable components we build, the faster we can test different configurations with users, and deliver new sections of Sounds.

Rendering on the server and isomorphism

We run server-side JavaScript alongside a JavaScript front-end framework. It helps to avoid having disparate languages for rendering and interacting with the UI. The application renders the full markup of its initial state in the server context. Then, we deliver both the state and a copy of the transpiled application, to pick up where we left off client-side.

When a user visits a page in Sounds, the application responds with the static HTML for the page requested . Users don’t have to wait for JavaScript to load. Then, as the React app mounts atop the existing HTML, components become more interactive; buttons appear on items to fetch more episodes from a podcast, or allowing users to subscribe.

"The benefits of this approach are multiple: ready-to-render initial responses are great for SEO and accessibility where good network connectivity and JavaScript is not always a given. But for engineers it’s also powerful to remove the context switch between client/server languages and tools, to code one language everywhere."
— Stephen Roberts, Senior Software Engineer, Ö÷²¥´óÐã Sounds

React

Choosing a front-end framework from the plethora offered up by the JavaScript ecosystem is no small feat for a new product. Our decision to use React was ultimately guided by some core features we knew Sounds would need to be future-proof and flexible to changing requirements, but also scale horizontally with our development capability.

React is among the frameworks which implement a virtual DOM (VDOM). The VDOM is a layer of abstraction which represents the UI in memory and employs a “” to apply updates to the DOM efficiently given a change in application state. This frees us up from writing boilerplate, data-binding / DOM manipulation code, to build the audience-facing components which make Ö÷²¥´óÐã Sounds.

React is a mature, open-source framework from Facebook, with a large community of developers and learning resources. Many large-scale applications run on React in production externally to the Ö÷²¥´óÐã, but also internally &³¾»å²¹²õ³ó; product teams have been reaping the benefits of using React and React-like frameworks. Choosing React therefore, leaves the door open for inter-product code and component sharing.

Redux

Delivering richer experiences around our content on the web translates to added complexity in frontend logic &³¾»å²¹²õ³ó; so it becomes increasingly important for engineers to be able to: reason about the internal state of our JS, communicate state changes to UI components efficiently, and debug when things go wrong.

In Sounds, we use as a predictable state container to provide our React app with a central, read-only store for its state. The state store can only be updated via a set of pure functions called reducers. These functions take the current app state plus a plain JavaScript object describing a state-change (an action), and update the store accordingly. React-redux then connects the data from the store to React components, creating an easy to understand pattern for unidirectional data flow.

In this way, application state is always predictable; any sequence of actions can be replayed on state with the same result. And, since the reducer functions that handle the changes are pure, they’re very straightforward to test.

Just as we changed the way we build applications, we also changed the way engineering team works and adopted new practices.

Engineering team practices

Each software engineering team comprises of a project manager, product team (e.g. product owner, business analyst), embedded UX designers and QA testers, team lead and software engineers, with streamlined processes and agile methodology in place, similar to other Ö÷²¥´óÐã teams.

We use a variety of tools to speed up our development process and facilitate communication, e.g. GitHub, custom Slack integrations etc. There’re also various practices that engineering team has been following &³¾»å²¹²õ³ó; some of them are listed below.

Cross-discipline collaboration

Developers often pair with UX designers, especially for branding related tasks and fine-tuning interactive experiences. Developing the component library has also been a joint effort from both engineering and UX teams to ensure consistency for users.

Running regular sessions with engineers working on the service layer and collaborating with other client teams ensures consistency in requirements and reduces complexity for the clients. You can read more about .

Open source and inner source

It has been an ongoing aspiration within the Ö÷²¥´óÐã to open source more as well as use inner source tools and libraries.

Here are examples of open-source Ö÷²¥´óÐã libraries that have been used for Sounds development on the web:

•  &³¾»å²¹²õ³ó; Ö÷²¥´óÐã Accessibility Guidelines Checker
•  &³¾»å²¹²õ³ó;  middleware that sets Server Timing API headers and optionally sends timers to stats systems.
•  &³¾»å²¹²õ³ó; collection of common CSS abstractions and utility helper classes
•  &³¾»å²¹²õ³ó; automatically generates an RPM Spec file for a Node.js project

Architecture decision records (ADRs)

Following API-led product development, clients of the API contribute to architecture decisions. Depending on context and complexity, these decisions could be discussed in the form of pull requests, white-boarding sessions, and stubs.

Architecture design decisions are short documents which enable our teams to have a current understanding of the context and decisions the team is making. As decision is made, it gets documented as an ADR () and added to version control with the code.

“The hope is these can act as a unit of knowledge being passed across team boundaries to allow us, much like a distributed system made of people, to achieve an eventually consistent base of knowledge of our technical estate. They also form an historical record for a team, to help them bring people up to speed and remind themselves of their own technical foundations.”
— Paul Caporn, Lead Technical Architect Ö÷²¥´óÐã TV&Radio

OKR methodology

In Sounds each team is responsible for setting its own Objectives and Key Results &³¾»å²¹²õ³ó; a methodology which is described in detail in the book “Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs” by J. Doerr. OKRs are meant to set strategy and goals over a specified amount of time for teams and individuals. At the end of that time period, OKRs provide a reference to evaluate whether these objectives have been met.

A/B testing

While developing Sounds we started extensively using A/B testing tools and success measures to ensure that the changes we’re making are the right ones for our audience. Every visit of an audience member is an opportunity to improve the product. Our experimentation toolkit allows teams to quickly test variations against an existing experience to determine what the optimal approach is in terms of a set of metrics. You can find out more about experimentation in the Ö÷²¥´óÐã in this blog post on optimising iPlayer experience.

10% time

Sounds have been making use of 10% time initiative that enabled developers to research and implement innovative solutions. Typical sprints in Sounds teams lasts two weeks, which means that one day per sprint is dedicated to 10% initiatives. This ensures 10% doesn’t skew delivery estimates for project managers, allowing flat distribution of allocated time per sprint. 10% time has been highly beneficial for engineers, giving space to grow, learn and think outside the box.

What’s next?

In 2019 we’re looking to personalise Ö÷²¥´óÐã Sounds even more, and follow our data-driven approach to implement meaningful improvements. By knowing our audience we aim to deliver a better experience of sounds, innovate on content, challenge our users, and provide an equal opportunity to access the best content for everyone.

If you are interested in working on projects like Ö÷²¥´óÐã Sounds, solving exciting, complex and large scale problems, why not come and join us?

For the past 3 years, the Radio and Music Services (RMS) team has been making APIs for iPlayer Radio, Ö÷²¥´óÐã Music and podcasts in the Radio and Music metadata space. We are an Agile Software Development team made up of 8 Software Engineers, 3 testers, a Product Owner, Project Manager and Business Analyst. Our vision is:

“We encapsulate business logic for Radio & Music products on all platforms. We add value by providing the right blend of metadata, reliably and fast“

In 2017 the Radio and Music department were tasked with building a new personalised audio product built using an API first approach. I’m going to talk about what that means to us and how we went about building Sounds in the API.

In the past typically we have made API endpoints designed for specific features our clients would request from us, they would write or modify existing client code to integrate with this and then deliver the feature. Clients would still integrate with various Ö÷²¥´óÐã APIs to build products but the benefits of having a platform independent API to provide a single integration point to these services were obvious. We decided for Sounds to go one step further and define the layout and content of the product in an API.

The stack

We love Scala (after we overcame the learning curve) and our APIs are built using predominantly and . We’ve found these tools provide excellent performance on modern cloud server architecture, and are scalable, resilient and a fantastic fit for the kind of concurrent retrieval of data we need from various Ö÷²¥´óÐã systems and databases.

Programme metadata is our bread and butter, and customising that to each users’ needs is at the core of Sounds. We have, at the time of writing, roughly 350,000 pieces of available audio we want users to be able to access. We think you should be able to serve up some of the oldest content, Britain declares war on Germany just the same as the latest Breakfast show with Greg James.

We follow the made by the super smart people at as much as we can.

Do one thing and do it well.

We’ve tried to stick to this principle to give us the flexibility to deploy and scale services individually.

The internal architecture at the Ö÷²¥´óÐã means that we typically get personalised information to hydrate programmes with from various sources:

• User Activity Service for play history, Bookmarks and Subscribing to Programmes
• Recommendations API for programmes recommended to a user from their listening history
• Ö÷²¥´óÐã Account for authentication to the Ö÷²¥´óÐã cross product Identification system

We use the for returning most of this content. The Personalised Programmes and Recommendations services are examples of this. We pass a users authentication token to an external service and get a list of programme identifiers back, then verify that those programmes are available and return a list of programmes back upstream.

A piece of work undertaken by a combination of Engineering, UX, Product and Project teams across RMS and client teams was to simplify the domain objects returned by the API. We hedged our bets that we would mostly be returning a combination of lists of programme content or single entities. We whittled it down to 4 main types:

1) Playable
The core of the product and an object you will see everywhere. In a nutshell, something you can play. It can be an episode, clip or live stream but clients don’t need to know that

2) Display
A piece of content, image, link, text or placeholder

3) Container
A container of other programme objects. Typically this can be a programme brand or series, a category, radio network or editorially curated collection of programmes

4) Broadcast
Programmes with specific dates and times that are linked to Playable (on demands or live streams) or Display items (typically things that aren’t available yet)

Each one of these object types was refined to return all necessary information but ONLY what was agreed with all teams. Making them as small as possible meant we optimised the size of content, efficiency and consistency of our responses.

We thought another good bet would be to define the experience of the product in the API and maintain a consistency across platforms. This also means there is one place to change layout, messaging and internationalisation. Clients are then free to apply their expertise in rendering that view in the best possible way for their platform. We began investigating returning all content required to load all the metadata content page in one request, benefitting mobile clients in particular. The continuing improvement of our services gave us more confidence in their performance and response times, that we could manage this all inside the Experience API and deliver all content apart from the platform specific layout on each. We started to develop this and found that not only could we improve page load times and latency, but client device and server performance, simplifying client code. This works particularly well for Search results, the Sounds homepage (Discover), Containers (Brand, Series and Collections) and My Sounds in the app.

It’s been an enjoyable (but busy) year, with lots of interesting challenges and fun problems to solve. The team are really proud of their work and hope our users will get the benefit from it whether they’re enjoying Sounds through the mobile apps (, i) or the web.

In 2019 we’re looking to personalise Ö÷²¥´óÐã Sounds even more through audience segmentation and releasing new features through multivariate testing, providing true cross platform Multivariate tests and measurement capabilities to our clients. We’re also looking at content discovery feeds such as popularity allowing the audience to find more of the audio content they love and improving the ‘continuous play’ experience. We’ll let you know how we get on.

If you are interested in working on projects like Ö÷²¥´óÐã Sounds or a wider variety of exciting, complex and large scale problems, come and join us: Latest jobs in .

The theme so far this month in the world of Ö÷²¥´óÐã technology has been Sound, with a showcase event last week at the New Broadcasting House Radio Theatre.  Sounds Amazing was a joint production by  and bringing together lots of ideas and demonstrations from the world of audio.  Much of it has been written up elsewhere, so here's a brief round-up of some of those highlights and other news.

• We learnt more about how spatial audio works and . And as the summer approaches, soon it will be
• There was a demonstration from the Blue Planet 2 sound production team about the scale of sound editing.  Each episode has around 170 sound tracks and takes roughly 15 days to edit and mix.  There's  
• We heard about Ö÷²¥´óÐã Radio's ambitions around podcasting, following .  It's now estimated that 10% of the population are listening to podcasts
• , spoke about some of their recent commissions including the 360 video documentary   More  on how it was made.   
• For VR fans, there's also a new immersive tour of the old Alexandra Palace studios, which takes you back to the early days of television
• And finally, a sound treat.  My colleagues in Archive Development have just released   While still Ö÷²¥´óÐã copyright, they've available for personal, education or research purposes. 

Why are some podcasts quiet?

Audio can take a number of routes to get online. Some routes may have audio processing applied and other routes may not. This means a live stream from Radio 1 with audio processing applied may be much louder than a podcast from Radio 4 which comes to us direct from the studio.

While the live stream from Radio 1 might be loud enough for the train, there is a good chance the quiet sections of the Radio 4 podcast will be harder to discern in the same environment. As portable music players have limits to how loud they can go, it might not be possible for a listener to turn the volume up enough in those conditions. Also, as increased personalisation allows us to offer listeners programmes on subjects of interest to them from different networks, for example jazz programmes from Radio Scotland and Radio 3, those differences in loudness between programmes could force listeners to reach for the volume control more often than they want to.

Loudness versus levels

One fairly recent change in audio processing has been the introduction of loudness based measurement. Loudness measurement takes account of the human ear’s increased sensitivity to certain frequencies and introduces a weighting to allow for this (K weighting). For a better understanding, please see this previous .

For a good technical explanation of the different level and loudness measurement scales, please see this . 

When we process audio for loudness, there are three main values that we consider:

1. The overall loudness of the entire programme or clip. This is called the “Integrated Loudness” and is measured in LUFS (Loudness units, full scale). Hence the “All you need is LUFS” badges worn by audio engineers.

2. The “Loudness range (LRA)” (measured in Loudness units, LU). The bigger the value, the greater the dynamic range available between the quietest and loudest moments.

3. The loudest peaks of the programme need to be controlled. Peak values are measured in dBTP (decibels, True Peak) and need to be below 0 dBTP to prevent a type of audible distortion known as clipping.

 

The current broadcast standards for loudness are based around the ITU-1770 measurement recommendation, and the EBU R-128 recommendation which specifies a target integrated loudness of -23LUFS. This value works really well in the home and is the standard for our HD television transmission, but when a programme recorded to an integrated loudness value of -23 LUFS is played in a noisy environment on portable equipment with its legal volume limits, it can sound very quiet compared to commercial music, and at worst it can become inaudible against the background conditions.

The Ö÷²¥´óÐã has been contributing to a new loudness recommendation aimed at online streaming, which takes account of the need to compensate for these factors. This was published as AES (Audio Engineering Society) . 

Bearing these recommendations in mind, we have decided to normalise our podcasts and audio clips to the following values.

• Integrated Loudness: -18 LUFS
• Loudness Range: 13 LU
• Maximum true peak level: -2dBTP

These values are a bit of a compromise. If we were just processing speech, we might go for a greater reduction in the loudness range, just pop music, we might look for higher integrated loudness values. As we will be dealing with everything from drama and classical music to electronic dance music, we chose values that would improve audibility while not impacting too heavily on the programme makers' original intent, allowing room for dynamics and not trimming too many peaks. We are trying to remain as transparent as possible to the listener.

If this work proves successful for podcasts we may apply it to all radio programming. If we do that, we will be able to use a range of target values so that we can tailor processing to the network’s content as we do for broadcast, while keeping our output within a manageable range of values.

Hopefully, in the future we will be able to add loudness metadata to our streams so that players can use the values to provide their own compensation, possibly taking into account the ambient noise levels through the built in microphone on mobile phones for example.

This is a first iteration of loudness processing and we’ve thought about the target values carefully, bearing in mind the amazingly wide range of content Ö÷²¥´óÐã radio produces and also what others are doing, not least the range of different values being proposed by the makers of voice activated speakers! We look forward to your feedback on the changes so that we can make adjustments if necessary to keep improving the listening experience.

The Ö÷²¥´óÐã iPlayer Radio website and Ö÷²¥´óÐã iPlayer Radio mobile app provide access to almost 60 separate stations, most of which broadcast new programmes 24 hours a day, seven days a week. As well as all that live programming there’s also a wealth of on demand programmes and clips available for you to catch up on. We recently checked how many on demand programmes were available and counted almost 150,000; a number that is set to continue rising.

This wealth of programming brings with it a challenge that isn’t unique to Ö÷²¥´óÐã Radio: how can you discover the things you love in amongst all those items? If you’ve got an idea of what you want then we have ways of helping you find it such as our search tool, the broadcast schedules for our stations or particular categories like ‘comedy’ or ‘drama’. But if you don’t really know what you’re after then it can be hard to know where to start.

Earlier this year we released new versions of all our station homepages to see if we could help with this issue. Our aim was to make the homepages do a better job of showing you our pick of the best of Ö÷²¥´óÐã Radio. Since we launched the new homepages, the proportion of people visiting those pages who click something on them has almost doubled, which is a significant improvement.

However the problem remains that when we pick out the best of Ö÷²¥´óÐã Radio we’re not taking account of your own personal listening preferences. This calls for a different approach, which we’re calling My Radio. It works by keeping track of the Ö÷²¥´óÐã Radio programmes you listen to online in order to help you keep up with the programmes that you love and introduce you to new programmes we think you’ll enjoy. We’re starting out with a relatively simple version, which includes some features we already have and some new ones. We’ll measure how well these features are doing and refine them, as well as introducing new ones to help you get the most out of Ö÷²¥´óÐã Radio online. The home for these features can be found here. In order for these to work you must be signed in to your Ö÷²¥´óÐã account.

Existing features which form part of My Radio include 'Listen Later' (previously called ‘Listen List’ and only available on the website) which gives you the ability to save things for later and ‘Following’ which allows you to see the latest available programme from your favourite shows. We’re introducing ‘Listen Later’ for the first time to the iPlayer Radio mobile app. You’ll be able to access these features on any device where you’re signed in to your Ö÷²¥´óÐã account.

We’ve also listened to your suggestions and have built a number of ways for you to sort your 'Listen Later’ and ‘Following’ lists. These include by alphabetical order, by when you added items to the lists, by how new the items are and by how soon they’re going to become unavailable.

On the iPlayer Radio website we’re introducing personalised radio recommendations for the first time. When you’re signed in to your Ö÷²¥´óÐã account we can keep track of the programmes you listen to unless you ask to opt out. Information about those programmes, such as their genre or what other programmes were listened to most often by people who listened to your programmes, is then used to work out what other programmes you might like.

These recommendations are unique to you since they take account of your personal listening preferences; someone else will get a different set of recommendations. What’s more, the more programmes you listen to online, the better our recommendations should get. We’re planning to introduce this in the Ö÷²¥´óÐã iPlayer Radio mobile app soon as well.

We think these changes will help you to better find your way through all our amazing Ö÷²¥´óÐã Radio content and discover programmes that you might not otherwise have come across. We’d like to hear how you find the journey.

One of the things we know is that people trust the Ö÷²¥´óÐã to pick out the best bits of our output for them, including new and established musicians and writers from all over the world. A key place we do this is on the radio station homepages. However, we also know that a lot of people who visit radio station homepages haven’t clicked on the bits that we’ve picked out. Part of this is to do with people often visiting radio homepages just to listen to live radio. However, we did some tests and found out that if we did a better job of showing some of the extra content we’d picked out we could double the number of people clicking on it.

So last summer we changed this and took the homepage sections with the extra content that were a bit hidden behind tabs and stacked them vertically on the page. As predicted by our research, this doubled the number of people clicking on that content.

Using Radio 2’s homepage as an example, it went from looking like this:

To looking like this:

We then asked ourselves what else we could do to make the network homepages even better at showing people all the great content we have for them. We came up with two things: the first was to design the sections of the homepage so that it’s a lot clearer what’s in them. If you’ve been watching closely you may have noticed that many of the homepage sections have already been changed to the new design. The second was to compress the top section where people click to listen live so that there’s more space to see the other things on offer.

The top section now includes a schedule which can be scrolled back to listen to a programme from earlier in the day or scrolled forward to see what is coming up. We tested this with some users and it went down well. All our radio stations have the same basic layout but our teams can now easily prioritise which sets of content they highlight on the page and in what order.

Again, looking at Radio 2, the top section has gone from looking like this:

To looking like this:

This new layout makes our pages more effective across the range of screen sizes and devices that people use.

The most significant changes are to the Radio 1 and 1Xtra homepages. They’ve been different from all the other radio stations since we launched their current homepages in late 2011. Those designs have served Radio 1 and 1Xtra well but after five years we have now found a better way to help users find all the amazing programmes, clips and videos that those two stations create.

Taking 1Xtra as the example, it will go from its current look:

To this new look:

We’re releasing this work in two parts. Firstly we changed the top section today on all radio stations apart from Radio 1 and 1Xtra. Once we’re happy that it’s worked well we’ll change the Radio 1 and 1Xtra homepages to their brand new layout.

As ever, we’d like to hear your feedback.

The story so far

Audio Factory has enabled a lot of new features for listeners in February 2015. On-demand programmes for nations and local radio became available on android mobile for the first time. We expanded the number of sports webcasts available simultaneously from eighteen to twenty four, all available in high quality and also on mobile for the first time. It is now possible to rewind our live streams on the desktop and we are exploring opportunities to surface this feature in other iPlayer Radio clients and some internet radios. We introduced downloads on the Ö÷²¥´óÐã iPlayer Radio app in time for The Proms and there were more than one million high quality downloads in the first month. All the Proms were available to download at 320kb/s in HD sound. We will soon make lower bit rates available for download for those who wish to use less disk space on their devices.

We are continuing to upgrade audio delivery where possible, to improve the quality of our streams. For national networks we have removed the 15kHz filter on the satellite distribution network that feeds some services to Audio Factory, so that listeners to our 320kb/s streams get more benefit of the higher bit rate. We are continuing to improve the contribution audio of local radio with twelve stations now available in high quality stereo and the rest following in the next couple of months.

We have added World Service streams to Audio Factory so that their listeners will be able to benefit from the same schedule pages and platform support that domestic listeners experience. We also enabled the three pop-up stations in 2015: Radio 2 Country, Radio 2 Eurovision, and Ö÷²¥´óÐã Jazz. These stations had all the same features you would expect from any other Ö÷²¥´óÐã station. Bit rates up to 320kb/s, and all programmes available to stream on-demand and some to download in the iPlayer Radio app.

SHOUTcast update

It's fair to say that while the vast majority of our listeners experience an improved service, there was some controversy at the launch of Audio Factory over the on-demand and their replacement with HLS delivered audio, and with the change of SHOUTcast from AAC streams to mp3 streams. I'd like to update you on what was done to assuage some of the issues that listeners faced.

Based on your feedback, UK only SHOUTcast streams were re-introduced for our sport focussed networks in time for the FA Cup final in May. This covered Radio Five Live, Radio Five Live Sports Extra and Radio Four Long Wave. This was done in such a way that most well behaved devices didn't have to use a new link and were just re-directed to the correct stream automatically.

Radio 3's "HD sound" SHOUTcast feed was also re-introduced after a short hiatus. This has now been moved to new hardware so that it can continue for longer. SHOUTcast for Radio 3 HD is not considered to be a delivery method in the long term, but we will work with Radio 3 before we make any decision to switch it off.

Working alongside manufacturers

We have had a lot of contact with the internet radio manufacturer community over the months since Audio Factory launched. Many are keen to move to our new streams and incorporate them in to new products. Companies with devices that now support our HLS streams include Naim, Linn, the full Sonos range - both new and pre-existing devices, and the Sonata Plus from Wireless for the Blind.

Our DASH delivery method has now been launched and various companies have expressed an interest. Some manufacturers are testing with our streams now and will have support soon. MPEG-DASH will also be used in Ö÷²¥´óÐã players to improve the quality of playback. It will also be our route of dissemination for innovation in the future such as surround and lossless audio delivery. The first example of this was the quadrophonic version of Stockhausen's Hymnen available on Radio 3 at New Year.

Our existing SHOUTcast streams continue to be hard work for us. While the experience for the listener has slowly improved, it is still having a big cost in support for us. We are continuing to look at ways of making it better while also making it less onerous to support. Our distribution partners have worked hard to make sure that the format is supportable for the next few years but there are no plans to expand or improve on it in the future.

Going forward

So what are our plans for the near future beyond those I have already alluded to? On top of improving SHOUTcast, and making sure our new features are available on all platforms, we will see the release of our work to enable adaptive bit rate switching on all platforms. This has already started for on-demand audio on the desktop. This means that a capable player will be able to provide the highest quality at any given time and adapt to the network conditions it faces. This development will also see the demise of RTMP as a delivery method for on-demand radio in Ö÷²¥´óÐã products. This has never been sanctioned for use in anything other than Ö÷²¥´óÐã products so if you're using it for your own stuff you shouldn't be and please consider this fair warning that it will be stopping soon without any further notice.

We have been working with the (AES) in drawing up a standard for loudness in online streaming. We find that the headphone level protections in mobile devices which are designed to cope with the consumption of commercial music, don't always sit well with the lower loudness targets that broadcast production often work to. The net result is that some programmes and podcasts can can be too quiet to hear in noisy environments when listening on mobile players. The seeks to address that. We will look to apply the new recommendations across all our online streams so that our radio output is consistent and when you are listening to programmes online from across the Ö÷²¥´óÐã you won't need to adjust the volume level on your player as much.

Another area we are focussing on, as I mentioned in other blogs, is the accuracy of start and end times of on-demands. Here we are working on improving the creation of our on-demand programmes so that they start and end much closer to the actual start and end times as they were broadcast, making it a better experience for our listeners. Hopefully listeners will begin to notice the difference this year.

We worked very hard in 2015 to try and provide the best possible online experience for our listeners, learning from and dealing with our issues where possible, and introducing new features that the audience requested as we went along. We hope to continue building on this foundation and improving the experience for our audience in 2016.

About downloads

The ability to download full Ö÷²¥´óÐã radio programmes to listen offline has been one of the most requested features from our users and comes as a result of a major piece of work to replace all of our radio streaming technology.

For a while users have been able to download podcasts in the app, but this update means you can now listen to full Ö÷²¥´óÐã radio programmes anywhere, even when out of range of a Wi-Fi or 3G/4G signal. And, for those of you about to head off abroad on your holidays, you can download them before you go here in the UK and then listen to them there too.

Most Ö÷²¥´óÐã radio programmes are available to listen again for 30 days after they're broadcast. You'll have until the end of the same 30-day period to listen to your downloads and after that time, the app will automatically remove them.

Some programmes are available for a shorter period or not available to download at all - this is because we have different rights agreements with different programmes.

About our new user experience

In parallel with developing our new download feature, we worked with our audiences team here at the Ö÷²¥´óÐã to form user testing groups to make our apps even better across tablets and mobiles.

Details around the new user experience and the design choices made will form the basis of a forthcoming blog article by our Creative Director.

How do I get the update to enable me to download programmes?

If you have the Ö÷²¥´óÐã iPlayer Radio app already installed on your phone, the upgrade should take place automatically.

Alternatively, if you do not have the app at all at the moment, you can download and install the app from ,  and the .

If you are using the dedicated Ö÷²¥´óÐã iPlayer Radio for iPad/Tablet app, this will soon be discontinued and you will be required to install the new unified app.

Don't worry, if you have favourited programmes. All of your favourited programmes are behind your Ö÷²¥´óÐã iD account; you simply have to log in on the new app for your favourites to appear.

Why can't I update?

Firstly, the new version the Ö÷²¥´óÐã iPlayer Radio app supports iOS 7.1 and above. Unfortunately, it is not possible to upgrade or install the new app if your device is on a version less than iOS 7.1.

If your device is running iOS 6, you can continue to use the previous version of the app, and while you won't be able to download full Ö÷²¥´óÐã radio programmes, you will still have access to many of the great features available to that version including the ability to download podcasts.

Secondly, like the previous version of the app, the new version is available for devices based on Android Ice Cream Sandwich (4.0) and above.

However, the ability to download full programmes is only available to those devices running Android Jelly Bean (4.1) and above. This in turn also affects certain Kindle Fire tablets and as such, downloading programmes is only supported by Kindle Fire HD 3rd generation and above and Kindle Fire HDXs.

For devices based on Ice Cream Sandwich (4.0) including Kindle Fire HD 2nd generation tablets, you will still be able to download podcasts for offline listening.

These platform decisions are in line with the Ö÷²¥´óÐã iPlayer app and you can read more about this .

What's next?

We are, at this very minute, working on an update to the app that will add an improved and refreshed look to the alarm (and widget for Android). This should be with you soon. 

Given our experience with how the Ö÷²¥´óÐã iPlayer Radio app for iPad and Tablet has evolved over the last 6 months, our intention is to maintain a similar approach and to keep the new version of the Ö÷²¥´óÐã iPlayer Radio app fresh and constantly evolving, and with your invaluable comments we will be introducing new features and improvements with regular updates.

If there is a feature that you would like to see in the Ö÷²¥´óÐã iPlayer Radio app, please do get in touch with us.

We can't guarantee an individual response, but we will read all your comments and use them to make improvements when applicable.

In the meantime, we hope you enjoy the latest version of the Ö÷²¥´óÐã iPlayer Radio app and your feedback is essential to make the app even better.