But the underlying technology hasn't kept pace with how we actually use it. True wireless earbuds, all-day hearing aids, shared audio experiences – none of these were anticipated when the original Bluetooth audio stack was designed.

LE Audio, introduced by the Bluetooth SIG and finalized in 2022, is a ground-up redesign that replaces the Classic Bluetooth audio stack with an entirely new architecture built on Bluetooth Low Energy. It introduces a new codec (LC3), new transport primitives (isochronous channels), new profiles for unified audio streaming, and an entirely new broadcast capability called Auracast.

Together, these changes address long-standing limitations around audio quality, power consumption, multi-device streaming, and accessibility.

This handbook is a comprehensive technical deep dive into LE Audio: what it is, why it exists, how it works at every layer of the stack, and how it's implemented in Android (AOSP). We'll start with the history and motivation, build up an intuitive understanding of the core concepts, and then go deep into the architecture and code.

Here's what you'll learn:

• Why Classic Bluetooth audio hit its limits, the relay problem, the two-profile split, power constraints, and the lack of broadcast or hearing aid support

• How the LC3 codec works, and why it delivers better audio at roughly half the bitrate of SBC

• What isochronous channels are, the new transport primitive that replaces SCO and ACL for audio, in both unicast (CIS) and broadcast (BIS) forms

• How the LE Audio profile stack is organized, from foundational services like BAP and PACS up through use-case profiles like TMAP and HAP

• How multi-stream audio eliminates the earbud relay hack, with native synchronized streams to each earbud

• What Auracast enables, one-to-many broadcast audio and the infrastructure that supports it

• How all of this is implemented in Android (AOSP), a full walkthrough of the architecture from framework APIs through the native C++ stack to the Bluetooth controller, including the state machines, codec negotiation, and data flow

Whether you're a Bluetooth engineer, an embedded developer, an Android platform engineer, or just someone curious about how your devices actually work, this guide aims to make one of the most complex parts of modern wireless systems feel approachable.

If you've ever wondered why your earbuds sound great for music but terrible on calls, why one earbud always dies first, or why you can't easily share audio with people around you, read on. The answers are all here.

Table of Contents

1. Once Upon a Time in Bluetooth Land

2. The Problems With Classic Bluetooth Audio

3. Enter LE Audio: The Hero We Needed

4. The LC3 Codec: Better Sound, Less Power, More Magic

5. Isochronous Channels: The New Plumbing

6. The LE Audio Profile Stack: A Layer Cake of Specifications

7. Multi-Stream Audio: No More Left Earbud Relay

8. Auracast: Broadcast Audio for the Masses

9. LE Audio in Android/AOSP: The Implementation

10. The AOSP Architecture: From App to Antenna

11. Server-Side (Source) Implementation

12. Client-Side (Sink) Implementation

13. The State Machine That Runs It All

14. Putting It All Together: A Day in the Life of an LE Audio Packet

15. Wrapping Up

1. Once Upon a Time in Bluetooth Land

Picture this: it's 2003. Flip phones are cool. The first Bluetooth headsets hit the market, and suddenly you can walk around looking like a cyborg while taking calls.

That mono, telephone-quality audio? Powered by a little thing called HFP (Hands-Free Profile) using the CVSD codec at a whopping 64 kbps. It sounded like your caller was speaking from inside a submarine, but hey, no wires!

Fast forward a few years. We got A2DP (Advanced Audio Distribution Profile) for streaming music, bringing us SBC (Sub-Band Codec), the audio codec equivalent of a Honda Civic. Not flashy, not terrible, gets the job done. A2DP gave us stereo music streaming, and life was good.

For a while.

The Bluetooth SIG (Special Interest Group), the consortium of thousands of companies that governs Bluetooth, kept iterating on the classic Bluetooth audio stack. We got better codecs like aptX, AAC, and LDAC. But here's the thing: all of these were built on top of the same ancient plumbing. It's like renovating your kitchen while the house's foundation is slowly cracking.

The Bluetooth audio stack was built on BR/EDR (Basic Rate/Enhanced Data Rate), the "Classic Bluetooth" radio. This is the same radio technology from the early 2000s, designed when streaming audio from a phone to a single headset was the pinnacle of innovation. Nobody imagined true wireless earbuds, hearing aids that stream directly from your phone, or broadcasting audio to an entire airport terminal.

By the late 2010s, Bluetooth audio was showing its age. Badly.

2. The Problems With Classic Bluetooth Audio

Let's catalogue the issues of Classic Bluetooth Audio, because they're educational:

Issue #1: The Two-Profile Personality Disorder

Classic Bluetooth had a split personality. Want to listen to music? Use A2DP with SBC/AAC at nice quality. Want to make a phone call? Switch to HFP, which uses a completely different codec (CVSD or mSBC) at dramatically lower quality.

Ever noticed how your wireless earbuds sound amazing playing Spotify, but the moment you jump on a Zoom call, it sounds like you're talking through a paper towel tube? That's the A2DP-to-HFP switchover. Different profiles, different codecs, different audio paths. The switch isn't even graceful, there's often an audible glitch.

The above diagram shows the audio quality drop when switching from A2DP (music streaming with SBC/AAC at high quality) to HFP (voice call with CVSD/mSBC at low quality). The switch causes an audible glitch and dramatic reduction in audio fidelity.

Issue #2: The Relay Problem (True Wireless Earbuds)

When you have true wireless earbuds (left and right earbuds with no wire between them), Classic Bluetooth has a dirty little secret: A2DP can only stream to one device at a time.

So what actually happens with your fancy earbuds?

1. Your phone sends the stereo audio stream to the primary earbud (usually the right one)

2. The primary earbud receives both left and right channels

3. It then relays the other channel to the secondary earbud via a separate Bluetooth link

