Playing audio with .NET MAUI

Many apps, whether mobile or desktop, require the ability to play audio. That audio may be remote, stored in the app bundle, or be chosen from the user’s device. However, .NET MAUI currently doesn’t have a cross-platform control capable of playing audio. However, all of the underlying platforms that .NET MAUI supports have native controls for playing audio. Android has MediaPlayer, iOS/Mac Catalyst has AVPlayer, and WinUI has MediaPlayerElement (only available in WinAppSDK 1.2-preview).

I’ve used these native types to create a cross-platform Audio control. It’s based on the Video control I created a month or two ago (see Playing video with .NET MAUI and Playing video with .NET MAUI on Windows). It plays audio from URLs, from audio embedded in your app package (and hence embedded in your single project), and files chosen by the user on your device. As well as using the in-built transport controls to control audio playback, you can provide your own transport controls.

Are there code sharing opportunities between my Audio and Video controls? Yes. The code to play audio on iOS/Mac/Windows is 99% identical to the code to play video on iOS/Mac/Windows. Similarly, the cross-platform Audio control is a renamed version of the cross-platform Video control. The big difference is audio and video playback on Android. The Video control uses an Android VideoView, combined with a MediaController, while the Audio control uses an Android MediaPlayer, combined with a MediaController. It’ll be possible to merge the two controls into a single Media cross-platform control, capable of playing video and audio. Will I be doing this? Maybe at some point. Just not now.

You can download the control from its GitHub repo.

An alternative approach to playing audio in a .NET MAUI app is to use Plugin.Maui.Audio, created by Gerald Versluis and Shaun Lawrence. Are there any code similarities between Plugin.Maui.Audio and what I’ve done? Not really. Plugin.Maui.Audio uses different types to play audio on iOS/Mac/Windows than I’ve used, requires you to provide your own transport controls, and doesn’t use handlers.

Handler architecture

.NET MAUI has an extension mechanism, known as handlers, that you can use to customise existing .NET MAUI controls, and write your own cross-platform views (controls) whose implementations are provided by native views (controls).

Each .NET MAUI cross-platform control is known as a virtual view. Handlers map these virtual views to native views on each platform, and are responsible for creating the underlying native view, and mapping their API to the cross-platform control. Each handler typically provides a property mapper, and potentially a command mapper, that maps the cross-platform view API to the native view API.

The following diagram shows the handler architecture for the Audio view:

The Audio type represents the cross-platform control. On iOS/Mac Catalyst the AudioHandler maps the Audio view to an iOS/Mac Catalyst AVPlayer. On Android, the Audio view is mapped to a MediaPlayer, and on WinUI the Audio view is mapped to a MediaPlayerElement.

The PropertyMapper in the AudioHandler class maps the cross-platform view properties to native view APIs via mapper methods. Each platform then provides implementations of the mapper methods, which manipulate the native view API as appropriate. The overall effect is that when a property is set on the cross-platform view, the underlying native view is updated as required.

The CommandMapper in the AudioHandler class maps cross-platform view commands to native view APIs via mapper methods. Command mappers provide a way for cross-platform controls to send commands to native views on each platform. They’re similar to property mappers, but allow for additional data to be passed. Note that commands, in this context, doesn’t mean ICommand implementations. In this context, a command is just a way of invoking some functionality on a native control. For example, the ScrollView in .NET MAUI uses a command mapper so that the ScrollView asks its handler to instruct the native views to scroll to a specific location, passing along the scroll arguments (such as the position or element it wants to scroll to). The ScrollView handler on each platform unpacks the scroll arguments and invokes native view functionality to perform the desired scroll. This was analogous in Xamarin.Forms to having an event on the cross-platform view, with the renderer subscribing to the event. The advantage of the command mapper approach is that it decouples the native view from the cross-platform view, and avoids the need to unsubscribe from events. It also allows for easy customisation - the command mapper can be modified by consumers without subclassing.

Handler implementations on each platform must override the CreatePlatformView method, and optionally the ConnectHandler and DisconnectHandler methods. The CreatePlatformView method should return the native view that implements the cross-platform view. The ConnectHandler method should perform any required native view setup, and the DisconnectHandler method should perform any required native view cleanup. Note that the DisconnectHandler override is intentionally not invoked by .NET MAUI - you have to invoke it yourself from a suitable place in your app’s lifecycle.

Code

I’m not going to provide a walkthrough of the code. But you can download it, and step through it yourself, by cloning the repo. However, I’ll give you some pointers to working through the code.

The solution is structured as follows:

The important folders in the solution are:

• Controls - the cross-platform view implementation.

  

  The Audio class derives from .NET MAUI’s View class, provides the cross-platform implementation, and is a collection of BindableProperty objects and public methods.

• Handlers - the handler implementation.

  

  The AudioHandler class is a partial class, whose platform-specific implementations are in the AudioHandler.Android.cs, AudioHandler.MaciOS.cs and AudioHandler.Windows.cs files. The AudioHandler class exposes a VirtualView property that can be used to access the cross-platform view from the handler/native view layer. It also exposes a PlatformView property that can be used to access the native view that implements the Audio view.

• Platforms - the native view implementations.

  

  Rather than implement the native views directly in the handler, I’ve split them out into native view implementations named MauiAudioPlayer. On Android, MauiAudioPlayer derives from CoordinatorLayout and uses a MediaPlayer (along with a MediaController). On Android there’s also an AudioProvider class, which is a content provider that retrieves the embedded audio files from the assets folder of its bundle. On iOS/Mac Catalyst, MauiAudioPlayer derives from UIView and uses an AVPlayer (along with an AVPlayerViewController for the transport controls). On Windows, MauiAudioPlayer derives from Grid and uses a MediaPlayerElement.

• Resources/Raw - three embedded audio files.

  

  The audio files have a build action of MauiAsset.

• Views - pages that exercise the Audio view. An event handler for the Unloaded event on each page invokes the DisconnectHandler override on AudioHandler.

A handler must be registered against its cross-platform view, and this takes place in MauiProgram.cs with the ConfigureMauiHandler/AddHandler methods.

On iOS, I modified the ContentOverlayView of the AVPlayerViewController object to display an image (the idea being you could display something that represents the audio being played - any UIView-derived object):

UIImageView imageView = new UIImageView();
imageView.Image = UIImage.FromBundle("dotnet_bot.png");
imageView.ContentMode = UIViewContentMode.ScaleAspectFit;
_playerViewController.ContentOverlayView.AddSubview(imageView);

imageView.TranslatesAutoresizingMaskIntoConstraints = false;
imageView.BottomAnchor.ConstraintEqualTo(_playerViewController.ContentOverlayView.BottomAnchor).Active = true;
imageView.TopAnchor.ConstraintEqualTo(_playerViewController.ContentOverlayView.TopAnchor).Active = true;
imageView.LeadingAnchor.ConstraintEqualTo(_playerViewController.ContentOverlayView.LeadingAnchor).Active = true;
imageView.TrailingAnchor.ConstraintEqualTo(_playerViewController.ContentOverlayView.TrailingAnchor).Active = true;

This code retrieves the dotnet_bot image that’s stored in the Resources\Raw folder of the project, from the app bundle (where it’s copied to at build time), and centers it in the ContentOverLay view of the AVPlayerViewController object using constraints. This makes the audio player look less plain:

Next steps

There are a couple of issues I’m aware of in the implementation. Firstly, the FilePicker, for selecting an audio file from the device, only works on Windows. On iOS/Android it lets you browse the device, but won’t let you select a file. On Mac Catalyst, it does nothing. At the moment I’ve yet to investigate whether these are MAUI bugs, or whether I’m doing something wrong/lacking a piece of config. Secondly, I’ve encountered a random crash on Android - I’m still trying to produce a firm repro case for it.

In addition, on Windows, the MediaPlayerElement seems to be reserving rendering space for a non-existent video. I need to look into whether there’s something I can do about that, or whether it’s due to MediaPlayerElement still being in preview.