This relay architecture has a few important consequences. First, you have double the battery drain on the primary earbud (it dies first, you've noticed this). You also get higher latency to the secondary earbud

There are also potential synchronization issues between left and right channels. And if the primary earbud runs out of battery or loses connection, both earbuds go silent.

Issue #3: Power Hungry

BR/EDR was designed in an era when "low power" meant "runs on AA batteries." Streaming audio over Classic Bluetooth is relatively power-hungry. The radio has to maintain a constant, high-bandwidth connection. For devices like hearing aids that need to run all day on tiny batteries, this was a dealbreaker.

Issue #4: One-to-One Only

Classic Bluetooth audio is fundamentally point-to-point. One source, one sink (or at best, a very hacky "dual audio" implementation where the phone maintains two separate A2DP connections). There's no way to broadcast audio to multiple listeners simultaneously without establishing individual connections to each one.

Imagine you're at an airport gate and want to stream the boarding announcements to everyone's earbuds. With Classic Bluetooth, you'd need to pair with every single person's device individually. Good luck with that at Gate B47.

Issue #5: No Standard for Hearing Aids

Before LE Audio, there was no official Bluetooth standard for hearing aids. Apple created its own proprietary MFi (Made for iPhone) hearing aid protocol. Google created ASHA (Audio Streaming for Hearing Aid) as a semi-proprietary BLE-based solution for Android. Neither was an official Bluetooth standard, and interoperability was... let's call it "aspirational."

3. Enter LE Audio: The Hero We Needed

In January 2020, at CES, the Bluetooth SIG unveiled LE Audio, a complete reimagining of Bluetooth audio built on top of Bluetooth Low Energy (BLE) instead of Classic BR/EDR.

The core transport features (isochronous channels, EATT, LE Power Control) shipped in the Bluetooth Core Specification v5.2 in late 2019/early 2020. But the full suite of LE Audio profiles and services wasn't completed until July 12, 2022, when the Bluetooth SIG officially announced that all LE Audio specifications had been adopted.

The effort involved over 25 working groups, thousands of engineers from hundreds of companies, and took approximately 7 years from initial concept to completion. This wasn't a minor spec update. It was a ground-up redesign.

Here's what LE Audio brings to the table:

Think of it this way: Classic Bluetooth Audio is like a landline telephone system: reliable, well-understood, but fundamentally limited.

LE Audio is like the transition to VoIP and streaming: same goal (getting audio from A to B), but entirely new infrastructure that unlocks capabilities the old system could never support.

4. The LC3 Codec: Better Sound, Less Power, More Magic

At the heart of LE Audio is a new mandatory codec called LC3: Low Complexity Communication Codec. If SBC is the Honda Civic, LC3 is a Tesla Model 3. It's more efficient, more capable, and designed from the ground up for the modern era.

What Even Is a Codec?

For the uninitiated: a codec (coder-decoder) is an algorithm that compresses audio so it can be transmitted over a limited-bandwidth wireless link, and then decompresses it on the other side. The better the codec, the better the audio sounds at a given bitrate, and the less battery it eats doing the math.

LC3 Technical Specs

LC3 was developed by Fraunhofer IIS (the same folks who brought us MP3 and AAC, they know a thing or two about audio coding) and Ericsson.

Here are the key specs:

• Sample rates: 8, 16, 24, 32, 44.1, and 48 kHz

• Bit depth: 16, 24, or 32 bits

• Frame durations: 7.5 ms and 10 ms

• Bitrate range: 16 to 320 kbps per channel

• Algorithmic latency: 7.5 ms (for 7.5 ms frames) or 10 ms (for 10 ms frames)

• Channels: Mono or stereo

Why LC3 Is Better Than SBC

The big headline: LC3 delivers equivalent or better audio quality at roughly half the bitrate of SBC.

In listening tests conducted by Fraunhofer, participants rated LC3 at 160 kbps as equivalent to or better than SBC at 345 kbps. That's not a marginal improvement, it's nearly a 2x efficiency gain.

The above bar chart compares subjective audio quality ratings of LC3 and SBC at various bitrates. LC3 at 160 kbps is rated equivalent to or better than SBC at 345 kbps, demonstrating roughly 2x efficiency improvement.

This efficiency gain translates directly into one of two things (or a combination of both):

1. Better audio quality at the same power, more bits for quality, less wasted

2. Same audio quality at lower power, the device runs longer on a charge

How LC3 Actually Works (The Simplified Version)

LC3 uses a modified discrete cosine transform (MDCT), a mathematical technique that converts audio from the time domain (a waveform) to the frequency domain (which frequencies are present). This is similar to what AAC and other modern codecs do, but LC3's transform is optimized for low computational complexity.

Here's the encoding pipeline, simplified:

This is a flowchart of the LC3 encoding pipeline. PCM audio input passes through an MDCT (Modified Discrete Cosine Transform) to convert from time domain to frequency domain. Then spectral noise shaping applies a psychoacoustic model to hide quantization noise in inaudible frequency regions, followed by quantization and entropy coding to produce the compressed LC3 bitstream.

The key insight is spectral noise shaping: LC3 uses a psychoacoustic model (a model of how humans perceive sound) to ensure that the quantization noise (the artifacts introduced by compression) is shaped to fall in frequency regions where it's least audible. Your ears literally can't hear the distortion. Clever, right?

LC3 vs. LC3plus

You might also hear about LC3plus, an enhanced version that adds:

• Super-wideband and fullband modes (up to 48 kHz audio bandwidth)

• Additional frame sizes (2.5 ms, 5 ms) for ultra-low-latency applications

• Higher quality at very low bitrates

LC3plus is not part of the base LE Audio spec but is used in some implementations (like DECT NR+ for cordless phones).

5. Isochronous Channels: The New Plumbing

Here's where things get architecturally interesting. Classic Bluetooth audio used SCO (Synchronous Connection-Oriented) links for voice and L2CAP over ACL (Asynchronous Connection-Less) links for A2DP streaming. These were okay, but they're like using garden hoses for different purposes, functional but not optimized for audio.

LE Audio introduces a brand-new transport mechanism at the link layer: Isochronous Channels. These are purpose-built pipes for time-sensitive data like audio.

What "Isochronous" Means

"Isochronous" (from Greek: iso = equal, chronos = time) means "occurring at regular time intervals." An isochronous channel guarantees that data arrives at a predictable, regular cadence, exactly what you need for audio.

Think of it this way:

• Asynchronous (ACL): "Here's some data. It'll get there when it gets there." (Great for file transfers, bad for audio)

• Synchronous (SCO): "Here's data that MUST arrive on time, and if it doesn't, too bad." (Old voice links, no retransmissions)

• Isochronous: "Here's data that should arrive on time, and we'll try our best to make that happen with some smart retransmission." (Best of both worlds)

This above chart is a comparison of three Bluetooth transport types: Asynchronous (ACL) delivers data without timing guarantees, Synchronous (SCO) delivers data on a fixed schedule with no retransmission, and Isochronous delivers data on a regular schedule with smart retransmission, combining the reliability of ACL with the timing guarantees of SCO.

Two Flavors: CIS and BIS

Isochronous channels come in two flavors, and this is where the magic happens:

CIS — Connected Isochronous Stream

CIS is for point-to-point audio (unicast). It's what your phone uses to stream music to your earbuds.

The aboe is a diagram of a Connected Isochronous Stream (CIS) setup: a phone (Unicast Client) sends two synchronized CIS streams within a single CIG (Connected Isochronous Group), one to the left earbud and one to the right earbud. Arrows show bidirectional audio flow, with music going to the earbuds and microphone audio returning to the phone.

Key features of CIS:

• Bidirectional: Audio can flow in both directions simultaneously (unicast to earbuds AND microphone audio back)

• Acknowledged: The receiver sends acknowledgments, enabling retransmissions of lost packets

• Grouped into CIGs: Multiple CIS streams are grouped into a CIG (Connected Isochronous Group), ensuring they're synchronized

That last point is crucial. A CIG ensures the left and right earbud receive their audio packets with tight synchronization, no more "my left ear is 50ms ahead of my right ear" issues.

BIS — Broadcast Isochronous Stream

BIS is for one-to-many audio (broadcast). It's the foundation of Auracast.

The above is a diagram of a Broadcast Isochronous Stream (BIS) setup: a single broadcast source transmits audio via a BIG (Broadcast Isochronous Group) containing multiple BIS streams. Multiple receivers (broadcast sinks) independently receive the same audio without any connection to the source, similar to FM radio.

Key features of BIS:

• Unidirectional: One-way only (source to listeners), makes sense, you can't have a million people talking back

• Unacknowledged: No acks from listeners (the source doesn't even know who's listening)

• Grouped into BIGs: Multiple BIS streams form a BIG (Broadcast Isochronous Group)

• Scalable: No upper limit on listeners, it's actual radio broadcasting

The ISO Data Path

Under the hood, isochronous data follows a specific path through the controller:

The above is a diagram of the isochronous data path through the Bluetooth controller. Audio frames from the host pass through HCI, then through the ISO Adaptation Layer (ISO-AL) which handles segmentation, timestamping, and flush timeout management, before reaching the Link Layer for transmission over the air.

The key innovation is the ISO-AL (Isochronous Adaptation Layer), which sits between HCI and the Link Layer. It handles:

• Segmentation: Breaking audio frames into link-layer-sized pieces

• Time-stamping: Each audio frame gets a timestamp so the receiver knows exactly when to play it

• Flush timeout: If a frame can't be delivered in time, it's flushed (better to skip a frame than play it late)

6. The LE Audio Profile Stack: A Layer Cake of Specifications

If you've ever looked at the list of LE Audio specifications and felt your eyes glaze over, you're not alone. There are a LOT of them. But they're organized in a logical hierarchy, and once you understand the structure, it all makes sense.

Visual: The Profile Stack

Here's a three-tier diagram of the LE Audio profile stack:

Tier 1 (foundation) contains BAP, VCP, MCP, CCP, MICP, CSIP, and BASS. Tier 2 (grouping layer) contains CAP, which coordinates the Tier 1 profiles. Tier 3 (use-case profiles) contains TMAP for telephony and media, HAP for hearing aids, and PBP for public broadcasts. Each tier builds on the one below it.

Think of it as a wedding cake with three tiers:

Tier 1: The Foundation (Core Services and Profiles)

These are the building blocks everything else is built on:

BAP — Basic Audio Profile

The big kahuna. BAP defines the fundamental procedures for discovering, configuring, and establishing LE Audio streams. It defines two roles:

• Unicast Client: The device that initiates and controls audio streams (typically your phone)

• Unicast Server: The device that renders or captures audio (typically your earbuds)

BAP relies on several GATT services:

• PACS (Published Audio Capabilities Service): "Hey, here's what audio formats I support"

• ASCS (Audio Stream Control Service): "Let's set up and manage audio streams"

VCP — Volume Control Profile

Handles remote volume control. Your phone can control the volume on your earbuds (and vice versa) using the VCS (Volume Control Service).

MCP — Media Control Profile

Allows remote control of media playback. Pause, play, skip, and so on, through the MCS (Media Control Service). Like AVRCP for LE Audio.

CCP — Call Control Profile

Manages phone call state. Answer, reject, hold calls via the TBS (Telephone Bearer Service). This replaces HFP's call control functionality.

MICP — Microphone Control Profile

Handles remote mute/unmute of a device's microphone. Simple but essential, ever been on a call where you couldn't figure out how to mute? MICP standardizes it.

CSIP — Coordinated Set Identification Profile

This is the "these two earbuds belong together" profile. It uses the CSIS (Coordinated Set Identification Service) to tell the phone: "Hey, I'm the left earbud, and my buddy over there is the right earbud. We're a set."

Without CSIP, your phone would treat each earbud as a completely independent device. CSIP is what enables seamless "coordinated set" behavior.

BASS — Broadcast Audio Scan Service

Handles the discovery of broadcast audio sources. A device with BASS can scan for nearby broadcasts and help another device (like hearing aids) tune into them.

Tier 2: The Grouping Layer

CAP — Common Audio Profile

CAP sits on top of the Tier 1 profiles and provides common procedures that higher-level profiles use. It handles things like:

• Discovering a coordinated set of devices (using CSIP)

• Setting up unicast audio streams to a coordinated set (using BAP)

• Initiating broadcast audio streams

Think of CAP as the "orchestrator" that coordinates all the Tier 1 profiles to work together.

Tier 3: The Use-Case Profiles

These are the profiles that map to actual user scenarios:

TMAP — Telephony and Media Audio Profile

The "all-in-one" profile for typical audio use cases. TMAP defines roles like:

• Call Terminal (CT): Can make and receive calls

• Unicast Media Sender (UMS): Can send media audio (your phone)

• Unicast Media Receiver (UMR): Can receive media audio (your earbuds)

• Broadcast Media Sender (BMS): Can broadcast media audio

• Broadcast Media Receiver (BMR): Can receive broadcast media audio

If you're building a typical phone + earbuds experience, TMAP is your profile.

HAP — Hearing Access Profile

The standardized profile for hearing aids. This replaces the proprietary MFi and ASHA solutions with an official Bluetooth standard. HAP defines procedures for:

• Streaming audio to hearing aids

• Adjusting hearing aid presets

• Controlling volume on hearing aids

This is a huge deal. For the first time, hearing aids can interoperate across all Bluetooth devices using a standard protocol.

PBP — Public Broadcast Profile

Defines how to set up and discover public broadcasts (Auracast). This is what enables "broadcast audio in the airport terminal" scenarios.

7. Multi-Stream Audio: No More Left Earbud Relay

Remember the relay problem with Classic Bluetooth? LE Audio eliminates it entirely with multi-stream audio.

With LE Audio, the source device (your phone) can send independent, synchronized audio streams directly to each earbud:

This diagram compares Classic Bluetooth relay architecture (phone sends stereo to primary earbud, which relays to secondary) with LE Audio multi-stream architecture (phone sends independent synchronized streams directly to each earbud via separate CIS channels within a CIG). The LE Audio approach provides balanced battery drain and lower latency.

How It Works

1. Both earbuds connect to the phone independently via BLE

2. The phone identifies them as a coordinated set using CSIP

3. The phone establishes a CIG (Connected Isochronous Group) with two CIS streams, one per earbud

4. The phone sends the left channel on CIS #1 and the right channel on CIS #2

5. The CIG ensures both streams are synchronized, the earbuds play their respective channels at exactly the same time

Benefits:

• Balanced battery drain: Both earbuds do equal work

• Lower latency: No relay hop means fewer delays

• Better reliability: If one earbud loses connection, the other keeps playing

• True stereo: Each earbud gets its own independent stream, no need to decode and split

8. Auracast: Broadcast Audio for the Masses

Auracast is LE Audio's broadcast feature, and it's arguably the most revolutionary part. It's like FM radio for Bluetooth: one source, unlimited listeners.

How Auracast Works

1. A Broadcast Source creates a BIG (Broadcast Isochronous Group) containing one or more BIS streams

2. The source advertises the broadcast using Extended Advertising with metadata (stream name, language, codec config)

3. A Broadcast Sink discovers the advertisement, syncs to the Periodic Advertising train to get stream parameters

4. The sink joins the BIG and starts receiving audio

The above diagram shows the Auracast broadcast flow: a broadcast source advertises via Extended Advertising, broadcast sinks discover the advertisement and sync to Periodic Advertising to receive stream parameters, then join the BIG to receive audio. There is no limit on the number of sinks.

Auracast Use Cases

The use cases are actually compelling:

• Airports/Train Stations: Broadcast gate announcements directly to travelers' earbuds (in multiple languages!)

• Gyms: Every TV on the wall can broadcast its own audio, pick which one to listen to

• Museums: Audio guides streamed to visitors' own earbuds

• Bars/Sports Events: Watch the game on the big screen with commentary in your earbuds, without blasting everyone

• Conferences: Live translation channels broadcast to attendees

• Silent Discos: Obviously

The BASS Role: Broadcast Assistants

There's a neat supporting concept called a Broadcast Assistant. This is a device (typically your phone) that helps another device (typically your earbuds) discover and tune into broadcasts.

Why? Because tiny earbuds might not have the processing power or UI to scan for and select broadcasts themselves. So your phone does the scanning, shows you available broadcasts, and tells your earbuds which one to tune into via the BASS (Broadcast Audio Scan Service).

The above diagram showes the Broadcast Assistant role: a phone scans for available Auracast broadcasts and displays them to the user. When the user selects a broadcast, the phone (acting as Broadcast Assistant) instructs the user's earbuds to tune into the selected broadcast via BASS (Broadcast Audio Scan Service), since the earbuds may lack the UI or processing power to scan on their own.

9. LE Audio in Android/AOSP: The Implementation

Now let's get into the code. This is where the rubber meets the road.

Timeline of Android LE Audio Support

• Android 12 (2021): Initial LE Audio APIs introduced (developer preview quality)

• Android 13 (2022): Full LE Audio support, including unicast client/server, broadcast source/sink

• Android 14 (2023): Improved stability, broadcast audio enhancements, LE Audio source role support

• Android 15 (2024): Auracast Broadcast Sink support, Broadcast Assistant role, improved audio context switching

• Android 16 (2025): Native Auracast UI in Quick Settings/Bluetooth settings, enhanced audio sharing experience

The LE Audio implementation in AOSP lives primarily in the Bluetooth module (packages/modules/Bluetooth), which is a Mainline module, meaning it can be updated via Google Play System Updates independent of full Android OS updates.

Key AOSP Source Locations

If you want to dive into the code yourself, here's your treasure map:

High-Level Architecture

The AOSP Bluetooth stack for LE Audio follows Android's classic layered architecture:

In this layered architecture diagram of the AOSP Bluetooth LE Audio stack, here's what's shown from top to bottom: Application layer, Framework APIs (BluetoothLeAudio, BluetoothLeBroadcast), LeAudioService (Java), JNI Bridge, Native C++ stack (le_audio_client, codec_manager, state_machine, iso_manager), HCI layer, and Bluetooth Controller hardware.

10. The AOSP Architecture: From App to Antenna

Let's walk through each layer in detail.

Layer 1: The Framework APIs

Android exposes LE Audio functionality through several public API classes in android.bluetooth:

BluetoothLeAudio

The main API for unicast LE Audio. Apps use this to:

• Connect to LE Audio devices

• Set active device for audio playback/capture

• Query group information (coordinated sets)

• Select codec configuration

// Example: Connect to an LE Audio device
BluetoothLeAudio leAudio = bluetoothAdapter.getProfileProxy(
    context, listener, BluetoothProfile.LE_AUDIO);

// Set the LE Audio device as active for media playback
leAudio.setActiveDevice(leAudioDevice);

BluetoothLeBroadcast

API for broadcast audio (Auracast). Apps use this to:

• Start/stop broadcast audio

• Set broadcast metadata (name, language)

• Configure broadcast code (encryption password)

// Start a broadcast
BluetoothLeBroadcast broadcast = bluetoothAdapter.getProfileProxy(
    context, listener, BluetoothProfile.LE_AUDIO_BROADCAST);

broadcast.startBroadcast(contentMetadata, audioConfig, broadcastCode);

BluetoothLeBroadcastAssistant

API for the broadcast assistant role, helping another device tune into a broadcast.

BluetoothVolumeControl

API for remote volume control via VCP.

BluetoothHapClient

API for the Hearing Access Profile, controlling hearing aid presets and streaming.

Layer 2: LeAudioService (The Brain)

The LeAudioService is the central service within the Bluetooth app that orchestrates all LE Audio functionality. This is where the magic happens.

Key responsibilities:

• Device Management: Tracking connected LE Audio devices and their capabilities

• Group Management: Managing coordinated sets (which devices belong together)

• Audio Routing: Deciding which device(s) should be active for playback/capture

• State Machine Management: Handling the lifecycle of audio connections

• Profile Coordination: Coordinating BAP, VCP, MCP, CCP, and CSIP

Here's a simplified view of how LeAudioService is structured:

public class LeAudioService extends ProfileService {
    
    // Map of device address -> state machine
    private Map<BluetoothDevice, LeAudioStateMachine> mStateMachines;
    
    // Map of group ID -> group information
    private Map<Integer, LeAudioGroupDescriptor> mGroupDescriptors;
    
    // Native interface bridge
    private LeAudioNativeInterface mNativeInterface;
    
    // Active device tracking
    private BluetoothDevice mActiveAudioOutDevice;
    private BluetoothDevice mActiveAudioInDevice;
    
    // Codec configuration
    private BluetoothLeAudioCodecConfig mInputLocalCodecConfig;
    private BluetoothLeAudioCodecConfig mOutputLocalCodecConfig;
    
    public void connect(BluetoothDevice device) {
        // 1. Check if device supports LE Audio (PACS)
        // 2. Create state machine for device
        // 3. Initiate connection via native stack
        // 4. Discover GATT services (PACS, ASCS, VCS, etc.)
        // 5. Read audio capabilities
    }
    
    public void setActiveDevice(BluetoothDevice device) {
        // 1. Look up device's group
        // 2. Find all devices in the coordinated set
        // 3. Configure audio streams via BAP
        // 4. Set up isochronous channels
        // 5. Start audio routing
    }
}

Layer 3: The Native Stack (C++)

Below the Java layer, the heavy lifting happens in C++. The native LE Audio implementation lives in the Bluetooth stack (historically called "Fluoride," with newer components in "Gabeldorsche").

Key native components:

le_audio_client.cc / le_audio_client_impl

The main C++ implementation of the LE Audio client. This handles:

• GATT client operations (discovering services, reading characteristics)

• ASE (Audio Stream Endpoint) state machine management

• Codec negotiation with remote devices

• CIS/BIS creation and management

state_machine.cc

Manages the connection state machine for each LE Audio device:

The above is a state diagram of the native LE Audio connection state machine with states: Disconnected, Connecting, Connected, and Disconnecting. The state machine is managed per-device in the native C++ layer and drives GATT connection setup, service discovery, and characteristic reads before transitioning to Connected.

codec_manager.cc

Handles codec configuration:

• Enumerates supported codec capabilities

• Selects optimal codec configuration based on device capabilities and use case

• Interfaces with the LC3 encoder/decoder

iso_manager.cc

Manages isochronous channels:

• Creates and tears down CIG/CIS for unicast

• Creates and tears down BIG/BIS for broadcast

• Handles the HCI interface for isochronous data

audio_hal_client.cc

Bridges the Bluetooth stack with the Android audio HAL:

• Receives PCM audio from the Android audio framework

• Passes it to the LC3 encoder

• Sends encoded audio over isochronous channels

Layer 4: The Controller (Hardware)

The Bluetooth controller handles the low-level radio operations:

• Link layer scheduling of isochronous events

• PHY layer (1M, 2M, or Coded PHY)

• Packet formatting and CRC

• Retransmission of lost isochronous PDUs

The host (Android) communicates with the controller via HCI (Host Controller Interface), using specific HCI commands for isochronous channels:

• HCI_LE_Set_CIG_Parameters: Configure a Connected Isochronous Group

• HCI_LE_Create_CIS: Create Connected Isochronous Streams

• HCI_LE_Create_BIG: Create a Broadcast Isochronous Group

• HCI_LE_Setup_ISO_Data_Path: Set up the path for ISO data (HCI vs. vendor-specific)

• HCI_LE_BIG_Create_Sync: Synchronize to a BIG (for broadcast receivers)

11. Server-Side (Source) Implementation

The "server side" in LE Audio terminology is actually the Unicast Server, the device that renders audio (your earbuds). Yes, it's confusing that the receiver is called the "server." Think of it as a GATT server: it hosts the GATT services that the client connects to.

What the Unicast Server Does

The Unicast Server (earbud) hosts several GATT services:

The above diagram shows the GATT services hosted by a Unicast Server (earbud). The server exposes four key services:

• PACS (Published Audio Capabilities Service), which advertises the device's supported codecs, sample rates, frame durations, and audio contexts

• ASCS (Audio Stream Control Service), which contains one or more ASE (Audio Stream Endpoint) characteristics that the client writes to in order to configure and control audio streams

• VCS (Volume Control Service), which allows the client to read and set the device's volume level

• and CSIS (Coordinated Set Identification Service), which identifies this device as part of a coordinated set (for example, "I am the left earbud, and my partner is the right earbud").

The Unicast Client (phone) connects to these services via GATT to discover capabilities, configure streams, and control playback.

The ASE State Machine (Server Side)

Each ASE (Audio Stream Endpoint) on the server has a state machine. This is the heart of audio stream management:

The above is a state diagram of the ASE (Audio Stream Endpoint) state machine on the Unicast Server. States: Idle, Codec Configured, QoS Configured, Enabling, Streaming, Disabling, and Releasing. The client drives transitions by writing operations (Config Codec, Config QoS, Enable, Disable, Release) to the ASE Control Point characteristic.

State transitions:

1. IDLE → CODEC_CONFIGURED: The client writes a Config Codec operation to the ASE Control Point, specifying codec type (LC3), sample rate, frame duration, and so on.

2. CODEC_CONFIGURED → QoS_CONFIGURED: The client writes a Config QoS operation, specifying:

   • SDU interval (how often audio frames are sent)

   • Framing (framed or unframed)

   • Max SDU size

   • Retransmission number

   • Max transport latency

   • Presentation delay

3. QoS_CONFIGURED → ENABLING: The client writes an Enable operation. The server prepares to receive audio.

4. ENABLING → STREAMING: The CIS is established and audio data starts flowing. This transition happens after the client creates the CIS and both sides are ready.

5. STREAMING → DISABLING: The client writes a Disable operation, or the connection is being torn down.

6. Any state → IDLE: The client writes a Release operation, tearing down the stream configuration.

Standard Codec Configurations

BAP defines a set of named codec configurations that map to specific LC3 parameters. These are the "presets" that devices negotiate:

For most consumer earbuds, you'll see 48_4 (96 kbps at 48 kHz) for media and 16_2 (32 kbps at 16 kHz) for phone calls. That single LC3 codec handles both use cases – no more switching between SBC and mSBC!

Audio Context Types

LE Audio defines Audio Context Types, metadata that tells the receiving device what kind of audio is being streamed. This allows the device to optimize its behavior (for example, enabling noise cancellation for calls or boosting bass for music):

This is way more granular than Classic Audio, which basically only knew two states: "you're playing music" (A2DP) or "you're on a call" (HFP). With LE Audio, the device can make intelligent decisions, like "this is a game, use 7.5ms frames for minimum latency" or "this is a notification, mix it in without interrupting the music stream."

AOSP Unicast Server Implementation

In AOSP, the Unicast Server functionality is implemented primarily for cases where the Android device acts as a receiver (for example, an Android-powered hearing aid or a Chromebook receiving audio).

Key classes:

• LeAudioService.java: Handles server-side operations when the device is in sink role

• In native code: le_audio_server.cc manages the GATT server hosting PACS, ASCS, and so on.

Broadcast Source Implementation

For broadcast audio (Auracast), the source side in AOSP involves:

// In LeAudioService.java / BroadcastService
public void startBroadcast(BluetoothLeBroadcastSettings settings) {
    // 1. Configure LC3 encoder with broadcast parameters
    // 2. Set up Extended Advertising with broadcast metadata
    // 3. Set up Periodic Advertising for stream parameters
    // 4. Create BIG via HCI
    // 5. Start sending ISO data on BIS streams
}

The native implementation:

• broadcaster.cc / broadcaster_impl: Manages broadcast lifecycle

• Configures Extended Advertising with the broadcast name and metadata

• Configures Periodic Advertising to carry the BASE (Broadcast Audio Source Endpoint) data structure

• Creates a BIG with the appropriate number of BIS streams

• Routes encoded audio to the BIS data path

12. Client-Side (Sink) Implementation

The "client side" is the Unicast Client, typically your phone. It discovers, connects to, and controls LE Audio devices.

Connection Flow

Here's what happens when you connect to LE Audio earbuds, step by step:

Steps: BLE scan and discovery, GATT connection, service discovery (finding PACS, ASCS, CSIP, VCS), reading PAC records to learn audio capabilities, reading CSIS to identify coordinated set membership, then ASE configuration (Config Codec, Config QoS, Enable) followed by CIS creation and audio streaming.

AOSP Client Implementation in Detail

Step 1-3: Discovery and Connection

// LeAudioService.java
public void connect(BluetoothDevice device) {
    // Creates a new LeAudioStateMachine for this device
    LeAudioStateMachine sm = getOrCreateStateMachine(device);
    sm.sendMessage(LeAudioStateMachine.CONNECT);
    
    // The state machine handles:
    // - GATT connection
    // - Service discovery
    // - Characteristic reads
}

The LeAudioStateMachine manages the connection lifecycle:

// LeAudioStateMachine.java (simplified)
class LeAudioStateMachine extends StateMachine {
    
    class Disconnected extends State {
        void processMessage(Message msg) {
            if (msg.what == CONNECT) {
                // Initiate GATT connection via native
                mNativeInterface.connectLeAudio(mDevice);
                transitionTo(mConnecting);
            }
        }
    }
    
    class Connecting extends State {
        void processMessage(Message msg) {
            if (msg.what == CONNECTION_STATE_CHANGED) {
                if (newState == CONNECTED) {
                    transitionTo(mConnected);
                }
            }
        }
    }
    
    class Connected extends State {
        void enter() {
            // GATT services have been discovered
            // Audio capabilities have been read
            // Device is ready for streaming
            broadcastConnectionState(BluetoothProfile.STATE_CONNECTED);
        }
    }
}

Step 4-6: Capability Discovery

The native layer reads PACS to understand what the remote device supports:

// In native le_audio_client_impl (C++)
void OnGattServiceDiscovery(BluetoothDevice device) {
    // Read PAC records from PACS
    ReadPacsCharacteristics(device);
    
    // Read CSIS for coordinated set info
    ReadCsisCharacteristics(device);
    
    // Read ASCS for ASE count and state
    ReadAscsCharacteristics(device);
}

void OnPacsRead(BluetoothDevice device, PacRecord sink_pac) {
    // sink_pac contains:
    //   codec_id: LC3
    //   sampling_frequencies: 48000, 44100, 32000, 24000, 16000, 8000
    //   frame_durations: 10ms, 7.5ms
    //   channel_counts: 1
    //   octets_per_frame: 40-155  (maps to bitrate range)
    //   supported_contexts: MEDIA, CONVERSATIONAL, GAME
    
    // Store capabilities for later codec negotiation
    device_info.sink_capabilities = sink_pac;
}

Step 7-12: Stream Setup

When audio playback begins, the client configures and enables streams:

// In native codec_manager (C++)
CodecConfig SelectCodecConfiguration(
    PacRecord remote_capabilities,
    AudioContext context  // MEDIA, CONVERSATIONAL, etc.
) {
    // For media playback, prefer high quality:
    //   48 kHz, 10ms frames, 96 kbps per channel
    
    // For voice calls, optimize for latency:
    //   16 kHz, 7.5ms frames, 32 kbps per channel
    
    // Negotiate: intersect local and remote capabilities
    // Select the best configuration both sides support
}

// In native le_audio_client_impl
void GroupStreamStart(int group_id, AudioContext context) {
    auto group = GetGroup(group_id);
    auto codec_config = SelectCodecConfiguration(
        group->GetRemoteCapabilities(), context);
    
    // For each device in the group:
    for (auto& device : group->GetDevices()) {
        // For each ASE on the device:
        for (auto& ase : device->GetAses()) {
            // Step 8: Config Codec
            WriteAseControlPoint(device, OPCODE_CONFIG_CODEC, {
                .ase_id = ase->id,
                .codec_id = LC3,
                .codec_specific = {
                    .sampling_freq = 48000,
                    .frame_duration = 10ms,
                    .channel_allocation = LEFT,  // or RIGHT
                    .octets_per_frame = 120
                }
            });
        }
    }
    // After codec configured notification:
    //   Step 9: Config QoS → Step 10: Enable → Step 11: Create CIS
}

Step 13: Audio Data Flow

Once streaming, here's how audio data flows through the AOSP stack:

The above diagram shows audio data flow during LE Audio streaming: PCM audio from the Android audio framework reaches the Bluetooth Audio HAL, is encoded by the LC3 encoder, packetized into ISO SDUs with timestamps, sent over HCI to the controller, transmitted over the air via CIS, received by the earbud's controller, decoded by the earbud's LC3 decoder, and rendered as audio.

Broadcast Sink Implementation

For receiving broadcast audio (Auracast), AOSP implements:

// Broadcast sink flow (native)
void OnBroadcastSourceFound(AdvertisingReport report) {
    // Parse Extended Advertising for broadcast metadata
    BroadcastMetadata metadata = ParseBroadcastMetadata(report);
    
    // Display: "Airport Gate B47 - English"
    NotifyBroadcastSourceFound(metadata);
}

void SyncToBroadcast(BroadcastMetadata metadata) {
    // 1. Sync to Periodic Advertising
    HCI_LE_Periodic_Advertising_Create_Sync(metadata.sync_info);
    
    // 2. On PA sync established, parse BASE
    BASE base = ParseBASE(periodic_adv_data);
    
    // 3. Select subgroup and BIS streams
    // 4. Sync to BIG
    HCI_LE_BIG_Create_Sync(base.big_params, selected_bis);
    
    // 5. Set up ISO data path
    HCI_LE_Setup_ISO_Data_Path(bis_handle, HCI_DATA_PATH);
    
    // 6. Start receiving and decoding audio
}

13. The State Machine That Runs It All

The AOSP LE Audio implementation uses several interconnected state machines:

Connection State Machine

Manages the overall connection lifecycle for each device:

This state diagram shows the LE Audio connection state machine with four states: Disconnected, Connecting, Connected, and Disconnecting.

Transitions: CONNECT event moves from Disconnected to Connecting, successful connection moves to Connected, DISCONNECT event moves to Disconnecting, and completion returns to Disconnected. Timeout or failure from Connecting also returns to Disconnected.

Group Audio State Machine

Manages the audio state for a group of devices (coordinated set):

This is a state diagram showing the group audio state machine with states: Idle, Codec Configured, QoS Configured, Enabling, Streaming, and Disabling. The forward path proceeds through each state in order as audio streams are set up. The Release operation returns any state to Idle.

How the Pieces Fit Together (Code Walkthrough)

Here's a simplified walkthrough of what happens when you press "play" on your music app with LE Audio earbuds connected:

The above diagram traces the sequence of events when a user presses "play" in a music app with LE Audio earbuds connected.

The flow is:

1. The music app writes PCM audio to an AudioTrack.

2. The Android AudioFlinger routes the audio to the Bluetooth Audio HAL.

3. The HAL notifies LeAudioService that audio is starting.

4. LeAudioService looks up the active group and triggers GroupStreamStart in the native stack.

5. The native stack configures ASEs on both earbuds (Config Codec → Config QoS → Enable) by writing to the ASCS control point on each device.

6. The native stack creates a CIG with two CIS channels via HCI.

7. Both CIS channels are established to the earbuds.

8. The ISO data path is set up.

9. PCM audio flows from the HAL to the LC3 encoder, which produces compressed frames

10. The compressed frames are sent as ISO SDUs over HCI to the controller

11. The controller transmits the frames over the air on the scheduled CIS intervals

12. The earbuds receive, decode, and render the audio at the agreed presentation delay.

14. Putting It All Together: A Day in the Life of an LE Audio Packet

Let's follow a single audio packet from your music app to your earbud:

The above diagram follows a single audio packet through every stage of the LE Audio pipeline.

Starting at the top: the music app generates PCM audio, which passes through Android's AudioFlinger to the Bluetooth Audio HAL. The HAL feeds 10ms of PCM samples (480 samples at 48 kHz) to the LC3 encoder, which compresses them into a ~120-byte frame.

This frame is wrapped in an ISO SDU with a timestamp and sequence number, then passed over HCI to the Bluetooth controller. The controller segments the SDU into link-layer PDUs, schedules them on the next CIS event, and transmits them over the air using the negotiated PHY (for example, 2M PHY).

On the earbud side, the controller receives the PDUs, reassembles the ISO SDU, and passes the LC3 frame to the earbud's decoder. The decoder reconstructs 480 PCM samples, which are buffered until the presentation delay timestamp is reached, then rendered to the speaker driver.

Total latency: ~40ms from phone to earbud (with 10ms frame + transport + presentation delay). Compare this to Classic Bluetooth A2DP which typically runs at 100-200ms!

The Presentation Delay: The Synchronization Secret

The presentation delay is a crucial LE Audio concept. It's a fixed delay that both sides agree upon during stream setup. All audio must be rendered (played) at exactly:

rendering_time = reference_anchor_point + presentation_delay

This ensures:

• Left and right earbuds play audio at the exact same instant

• Even if transport latency varies between the two CIS channels

• The presentation delay provides a "buffer" for the receiver to absorb jitter

Think of it like a choir director: "Everyone sing at the count of 3. Not before, not after. Exactly at 3."

15. Wrapping Up

Bluetooth LE Audio is the most significant upgrade to Bluetooth audio since... well, since Bluetooth audio was invented. Let's recap:

What It Solves

• Better codec (LC3) — equivalent quality at half the bitrate, or better quality at the same bitrate

• Multi-stream — no more relay earbud architecture, balanced battery life

• Broadcast audio (Auracast) — one-to-many streaming, opening up entirely new use cases

• Hearing aid support (HAP) — finally a standard, interoperable solution

• Unified audio (BAP) — one profile for both music and calls, no more A2DP/HFP switching

The AOSP Stack

• Framework layer: BluetoothLeAudio, BluetoothLeBroadcast APIs

• Service layer: LeAudioService orchestrates everything

• Native layer: C++ le_audio_client_impl handles GATT, ASE state machines, codec negotiation

• Controller layer: CIS/BIS isochronous channels managed via HCI

What's Next?

LE Audio is still maturing. Key areas of development:

• Better interoperability across devices from different manufacturers

• Auracast infrastructure — venues need to install broadcast transmitters

• Dual-mode support — many devices will support both Classic and LE Audio during the transition period

• Higher quality — as Bluetooth bandwidth improves, LC3 can scale to even higher bitrates

• Gaming — ultra-low-latency configurations (7.5ms frames, minimal presentation delay)

The transition from Classic Audio to LE Audio won't happen overnight. It's more like the transition from IPv4 to IPv6 – gradual, sometimes painful, but ultimately necessary. The good news is that both can coexist, and the AOSP implementation supports fallback to Classic Audio for devices that don't support LE Audio.

So the next time you connect your earbuds and marvel at the audio quality (or lack thereof), you'll know exactly which parts of this massive protocol stack are working (or failing) to get those sound waves from your phone to your ears.

Happy coding, and may your packets always be isochronous!

References

1. Bluetooth SIG — LE Audio Specifications

2. Bluetooth SIG — A Technical Overview of LC3

3. AOSP Bluetooth Module — packages/modules/Bluetooth

4. Zephyr Project — LE Audio Stack Documentation

5. Fraunhofer IIS — LC3 Codec

This is a continuation of my previous post on setting up Authentication using Supabase. If you aren't familiar with getting Supabase set up in your project, I highly recommend going through that post.

The Starting Code Repo

Here is the repo from my previous post that will get you to where this post will be starting. You'll just need to set up Supabase and add your credentials/API key to a .env.local file to get up and running. This repo also has styling applied to it that was not included in the previous post.

Prerequisites

You should be familiar with JavaScript, have had some experience with Vue 3, and you should have Node.js and NPM installed on your machine.

If you've gone through the previous post about Supabase Authentication or this other post on Getting Started with Supabase you'll be good to go.

You will also need a free API key from Deepgram for when we get to the transcription section.

Getting Started

Once you have downloaded the repo from above run npm install to get the packages installed for the project.

Add your VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY environment variables from your the dashboard of your own Supabase project.

Run npm run dev to get the local dev server started.

Sign in to the app using either the Sign In form or the Magic Link form. Once you get signed in, you should see the HelloWorld component/page with a sign out button at the top.

Hello World component

How to Fetch a Podcast RSS Feed

The first thing we need to do is add functionality to get a podcast feed into our app. Create a new component in the components folder called PodcastFeed.vue.

Most podcasts have a public RSS feed that we can use to get the information we need with a simple fetch request.

Inside the of the PodcastFeed.vue component create the following form that takes in a RSS feed URL, and hooks up to a button that triggers the fetch request.

Note: I've tried to add comments in the code to help you understand what each part is doing.

<template>
  <div class="podcast-input-feed">
    <label for="email">Podcast RSS Feed URL</label>
    <div class="">
      <!-- binding the url input field to the 'url' data property -->
      <input
        type="url"
        name="url"
        id="url"
        v-model="url"
        placeholder="https://rss.your-org.org/feed/"
        aria-describedby="rss-url"
      />
    </div>
    <!-- hooking the button click to the 'getRssFeed' method -->
    <button @click="getRssFeed()" type="button" class="">Get Feed</button>
  </div>
</template>

<script>
import { ref } from "vue";
import { supabase } from "../supabase";
import { store } from "../store";
export default {
  setup() {
    // I am initializing the url to a url I know works, so that I don't need to keep inputing a url as I'm developing.
    // feel free to change this to a url of your own choosing
    const url = ref("https://anchor.fm/s/3e9db190/podcast/rss");
    // initializing the podcast state to an empty object
    const podcast = ref({});

    function getRssFeed() {
      const feedUrl = url.value;
      return (
        fetch(feedUrl)
          // this returns a promise so we need to convert it to a string
          .then((response) => response.text())
          // this next line is to parse the xml response
          .then((str) =>
            new window.DOMParser().parseFromString(str, "text/xml")
          )
          // parsing the data from the xml response and setting it into the podcast state
          .then((data) => {
            console.log("Data: ", data);
            podcast.value.image_url = data
              .querySelector("image")
              .querySelector("url").innerHTML;
            podcast.value.title = data.querySelector("title").textContent;
            podcast.value.description =
              data.querySelector("description").textContent;
            podcast.value.rss_url = feedUrl;
          })
          .catch((err) => {
            console.log("ERROR: ", err);
          })
      );
    }
    return {
      url,
      podcast,
      store,

      getRssFeed,
    };
  },
};
</script>

With that set up, replace the HelloWorld component in the App.vue file with this new PodcastFeed.vue component:

<template>
  <button v-if="store.state.user" class="signout-button" @click="signOut">Sign Out</button>
  <!-- Check if user is available in the store, if not show auth compoenent -->
  <Auth v-if="!store.state.user" />
  <!-- If user is available, show the app -->
  <div v-else class="app">
    <PodcastFeed />
  </div>
</template>

<script>
import Auth from "./components/Auth.vue";
import PodcastFeed from "./components/PodcastFeed.vue";

import { store } from "./store";
import { supabase } from "./supabase";

export default {
  components: {
    PodcastFeed,
    Auth,
  },
  setup() {
    // we initially verify if a user is logged in with Supabase
    store.state.user = supabase.auth.user();
    // we then set up a listener to update the store when the user changes either by logging in or out
    supabase.auth.onAuthStateChange((event, session) => {
      if (event == "SIGNED_OUT") {
        store.state.user = null;
      } else {
        store.state.user = session.user;
      }
    });

    async function signOut() {
      const { error } = await supabase.auth.signOut();
    }

    return {
      store,

      signOut,
    };
  },
};
</script>

<style></style>

So now the app should look like this:

App after adding PodcastFeed.vue

When you click the button, the data that comes back from the fetch request will show up in the console.

Parsed XML Data

In the getRssFeed method we parse that data and then take the information we need and add it to the podcast state data. We need to display that data so that the user can know the request was successful. We also want to add better error messaging in case the request fails.

Create a new component called PodcastInfo.vue and add the following code:

<template>
  <div class="podcast-info">
    <div class="image-container">
      <img :src="podcast.image_url" alt="" class="" />
    </div>
    <div class="podcast-text">
      <div class="title-desc">
        <p class="title">
          {{ podcast.title }}
        </p>
        <p class="desc">
          {{ podcast.description }}
        </p>
      </div>
    </div>
  </div>
</template>

<script>
import { store } from "../store";
import { supabase } from "../supabase";

export default {
  props: {
    podcast: {
      type: Object,
      required: true,
    },
  },
  computed: {},
  methods: {},
  setup() {},
};
</script>

<style scoped></style>

<template>
  <div class="info-error">
    <h3 class="">There was an error with your request</h3>
    <p class="">Check your RSS feed URL and try again.</p>
  </div>
</template>

<script>
export default {};
</script>

Then update the PodcastFeed.vue to the following in order to bring in the component:

<template>
  <div class="podcast-input-feed">
    <label for="email">Podcast RSS Feed URL</label>
    <div class="">
      <!-- binding the url input field to the 'url' data property -->
      <input
        type="url"
        name="url"
        id="url"
        v-model="url"
        placeholder="https://rss.your-org.org/feed/"
        aria-describedby="rss-url"
      />
    </div>
    <!-- hooking the button click to the 'getRssFeed' method -->
    <button @click="getRssFeed()" type="button" class="">Get Feed</button>
    <!-- Adding in these two new components -->
    <podcast-info v-if="podcast.title && !requestError" :podcast="podcast" />
  </div>
</template>

<script>
import { ref } from "vue";
import { supabase } from "../supabase";
import { store } from "../store";

import PodcastInfo from "./PodcastInfo.vue";

export default {
  components: {
    PodcastInfo,
  },

  setup() {
    // I am initializing the url to a url I know works, so that I don't need to keep inputing a url as I'm developing.
    // feel free to change this to a url of your own choosing
    const url = ref("https://anchor.fm/s/3e9db190/podcast/rss");
    // initializing the podcast state to an empty object
    const podcast = ref({});
    const requestError = ref(false);

    function getRssFeed() {
      const feedUrl = url.value;
      return (
        fetch(feedUrl)
          // this returns a promise so we need to convert it to a string
          .then((response) => response.text())
          // this next line is to parse the xml response
          .then((str) =>
            new window.DOMParser().parseFromString(str, "text/xml")
          )
          // parsing the data from the xml response and setting it into the podcast state
          .then((data) => {
            console.log("Data: ", data);
            podcast.value.image_url = data
              .querySelector("image")
              .querySelector("url").innerHTML;
            podcast.value.title = data.querySelector("title").textContent;
            podcast.value.description =
              data.querySelector("description").textContent;
            podcast.value.rss_url = feedUrl;
          })
          .catch((err) => {
            requestError.value = true;
          })
      );
    }
    return {
      url,
      podcast,
      store,
      requestError,

      getRssFeed,
    };
  },
};
</script>

Now when you click the "Get Feed" button, you should see the following:

Now that we can get the info displayed, we can wire up the app to save the info to Supabase.

How to Add a Table to the Supabase DB

The first thing we need to do is add a table to our Supabase DB. In the Dashboard for your project on Supabase, select the Table Editor and click the New table button. I name the new table podcasts. Enable the Row Level Security (this makes our DB more secure) and add the following columns:

• id (this column should be filled in for you when you create a new table)
• created_at
• name
• image_url
• description
• rss_url
• user_id (for this one, we want to link it via foreign key to our users table created by the Auth service. Click the chain-link icon to get that set up and link it to the users table on the id column.)

podcasts table setup

Because we enabled the Row Level Security, the table won't let anything get inserted until we update the policies for it.

Under the Authentication tab there is a section called 'Policies'. There you should see the podcasts table and a button to create a new policy. When you click on it, it will give you the option to create a policy from a template. Choose the template called 'Enable insert access for authenticated users only'. Now, only users that are authenticated have access to insert anything into the table.

When Supabase runs the insert command, it will automatically run a select command and return the newly inserted row. Because of this, we also have to add a policy to the table allowing the user SELECT access.

Create a new policy with the name Enable select based on userid and then in the USING expression section put (uid() = user_id). That will prevent users from reading other users' information, while still giving them access to their own podcasts in the table.

Select based on userid policy

How to Link Up the UI to the DB So the User Can Save Podcasts

To add a podcast to our DB, we will first add a button to the PodcastInfo component. Add this code to the bottom of the <div class="podcast-info">:

<button @click="addPodcast">Add to My Podcasts</button>

Now add a method called addPodcast to the setup function of the component like this. Don't forget to add the props to the argument of the setup function.

setup(props) {
    function addPodcast() {
      // Setting up the podcast object to send to supabase
      const podcast = {
        name: props.podcast.title,
        image_url: props.podcast.image_url,
        description: props.podcast.description,
        rss_url: props.podcast.rss_url,
        user_id: store.state.user.id,
      };
      // calling supabase method to insert into the db
      supabase
        .from("podcasts")
        .insert(podcast)
        .then(({ body }) => {
          store.addPodcastToStore(body[0]);
        })
        .catch((err) => {
          console.log(err);
        });
    }

    return {
      addPodcast,
    };
  },

You can see in the .then statement we call a method from the global store. Update the store.js file to the following:

import { reactive } from "vue";

export const store = {
  state: reactive({
    user: {},
    // adding podcasts array to global store
    podcasts: [],
  }),

  // adding addPodcastToStore method to store object
  addPodcastToStore(podcast) {
    this.state.podcasts.push(podcast);
  },
};

Now when we click the "Add To My Podcasts" button, the app makes a call to Supabase and then takes the result of that call and adds it to the podcasts array in the global store. (If you are getting a 403 error, make sure you set up the policies correctly. Maybe try restarting the dev server too.)

If a podcast is already in a user's list of podcasts, we don't want to let them click the add button again. To prevent this we need to first call Supabase to get all of the user's podcasts, and then check if the podcast they are looking at is in that list.

This method will not be specific to any one component so we want to create it inside of the global store. That way, any component has access to it. Add this method to the store.js file underneath the addPodcastToStore method:

getPodcastsFromDB() {
    supabase
        .from("podcasts")
        .select("*")
        .then(({ body }) => {
            this.state.podcasts = body;
        });
},

Then we want to update the method to be called whenever a user signs in. Inside of App.vue change the onAuthStateChange handler to this:

supabase.auth.onAuthStateChange((event, session) => {
    if (event == "SIGNED_OUT") {
        store.state.user = null;
    } else {
        // make call to supabase to get Podcasts for the user
        store.getPodcastsFromDB();
        store.state.user = session.user;
    }
});

Now update the PodcastInfo.vue file to this in order to display to the user if a podcast is already in their library.

<template>
  <div class="podcast-info">
    <div class="image-container">
      <img :src="podcast.image_url" alt="" class="" />
    </div>
    <div class="podcast-text">
      <div class="title-desc">
        <p class="title">
          {{ podcast.title }}
        </p>
        <p class="desc">
          {{ podcast.description }}
        </p>
      </div>
    </div>
    <!-- Add check in markup to remove the button if the podcast already exists in the user's list -->
    <div v-if="isInUserPodcasts" class="in-podcasts">In Your Podcasts</div>
    <button v-else class="" @click="addPodcast">Add to My Podcasts</button>
  </div>
</template>

<script>
// importing computed
import { ref, computed } from "vue";
import { store } from "../store";
import { supabase } from "../supabase";

export default {
  props: {
    podcast: {
      type: Object,
      required: true,
    },
  },
  setup(props) {
    // add computed property checking if podcast is in user's podcasts
    const isInUserPodcasts = computed(() => {
      return store.state.podcasts.some(
        (podcast) => podcast.rss_url === props.podcast.rss_url
      );
    });

    function addPodcast() {
      // check if podcast is already in user's podcasts
      if (isInUserPodcasts.value) {
        alert("You already have this podcast in your list!");
      } else {
        const podcast = {
          name: props.podcast.title,
          image_url: props.podcast.image_url,
          description: props.podcast.description,
          rss_url: props.podcast.rss_url,
          user_id: store.state.user.id,
        };
        supabase
          .from("podcasts")
          .insert(podcast)
          .then(({ body }) => {
            store.addPodcastToStore(body[0]);
          })
          .catch((err) => {
            console.log(err);
          });
      }
    }

    return {
      // exposing the isInUserPodcasts computed property
      isInUserPodcasts,
      addPodcast,
    };
  },
};
</script>

<style scoped></style>

Next, we want to display a list of podcasts that the user has added to their library. We have the list in the global store, so we just need to loop through them to display the needed info.

Add the following to the bottom of the PodcastFeed.vue template:

<!-- Loop through podcasts and display them -->
  <div class="feeds">
    <h2 class="">Your Podcast Feeds</h2>
    <ul class="">
      <li v-for="pod in store.state.podcasts" :key="pod.id" class="">
        <a :href="`/podcast/${pod.id}`" class="">
          <img :src="pod.image_url" :alt="`logo for ${pod.name}`" class="" />
          <p class="">{{ pod.name }}</p>
        </a>
      </li>
    </ul>
  </div>

How to Set Up the Other Pages for Our Podcast App

Now that we have the list of podcasts being displayed in the app, we need a way to navigate to an individual podcast. We have the markup set to link to a path like /podcast/{podcast_id}. Now we need to update our app to handle routes like this.

First, install vue-router using npm i vue-router.

Then create a file called router.js with the following code:

// Import Vue Router
import * as VueRouter from "vue-router";

// Import the components that will show on the different routes
import PodcastFeed from "./components/PodcastFeed.vue";
import PodcastDetail from "./components/PodcastDetail.vue";

// Set up the routes
const routes = [
  { path: "/", component: PodcastFeed },
  { path: "/podcast/:id", component: PodcastDetail },
];

// Initialize the router
const router = VueRouter.createRouter({
  history: VueRouter.createWebHistory(),
  routes,
});

// Export the router
export default router;

Update main.js to use the router in the Vue app:

import { createApp } from "vue";
import router from "./router";
import App from "./App.vue";
import "./index.css";

const app = createApp(App);
app.use(router);
app.mount("#app");

Update App.vue to show the router-view component provided by Vue Router:

<template>
  <button v-if="store.state.user" class="signout-button" @click="signOut">Sign Out</button>
  <!-- Check if user is available in the store, if not show auth compoenent -->
  <Auth v-if="!store.state.user" />
  <!-- If user is available, show the app -->
  <div v-else class="app">
    <router-view></router-view>
  </div>
</template>

Now create a PodcastDetail.vue file that will display the episode info for the podcast:

<template>
  <nav class="">
    <a href="/" class="">Home</a>
  </nav>
  <!-- Basic layout for showing podcast info -->
  <div class="podcast-detail">
    <img :src="podcast.image_url" :alt="podcast.name" class="" />
    <h1 class="">{{ podcast.name }}</h1>
    <p>{{ podcast.description }}</p>
    <h2 class="">Episodes</h2>
    <!-- Looping through each episode of a podcast and displaying episode info -->
    <ul class="">
      <li
        v-for="episode in episodes"
        :key="episode.guid || episode.link"
        class=""
      >
        <div class="info">
          <h3>{{ episode.title }}</h3>
          <audio class="" controls>
            <source :src="episode.url" type="audio/mpeg" />
            Display
          </audio>          
        </div>        
      </li>
    </ul>
  </div>
</template>

<script>
// Importing necessary methods
import { ref, onMounted } from "vue";
import { useRoute } from "vue-router";
import { supabase } from "../supabase";

export default {
  setup() {
    const route = useRoute();
    const podcast = ref({});
    const episodes = ref([]);

    // Getting podcast info from the database
    async function getPodcastData() {
      const {
        data: [podcastinfo],
      } = await supabase.from("podcasts").select().eq("id", route.params.id);
      podcast.value = podcastinfo;

      // Making call to episode url to get episode info
      getEpisodes(podcastinfo.rss_url);
    }

    function getEpisodes(url) {
      fetch(url)
        .then((response) => response.text())
        .then((str) => new window.DOMParser().parseFromString(str, "text/xml"))
        .then((data) => {
          // Finding all the "item" tags in the xml response which will contain the episode info
          const items = data.querySelectorAll("item");
          // Looping through each item and getting the episode info and pushing it to the 'episodes' array
          items.forEach((item) => {
            let url;

            // Not every podcast episode is going to have the `enclosure` tag, so we need to check if it exists
            try {
              url = item.querySelector("enclosure").getAttribute("url");
            } catch (e) {
              console.log("error", e);
              url = item.querySelector("link").innerHTML;
            }

            episodes.value.push({
              // this `title` and the `guid` properties looks a little different because the title contains CDATA tags which need to be grabbed with the 'childNodes' property
              title: item.querySelector("title").childNodes[0].textContent,
              link: url,
              url: url,
              description: item.querySelector("description").innerHTML,
              pubDate: item.querySelector("pubDate").innerHTML,
              guid: item.querySelector("guid").childNodes[0].textContent,
            });
          });
        })
        .catch((err) => {
          alert("Couldn't get episodes", err);
        });
    }

    onMounted(() => {
      // Getting podcast info from the database once the component is mounted
      getPodcastData();
    });

    return {
      podcast,
      episodes,
    };
  },
};
</script>

<style scoped></style>

With those changes, we can now see the individual episodes of the podcast and can play them using the <audio> html tag.

How to Get the Transcriptions of the Podcasts

The last step is to get transcriptions for the podcasts, and then save them to our database.

If you haven't yet, you'll need to get a free API key from Deepgram in order to process the audio and get the transcriptions.

Once you get the API key, add it to your .env.local file as VITE_DEEPGRAM_KEY. Make sure you restart your dev server here, otherwise you'll probably get a 403 Forbidden error when we finally call the API.

Then add this code to a deepgram.js file in the src folder.

const deepgramKey = import.meta.env.VITE_DEEPGRAM_KEY;

async function deepgram(url) {
  const response = await fetch(
    "https://api.deepgram.com/v1/listen?punctuate=true&diarize=true&utterances=true",
    {
      method: "POST",
      headers: {
        Authorization: `Token ${deepgramKey}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        url: url,
      }),
    }
  );
  const json = await response.json();
  return json.results;
}

export default deepgram;

This gives us a utility function we can import into our app in other files to call the Deepgram API in order to get the transcriptions. We added the punctuate, diarize, and utterances to the URL as parameters to get a cleaner transcription that is easier to read.

Now that we have that, we need to add some functionality to the PodcastDetail.vue file. I'll walk through the changes and then later will put up the final code for the file.

First we need to have some state to keep track of the transcriptions we get, and also to have some loading state once we click a button to get a transcription. So we'll add these two lines to our setup function:

let transcriptions = ref({});
const episodeTranscriptionLoading = ref([]);

Don't forget to add them to the return object of the setup function.

Then add this function to make the request to Deepgram, and then add the transcription to the local transcriptions object.

// Function to get a transcription from Deepgram, passing in the episode url
async function getTranscription(episode) {
    // setting the loading state to true for the episode
    episodeTranscriptionLoading.value.push(episode.guid);
    const transcription = await deepgram(episode.url);
    // setting a unique id for the episode transcription
    transcriptions.value[`${podcast.value.id}---${episode.guid}`] =
        transcription;
    // removing the loading state for the episode
    episodeTranscriptionLoading.value.splice(
        episodeTranscriptionLoading.value.indexOf(episode.guid),
        1
    );
}

Make sure you import the deepgram function from deepgram.js at the top of the script tag.

Then update the template to this:

<template>
  <nav class="">
    <a href="/" class="">Home</a>
  </nav>
  <!-- Basic layout for showing podcast info -->
  <div class="podcast-detail">
    <img :src="podcast.image_url" :alt="podcast.name" class="" />
    <h1 class="">{{ podcast.name }}</h1>
    <p>{{ podcast.description }}</p>
    <h2 class="">Episodes</h2>
    <!-- Looping through each episode of a podcast and displaying episode info -->
    <ul class="">
      <li
        v-for="episode in episodes"
        :key="episode.guid || episode.link"
        class=""
      >
        <div class="info">
          <h3>{{ episode.title }}</h3>
          <audio class="" controls>
            <source :src="episode.url" type="audio/mpeg" />
            Display
          </audio>
            <!-- button to get transcriptions -->
          <button
            v-if="!transcriptions[`${podcast.id}---${episode.guid}`]"
            @click.prevent="getTranscription(episode)"
            class=""
          >
            {{
              episodeTranscriptionLoading.includes(episode.guid)
                ? "Loading..."
                : "Get Transcription"
            }}
          </button>
        </div>
          <!-- box to display the transcription -->
        <div
          v-if="transcriptions[`${podcast.id}---${episode.guid}`]"
          class="transcription"
        >
          <p>
            {{
              transcriptions[`${podcast.id}---${episode.guid}`].channels[0]
                .alternatives[0].transcript
            }}
          </p>
        </div> 
      </li>
    </ul>
  </div>
</template>

How to Save the Transcriptions

Now that we can get the transcriptions, we need to add the functionality to save them to Supabase.

First, go create a table in Supabase like we did above, but this time name the table transcriptions. You'll want the following as the columns:

• id – varchar (primary) Also remove the "Is Identity" check mark in the settings for this column
• podcast_id – int8
• episode_guid – varchar
• transcript – text
• user_id – uuid (You'll need to link this to the user table by clicking on the link icon)
• created_at – timestamptz

columns for transcriptions table

Once that table is set up, we can add a reactive property called savedTranscriptions to the component and then add the following code to save the transcriptions to Supabase. Then we'll store them in the object savedTranscriptions.

function saveTranscription(podcastId, episodeGuid) {
    supabase
        .from("transcriptions")
        .insert({
        id: `${podcastId}---${episodeGuid}`,
        podcast_id: podcastId,
        episode_guid: episodeGuid,
        transcript:
        transcriptions.value[`${podcastId}---${episodeGuid}`].channels[0]
        .alternatives[0].transcript,
        user_id: store.state.user.id,
    })
        .then(({ data: [transcriptObject] }) => {
        savedTranscriptions.value[transcriptObject.id] =
            transcriptObject.transcript;
    });
}

Once a user has a transcription saved, we need to display it whenever they re-visit a page. Add this function to get that data from Supabase:

async function getTranscriptions() {
    const { data: transcriptions } = await supabase
    .from("transcriptions")
    .select()
    .eq("podcast_id", podcast.value.id);
    console.log("Transcriptions", transcriptions);
    transcriptions.forEach((transcript) => {
        console.log("id", transcript.id);
        savedTranscriptions.value[transcript.id] = transcript.transcript;
    });
}

We will want this called whenever a user hits this page, but not until we get the podcast information. Add a call to getTranscriptions to the bottom of the getPodcastData function to do that.

The last thing to do is to update the template to include the save buttons and to display transcriptions if they are in the saved objects. The final code for the PodcastDetail.vue should then look like this:

<template>
  <nav class="">
    <a href="/" class="">Home</a>
  </nav>
  <!-- Basic layout for showing podcast info -->
  <div class="podcast-detail">
    <img :src="podcast.image_url" :alt="podcast.name" class="" />
    <h1 class="">{{ podcast.name }}</h1>
    <p>{{ podcast.description }}</p>
    <h2 class="">Episodes</h2>
    <!-- Looping through each episode of a podcast and displaying episode info -->
    <ul class="">
      <li
        v-for="episode in episodes"
        :key="episode.guid || episode.link"
        class=""
      >
        <div class="info">
          <h3>{{ episode.title }}</h3>
          <audio class="" controls>
            <source :src="episode.url" type="audio/mpeg" />
            Display
          </audio>
          <button
            v-if="savedTranscriptions[`${podcast.id}---${episode.guid}`]"
            disabled
          >
            Transcription Saved
          </button>
          <button
            v-else-if="
              !transcriptions[`${podcast.id}---${episode.guid}`] &&
              !savedTranscriptions[`${podcast.id}---${episode.guid}`]
            "
            @click.prevent="getTranscription(episode)"
            class=""
          >
            {{
              episodeTranscriptionLoading.includes(episode.guid)
                ? "Loading..."
                : "Get Transcription"
            }}
          </button>
          <button
            v-if="
              transcriptions[`${podcast.id}---${episode.guid}`] &&
              !savedTranscriptions[`${podcast.id}---${episode.guid}`]
            "
            class="save"
            @click.prevent="saveTranscription(podcast.id, episode.guid)"
          >
            Save Transcription
          </button>
        </div>
        <div
          v-if="savedTranscriptions[`${podcast.id}---${episode.guid}`]"
          class="transcription"
        >
          <p>
            {{ savedTranscriptions[`${podcast.id}---${episode.guid}`] }}
          </p>
        </div>
        <div
          v-else-if="transcriptions[`${podcast.id}---${episode.guid}`]"
          class="transcription"
        >
          <p>
            {{
              transcriptions[`${podcast.id}---${episode.guid}`].channels[0]
                .alternatives[0].transcript
            }}
          </p>
        </div>
      </li>
    </ul>
  </div>
</template>

<script>
// Importing necessary methods
import { ref, onMounted } from "vue";
import { useRoute } from "vue-router";
import { supabase } from "../supabase";
import { store } from "../store";
import deepgram from "../deepgram";

export default {
  setup() {
    const route = useRoute();
    const podcast = ref({});
    const episodes = ref([]);
    let transcriptions = ref({});
    let savedTranscriptions = ref({});
    const episodeTranscriptionLoading = ref([]);

    // Getting podcast info from the database
    async function getPodcastData() {
      const {
        data: [podcastinfo],
      } = await supabase.from("podcasts").select().eq("id", route.params.id);
      podcast.value = podcastinfo;

      // Making call to episode url to get episode info
      getEpisodes(podcastinfo.rss_url);
      await getTranscriptions();
    }

    function getEpisodes(url) {
      fetch(url)
        .then((response) => response.text())
        .then((str) => new window.DOMParser().parseFromString(str, "text/xml"))
        .then((data) => {
          // Finding all the "item" tags in the xml response which will contain the episode info
          const items = data.querySelectorAll("item");
          // Looping through each item and getting the episode info and pushing it to the 'episodes' array
          items.forEach((item) => {
            let url;

            // Not every podcast episode is going to have the `enclosure` tag, so we need to check if it exists
            try {
              url = item.querySelector("enclosure").getAttribute("url");
            } catch (e) {
              console.log("error", e);
              url = item.querySelector("link").innerHTML;
            }

            episodes.value.push({
              // this `title` and the `guid` properties looks a little different because the title contains CDATA tags which need to be grabbed with the 'childNodes' property
              title: item.querySelector("title").childNodes[0].textContent,
              link: url,
              url: url,
              description: item.querySelector("description").innerHTML,
              pubDate: item.querySelector("pubDate").innerHTML,
              guid: item.querySelector("guid").childNodes[0].textContent,
            });
          });
        })
        .catch((err) => {
          alert("Couldn't get episodes", err);
        });
    }

    // Function to get a transcription from Deepgram, passing in the episode url
    async function getTranscription(episode) {
      // setting the loading state to true for the episode
      episodeTranscriptionLoading.value.push(episode.guid);
      const transcription = await deepgram(episode.url);
      // setting a unique id for the episode transcription
      transcriptions.value[`${podcast.value.id}---${episode.guid}`] =
        transcription;
      // removing the loading state for the episode
      episodeTranscriptionLoading.value.splice(
        episodeTranscriptionLoading.value.indexOf(episode.guid),
        1
      );
    }

    function saveTranscription(podcastId, episodeGuid) {
      console.log(
        "saving transcription",
        transcriptions.value[`${podcastId}---${episodeGuid}`]
      );
      supabase
        .from("transcriptions")
        .insert({
          id: `${podcastId}---${episodeGuid}`,
          podcast_id: podcastId,
          episode_guid: episodeGuid,
          transcript:
            transcriptions.value[`${podcastId}---${episodeGuid}`].channels[0]
              .alternatives[0].transcript,
          user_id: store.state.user.id,
        })
        .then(({ data: [transcriptObject] }) => {
          console.log("saved", transcriptObject);
          savedTranscriptions.value[transcriptObject.id] =
            transcriptObject.transcript;
        });
    }

    async function getTranscriptions() {
      const { data: transcriptions } = await supabase
        .from("transcriptions")
        .select()
        .eq("podcast_id", podcast.value.id);
      console.log("Transcriptions", transcriptions);
      transcriptions.forEach((transcript) => {
        console.log("id", transcript.id);
        savedTranscriptions.value[transcript.id] = transcript.transcript;
      });
    }

    onMounted(() => {
      // Getting podcast info from the database once the component is mounted
      getPodcastData();
    });

    return {
      podcast,
      episodes,
      transcriptions,
      savedTranscriptions,
      episodeTranscriptionLoading,

      getTranscription,
      saveTranscription,
    };
  },
};
</script>

<style scoped></style>

Conclusion

If you've followed the steps above, you should have a working app. Here is the final code if you want to double check against what I have written.

I know I enjoyed making the app. Supabase makes it really easy to get a database/backend up and running. Please reach out to me on Twitter if you have any questions!

If so, no worries! It is a pretty common issue that you can resolve quickly. In this article, I am going to help you solve the issue completely. I'll be using a well known distro called Manjaro Linux, but I believe that the same method is applicable for all Linux distributions.

Step 1 – Open the terminal / console

Step 2 – Open Alsamixer

We will use alsamixer to tweak the audio settings. Type alsamixer and press the Enter key on your keyboard.

Alsamixer will open in your terminal.

Step 3 – Set Preferred Sound Card

Now you need to select your preferred sound card. For that, simply press the F6 key on your keyboard. Select the sound card appropriate for you.

If you are not sure, then you can simply select one of them at a time (press the Enter key after selecting the sound card) and try the rest of the methods to see whether that sound card was appropriate or not. For me, it is default:1 HD-Audio Generic.

The AlsaMixer window will change depending on your selected sound card.

Then press the right arrow (➜) key until you find Auto-Mute Mode.

You will see that it is currently ENABLED.

We need to change it back to DISABLED. You have to press the down arrow (↓) key to disable it.

Then press the Esc key to exit AlsaMixer.

Step 4 – Save Settings

Now we need to save the settings that we just tweaked in AlsaMixer. For that, type sudo alsactl store. Now press the Enter key.

Now you are good to go!

If you want to check whether the audio is working in your speakers or not, then you can go to Settings.

Then go to Sound.

If you change your Output Device, then you should see that the speaker audio is working perfectly. I am using the Line Out option here for my workstation.

Now you should see that the audio issue has been fixed!

BONUS: I have also made a complete video tutorial about this and published the video on my new YouTube channel.

Conclusion

I hope this trick helps you if you also face this kind of audio issue in your speakers. Thanks a lot for reading the entire article till now. If it helps you then you can also check out other articles of mine at freeCodeCamp.

If you want to get in touch with me, then you can do so using Twitter, LinkedIn, and GitHub.

You can also SUBSCRIBE to my YouTube channel (Code With FahimFBA) if you want to learn various kinds of programming languages with a lot of practical examples regularly.

If you want to check out my highlights, then you can do so at my Polywork timeline.

You can also visit my website to learn more about me and what I'm working on.

Thanks a bunch!

This error can be caused by a corrupt driver, overdue updates, or improper connection.

In this article, I will show you 2 ways you can fix the "no audio output device is installed" error. I will also show you some other troubleshooting methods, so you will be able to listen to music or hear sounds on your computer once again.

How to Fix the No Audio Output Device Is Installed Error by Updating Audio Driver

Step 1: Click on Start (Windows logo) or press the WIN key on your keyboard, then search for "device manager". Click on the first search result or press ENTER.

Step 2: Expand “Audio inputs and outputs”.

Step 3: Right-click on your audio device and select "Update driver".

Step 4: Choose “Search automatically for updated driver software”. Windows will now search the internet for an updated audio driver and install it for your computer.

How to Fix the No Audio Output Device Is Installed Error by Uninstalling your Audio Device

Step 1: Press the WIN (Windows logo) key on your keyboard, then search for "device manager". Click on the first search result or press ENTER.

Step 2: Expand “Audio inputs and outputs”

Step 3: Right-click on your audio device and select "Uninstall device"

Step 4: Restart your computer and a newer version of your audio device will be downloaded for you.

Final Words

In this article, you learned about 2 ways you can fix the "no audio output device is installed" error.

Apart from updating your computer's audio driver, or the audio device itself, you can also fix the "no audio output device is installed error" by updating Windows 10.

In addition, if you're using an external audio device, you should make sure it is correctly connected to your computer – if it isn't, this improper connection can mess with an external audio device.

Thank you for reading. If you find this article useful, please share it with your friends and family.

Audio is a very important part of any digital media. Since audio or sound is a wave (a literal, continuous wave) it is analog in nature. This means that it cannot be stored and processed by the computer directly, as a computer only understands digital signals.

So naturally, engineers found a way to convert these analog signals into digital signals. They've also developed a method to save them in digital format. I'm talking about audio codecs.

Audio codecs, in simpler terms, are just encoders and decoders (co - coders, dec - decoders, or co - compressor, dec - decompressor). They can be implemented as hardware codecs, which encode analog audio to digital audio and vice versa.

An example of such codecs are sound cards in your computer, which have built-in analog-to-digital (ADC) and digital-to-analog (DAC) circuits.

The software counterpart is an algorithm that compresses and decompresses digital audio. Some examples of such codecs are MP3, FLAC, WAV, and AAC.

Today, we'll be looking at software encoders and we'll focus our attention on the WAV format.

What compression means in audio codecs

Audio compression algorithms are divided into two categories: Lossless and Lossy. So what's the difference between these two?

Lossless algorithms

These algorithms may perform some kind of compression on the audio, but it doesn't remove any audio data, thus nothing is lost. The tradeoff is that you have very large file sizes.

Lossy algorithms

In this type of compression, some part of audio fidelity, deemed inaudible/indistinguishable to human ears, is removed or has its fidelity (or accuracy or loudness) reduced. Compression is also performed after this step. You can read more about it here.

Unless you have a very good HI-FI sound system that can reproduce those extra fidelity sounds, you should go for lossy. It will save space and remove extra data that you might never even hear.

Now that you understand audio compression, let's move on to the main topic of this article.

What is WAV?

WAV (or WAVE) stands for Waveform Audio File Format. It was developed by IBM and Microsoft. The file extension is .wav or .wave.

The WAV format is widely used where you would want uncompressed audio. For example, sound engineers use it a lot – and due to its lossless form, it can be used for early production samples.

The large file size means that it's usually not suitable for transmission over the internet. Other formats like MP3 and AAC offer much smaller file sizes, as they are lossy.

Limitations of the WAV format

WAV files are limited to 4GB in size as they have a 32bit file size header. W64 is a successor which has a 64bit header, allowing even larger file sizes.

Apart from that, since the audio is uncompressed, its file size is large. So if the audio is stored on a slow disk drive, it can cause buffering issues (as audio needs to be loaded from disk to RAM before the music player can decode and play the file).

This might not be an issue, however, on modern computers, as they have much faster disks drives.

How to open a WAV file

Since WAV is quite a popular format, almost all devices today support it using built-in media players.

• On Windows, the Windows Media Player is capable of playing WAV files.
• On MacOS, iTunes or QuickTime can play WAV files.
• On Linux, your basic ALSA system can play these files.

Other solutions also exist which can help you play WAV files, such as the VLC media player or any other music players.

How to Play a WAV file on Windows using Windows Media Player

1. Open Windows Media Player using Search

step 1: windows search

2. Drag and drop your WAV audio file from explorer to Windows Media Player

step 2: drag and drop your audio

3. Click Play!

step 3: click play

How to Play a WAV file on any OS with VLC Media Player

VLC media player is an open-source media player that can play most of your file formats without needing to download external codecs. It is cross platform, too, so you'll get the same features and interface across all operating systems, whether you use Linux, Windows, or MacOS (also supports Android and iOS).

Here are the steps to play an WAV file with VLC on your PC.

1. Download VLC from the official website here
2. Open VLC
3. Click on Media, then select Open File

step 3: click on 'media', then click 'open file'

4. In the file picker dialog, choose your audio, click Open and the WAV file should start playing automatically!

step 4: select your file and click 'open'

Or if you prefer a GIF:

Step 1-4 for VLC :D

How to convert WAV files to MP3

Depending on the end device, you might want to convert WAV to other formats, for example to save disk space or if you're listening on a low end device.

MP3 is quite a good format for storing audio. It gives you 50-75% smaller file sizes, while retaining almost the same listening experience. Let's see how you can convert these files.

Online Convertors

If you only convert audio on rare occasions, I would suggest that you to use an online convertor such as CloudConvert. And Google is your friend here.

Do keep in mind that these online convertors can store your files for some time (even forever), so read their policy if you want to convert something mission critical.

Offline Convertors

Another option is to convert these files locally. This will help you if you want to convert frequently or have something that you don't want to expose to the internet.

There are two ways to do this:

Audacity: Audacity is a free, open-source cross-platform application that allows you to edit and convert audio.

The only con is you have to do some initial setup first (installing LAME). Also you have to convert files one by one.

FFmpeg: FFmpeg is a cross-platform command line tool to convert audio and video files. You can run the following command to convert a wav file to mp3:
ffmpeg -i input.wav output.mp3

You can dig around FFmpeg's docs to figure out how to customize some parameters and pass a list of files for batch conversions.

The main con is that FFmpeg is not user friendly. You need to know how to use command line tools. Though stuff like a FFmpeg GUI exists, it is out of the scope of our discussion here.

Thanks for reading!

I hope this article gave you some insights into audio compression, as well as how to play around with and convert WAV files.

For any questions or comments, you can find me on Twitter @vaibhav_kandwal. Thank you for reading.

HTML allows us to create standards-based video and audio players that don’t require the use of any plugins. Adding video and audio to a webpage is almost as easy as adding an image or formatting some text.

There are two different ways to include video elements. We will be discussing both of them below.

Video Element

The <video> element allows us to embed video files into an HTML, very similar to the way images are embedded.

Attributes we can include are:

• src This attribute stands for the source, which is very similar to the src attribute used in the image element. We will add the link to a video file in the src attribute.
• type This is going to be video/mp4 because .mp4 is the format of the video we are using. We can also use different video formats like .ogg or .webm, then the value of type attribute will change to video/ogg or video/WebM respectively.

Note: some common video formats are WebM, Ogg, MP4.

<video> in Webpage

We now have this video on our page. But there’s a problem. This video isn’t playing automatically and there are also no controls to start the video.
We will have to add controls manually by using the controls attribute to our video element.

This attribute doesn’t take any value, because it’s a boolean attribute. That means it can either be true or false.

Now, by having the controls attribute in our video element, it means that it’s true and it will display playback controls.

<video> + Controls

Now, if we remove the controls we could also make the video autoplay, by using the autoplay attribute. This is also a boolean attribute.

<video> element + autoplay attribute (without controls attribute)

Now, as you can see the video is playing by itself, and there’s no control. So, we didn’t actually start the video, but we also can’t stop the video.

We can also have controls and autoplay together.

<video> element with autoplay and controls attribute

You can provide different attributes to the video element, depending on the requirement.

I mentioned above that there are two different ways to add the video element. Let’s try the other way.

Source Element

Earlier we used a video element with self-closing tag, but here we will close the video element. So we have an opening and closing tag now.

We will also remove the type and source attributes from the video element and paste it into another element.

<video>  <source src="http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/ForBiggerEscapes.mp4" type="video/mp4"></video>

We just moved the attributes over to the source element.

Now, why would we want to do that?

Well, in most cases, with the video we will have multiple sources because we need to provide different file types depending on which browser is viewing your video because different browsers support different file types.

The video will look exactly the same. But now we have broader browser support.

Video with broader browser support (No Attributes)

Now, if we want to add attributes like controls, autoplay, loop etc, we will add it to the <video> element.

Video with broader browser support and other attributes

Audio Element

The <audio> element is very similar to the video element. However, the only major difference is that there are no visuals.

We can use the audio element to play an audio file on our web page — such as an mp3 file.

Now, just like the video tag, there are two different ways to do this.

• Use a single tag representing the entire element.
• Opening and closing tag with the child elements in between.

Now, we’ll have an opening and closing audio tag, and then we will add the source element in between.

The folder structure might look like this:

|-- project    |-- audio      |-- sample.mp3      |-- sample.ogg    |-- css      |-- main.css      |-- normalize.css    index.html

There is no controls attribute given to the <audio> element in the example above, so the &lt;audio> element won’t show up in the HTML document.

Now, you can see that there are only a few key differences here. The value in type attribute is changed from “video/mp4” to “audio/mp3”. In the src attribute, we’ve changed from a video file with .mp4 extension to an audio file with .mp3 extension.

Now, just like the video element, we won’t actually be able to stop or start the audio without any controls. So, we will be adding the controls attribute to the audio element.

Audio element(<audio></audio>) with multiple sources for broader browser support

You can also add other attributes in the <audio> element like autoplay, loop etc.

We have covered the essentials of audio and video elements in HTML.

You can learn more about audio and video in the links given below:

• MDN Web docs — Video
• MDN Web docs — Audio

I hope you’ve found this post informative and helpful. I would love to hear your feedback!

Thank you for reading!

A-Frame is a web framework for building virtual reality experiences. Ever since its introduction in late 2015, it quickly became a favorite among artists and creators of all backgrounds who want to experiment with WebXR.

I am a creative coder with a background in audio. Diving into the sonic possibilities of this new platform was a very exciting and rewarding journey. Most of my A-Frame experience was confined to standard desktop and smartphone environments and not VR. I am sharing my findings. I want to create a sort of an unofficial manual on how to implement, use and create audio in A-Frame. In this first part, we will take a look at how to use A-Frame’s out of the box audio capabilities.

Prerequisites

This write-up assumes you have some experience with A-Frame. You don’t have to be an expert on it but knowing how the basics work will make following this tutorial easier. If you haven’t had a chance to check it out yet, you can start here.

A-Frame Sound Component

A-Frame is a framework based on Three.js. The sound component it provides is a wrapper around the Three.js positional audio component (or non-positional depending on what we choose, but more on that later), which uses the Web Audio API.

This means we get things like positional audio, volume control and audio playback out of the box, as soon as we use an A-Frame sound component.

_A-Frame sound component properties, screenshot taken from [A-Frame Docs](https://aframe.io/docs/0.8.0/components/sound.html" rel="noopener" target="blank" title=")

But how do we add this component to our scenes and provide audio feedback to user interactions and/or create a soundscape?

To demonstrate this I created an A-Frame project from scratch. It is based on user interactions with a desktop computer. (i.e. to use with a mouse and a keyboard). The principles should transfer to other types of controls for the most part.

You have the option to either start with a fresh copy of the project [Glitch][GitHub] — with no sounds attached to it — and follow along while implementing the provided sounds yourself. Or you can check out the finished version [Glitch][GitHub] and follow along by reading the code.

The Kitchen

Before we start the audio implementation process, let’s take a look at our scene. We have several 3D models here (courtesy of Google Poly). Our kitchen is a complete model by itself. Items like the espresso machine, radio, the frying pan and the egg on top of it are separate models that are added to the scene on top of the kitchen.

Now let’s see the methods we can use to add sounds to this scene.

User Interaction Sounds

User interaction sounds are usually one-shot sounds. This means they are short samples that play once when triggered. They are not continuous or looped like environment audio or music. Which means we need to find a way to put an audio file on our scene and then trigger it when our user interacts with that object. (e.g. clicks the mouse button, hovers over it etc.).

To trigger a sound on user interaction, we can:

1. Put a sound on a model
2. Put a sound on a primitive, like a box geometry
3. Put a primitive on an component

So let’s go through our options one by one and see the use cases for each one.

Putting a Sound on a Model

Who doesn’t want to start the day with a fresh cup of espresso? (If that’s not you, feel free to grab a tea model from here and go with that instead.)

I would say half of the satisfaction of having that caffeine boost is the sound our beloved espresso machine makes. To make sure our scene provides that aural feedback, we implement a sound that will respond to user interaction.

First let’s take a look at how our espresso machine works under the hood

We start by loading our model with the A-Frame loader. Then we set the position, rotation and scale of the model within the scene, by using the named properties.

Our model is referenced by the id “#coffeeMaker”, instead of the relative path of the file. All the models for this project is registered in the Asset Management System beforehand.

Easiest way to add a sound to our espresso machine is by adding the sound component to it by using it as an HTML attribute on the object.

We reference our sound by using the asset management system again, and setting the volume of it to 1. This means it will be heard at 100%. Now for the most important part, we set the “on” property of the sound to the “click” value. This means when a user clicks on this object, the sound will be triggered.

We don’t use the autoplay or loop properties here as this is a one-shot that depends on user interaction. We leave the positional property as “on” by default. Otherwise we would hear the sound at the same volume level at all times, no matter how distant we are from the object. Sound wouldn’t have any panning and would always play exactly where we are, instead of to the left, right or behind us depending on our position relative to the object.

NOTE: Positional sounds like these should be rendered mono to make the spatial cognition of the sound easier, while background music or audio ambiances that are not positional preferably should be rendered stereo.

Time to Crack a Few Eggs

Now it’s your turn, go ahead and implement the provided frying egg sound to the egg model, which is placed on top of the frying pan. For a challenge, you can also try to use a few additional sound properties of your choosing. Go around the scene after putting the egg sound in place and test your implementation to see if it sounds realistic (or unrealistic if that’s what you are going for!)

Did you do it?

Great!

Your code for the egg model now should look approximately like this (with your desired properties and values)

Putting a Sound on a Geometry

So we can add our sounds to the models by simply adding them as an HTML attribute. What if we want to put a sound to an object that is already part of a bigger model and not a separate entity by itself?

Let’s say we want to add a sound to the red bottle on the right, which should make it sound like we are picking it up when we click on it.

If we put the sound on the kitchen model like we did with the smaller models, it would mean that the sound would trigger no matter where we clicked on the model itself, instead of only on the bottle like we want.

We can solve this problem by using a geometry which we can click on, aligning it to where the bottle is, and adding the sound property to it.

A-Frame Inspector to the Rescue

For the next steps I highly recommend that you start creating and positioning objects inside your scene right in the browser by using the A-Frame Inspector. You can then copy and use this code instead of guesswork as to where your object should be positioned.

Open the A-Frame Inspector by using the <ctrl> + <alt> + i shortcut.

Let’s start by creating a geometry primitive on our scene, a cylinder should work well given our bottle’s shape.

Now scale and position this cylinder by using the A-Frame inspector. It can cover our bottle and respond to user interaction on the correct spot.

NOTE: If you add this geometry inside the model, it would enable you to move or rotate the parent model and preserve the correct position of everything inside.

Scale and position the cylinder inside the scene by using the controls top right

You can paste the code you copied from the inspector and just move the scale, position and rotation values inside the .

Copy the entity and its properties by using the button on the top right

Make sure to bring down the opacity of the material to 0, so our bottle can stay visible inside the cylinder geometry. As a final step, add the provided bottle sound to the object, like you did before with the espresso machine and the egg.

Now your cylinder code should look like this…

…and respond to user interaction correctly.

Using an Component

<a-sound> is a primitive wrapper around the A-Frame sound component and allows us to use audio without attaching it to anything else on the scene. However if we want to trigger this sound on interaction, we still need a type of geometry which will allow us to interact with this object.

We can put this geometry on anywhere else on the scene. (think of a user interface menu button which will trigger a non-positional sound). Or we can put it directly on to and then position it on top of the object we want to hear audio feedback from.

Which means to add a sound to our toaster, we can do the reverse of what we just did and create an component and attach a clickable geometry to it.

Environment Audio

We saw a couple of the ways we can use to implement sounds that respond to user interactions. But what about sounds that don’t require the user to do anything to play? These are sounds that go through the scene from beginning to end, to create atmosphere, mood, a sense of place?

If we take a look at our kitchen, we can see that there is a big fridge to the left, which is dead silent right now. Not to mention, whether we are consciously aware of it or not, almost all the environments we occupy (unless they are an anechoic chamber) have something called a presence or a room tone.

Electric hums, machinery, air conditioning units and alike create the room tone with or without us adding on top of it acoustically. So, to reflect that, our choice should be an ongoing. In this case a looping sound which is present throughout our scene.

NOTE: .mp3 format by its nature does not loop seamlessly in most platforms, there’s always a very short gap between loops which breaks the audio consistency, and therefore for looping sounds other formats like .wav or .ogg should be used.

Adding Room Tone

Now let’s add the provided room tone to our scene. We have several options depending on what type of A-Frame project we are working on. If we have only one room-as is the case here-we can put our room tone directly to our . Or if we have several rooms in our scene with different characteristics, we can put the room tone in to a plane geometry which could act as the ground. Or in an object which we can put in the center of the room. In all cases we have to make sure our room tone is not positional, as opposed to all the other sounds we used previously on this project.

Given that we are only working with a single room/environment in here, we can put our room tone directly into the scene itself. We set the positional property to false, to make sure sound is heard equally throughout the room.

We also set the autoplay property to true since we don’t need user interaction to hear the room tone.

NOTE: Audio autoplay in most browsers either already require or will require user interaction to start. Which means to automatically play sounds like background music or ambient audio you need to use a menu screen or a mute/unmute button or something alike to enable audio autoplay.

Music

For the final piece of our audio puzzle, let’s add some music to our scene. We can either choose to add this as diegetic music that’s coming from the radio in our scene, or as extra-diegetic music which is non-existent in the virtual world we created, but specifically for the user/viewer/player who is experiencing and controlling this virtual world.

To do the latter, we would need to put our music either onto our camera () or to our first-person character (if that is an option) and make sure the audio is non-positional. In this scene I chose to go with the former and put the music to the radio model as a source inside the virtual world.

We can add the provided music track (composed by yours truly) to our radio model just like we added all the sounds up to this point.

Playback Control

Our music plays whenever we click on the radio, but what if we want to pause it and then play it again?

To have this functionality we need to write a custom A-Frame component. Then add that component as an HTML attribute to any object we want to add that functionality to, just like we added the “sound” component to our models before.

You can either write your A-Frame components inline, or write it in an external JavaScript file and then link to it from the html, like I did for this project.

Now we have an audio-toggle component that enables us to play and pause the sound we are hearing. It also allows us to change the autoplay ability via the “playing” property.

And that’s it! We have an A-Frame scene with music, environment sounds and interactive audio.

In the next part we will take a look at how to integrate Tone.js to an A-Frame project and writing more custom components with advanced audio functionality.

Thanks for reading!

Recently an audio clip asking listeners whether they hear the word “Yanny” or “Laurel” has been completely puzzling the world and pitting friend against friend in the online debate.

The clip and the “Yanny or Laurel” poll were posted on Instagram, Reddit, and other sites by high school students who said that it had been recorded from a vocabulary website playing through the speakers on a computer. Now hundreds of thousands of people are engaged in a debate over what they hear. It’s been driving people crazy and leading to passionate defenses on both side.

However, the magic behind this debate is quite simple. Different ears have different sensitive frequency zones for the same audio clip. Also, different speakers have different responses to different audio frequencies.

This tutorial will go through the details about how to use the Web Audio API and simple JavaScript to create to tool that will help you hear both “Yanny” and “Laurel.” Then you’ll be able to win any of those debates. :)

If you just want to try the tool, it is live HERE. Just open your browser, play the audio, and try to find the sweet spots for “Yanny” and “Laurel” while moving the frequency slider.

How it works

Let’s talk about the key part first. In order to hear the different word, you need to somehow increase the volume for a specific frequency range which depends on your ears. Luckily the Web Audio API already has something ready for us: BiquadFilterNode.

There are different types of [BiquadFilterNode](https://developer.mozilla.org/en-US/docs/Web/API/BiquadFilterNode) you can use. For this case, we will just go with the bandpass filter.

A bandpass filter is an electronic device or circuit that allows signals between two specific frequencies to pass, but that discriminates against signals at other frequencies. (source)

And for a bandpass filter, most of the time we just need to define the center frequency value we want to boost or cut, instead of the start and the end of the frequency range. We use a Q value to control the width of the frequency range. The larger the Q is, the narrower the frequency range will be. Check out Wikipedia for more details.

That’s all the knowledge we need to know at this point. Now, let’s write the code.

Web Audio API Initialization

const AudioContext = window.AudioContext || window.webkitAudioContext;

const audioContext = new AudioContext();

Create Audio Nodes along with setup and signal chain

// the audio tag in HTML, where holds the original audio clipconst audioTag = document.getElementById('audioTag');

// create audio source in web audio apiconst sourceNode =

audioContext.createMediaElementSource(audioTag);

const filterNode = audioContext.createBiquadFilter();

filterNode.type = 'bandpass'; // bandpass filterfilterNode.frequency.value = 1000 // set the center frequency

// set the gain to the frequency rangefilterNode.gain.value = 100;

// set Q value, 5 will make a fair band width for this casefilterNode.Q.value = 5;

// connect nodessourceNode.connect(filterNode);filterNode.connect(gainNode);gainNode.connect(audioContext.destination);

Sample HTML file

<!DOCTYPE html><html lang="en"><head>  <meta charset="UTF-8">  <title>Yanny vs Laurel Web Audio API</title></head><body>  <div id="container">    <audio id='audioTag' crossorigin="anonymous" src="yanny-laurel.wav" controls loop></audio>    <hr>    <input type="range" min="20" max="10000" value="20" step="1" class="slider" id="freqSlider">  </div>  <script src='script.js'></script></body></html>

Adding frequency slider UI

To make it easier to adjust the center frequency of our bandpass filter, we should add a slider to control the value.

<!DOCTYPE html><html lang="en"><head>  <meta charset="UTF-8">  <title>Yanny vs Laurel Web Audio API</title></head><body>  <div id="container">    <audio id='audioTag' src="yanny-laurel.wav" controls loop></audio>    <hr>    <input type="range" min="50" max="4000" value="1000" step="1" class="slider" id="freqSlider">    <br>    <p id="freqLabel" >Frequency: 1000 Hz</p>  </div>  <script>;    // add event listener for slider to change frequency value    slider.addEventListener('input', e => {

      filterNode.frequency.value = e.target.value;      label.innerHTML = `Frequency: ${e.target.value}Hz`;

    }, false);  <script src='script.js'></script><;/body></html>

createMediaElementSource bug in iOS Safari

I found that createMediaElementSource won't work in iOS Safari and Chrome. To solve this, you have to use createBufferSource to create an AudioBufferNode to store and play the audio instead of the HTML audio tag.
Please see the code here for more detail.

Now you made yourself a tool so you can hear both “Yanny” and “Laurel.” Just open your browser, play the audio, and try to find the sweet spot while moving the frequency slider.

If you want to just try the tool, it is live HERE.

I write code for audio and web, and play guitar on YouTube. If you want to see more stuff from me or know more about me, you can always find me on:

Website:
https://haochuan.io/

GitHub:
https://github.com/haochuan

Medium:
https://medium.com/@haochuan

YouTube: https://www.youtube.com/channel/UCNESazgvF_NtDAOJrJMNw0g