macOS Bluetooth Audio: Complete Annotated Console Log Guide

A Step-by-Step Manual for Understanding How Bluetooth Audio Works on macOS

Test Equipment

• Computer: MacBook Air (13-inch, 2018), Bluetooth 4.2

• Headphones: Bowers & Wilkins Px7 S2e Bluetooth Wireless Headphones

• Operating System: macOS

How to Capture Bluetooth Audio Logs

Step 1: Disconnect Your Bluetooth Headphones

Before you begin, make sure your Bluetooth headphones are disconnected from your Mac. You can do this by:

• Clicking the Bluetooth icon in the menu bar (top right corner of your screen)

• Finding your headphones in the list

• Clicking "Disconnect"

Alternatively, turn off your headphones completely.

Step 2: Open the Console Application

The Console app is macOS's built-in log viewer. It shows you what's happening inside your system in real-time.
Method 1 - Using Terminal:

1. Open Terminal (Applications → Utilities → Terminal)

2. Type the following command and press ENTER:

   open -a Console.app

Method 2 - Using Finder:

1. Open Finder

2. Go to Applications → Utilities

3. Double-click "Console"

Method 3 - Using Spotlight:

1. Press Command (⌘) + Space

2. Type "Console"

3. Press ENTER

Step 3: Configure the Search Filter

When Console opens, the window will be empty (streaming has not started yet).

1. Locate the search bar: Look at the top-right corner of the Console window. You'll see a search field.

2. Type "codec" into the search bar and press ENTER.

3. Change the filter type: To the left of the word "codec" in the search bar, a dropdown menu will appear. Click it and select "Message" from the list. This tells Console to search only in the message content, not in the entire log entry.

Step 4: Start Streaming Logs

In the center of the Console window toolbar, you'll see a button that says "Start streaming" (or it might show a play icon ▶). Click this button to begin capturing logs in real-time.
The Console is now watching for any system messages that contain the word "codec".

Step 5: Connect Your Bluetooth Headphones

Now, while Console is streaming logs:

1. Turn on your Bluetooth headphones (or click the Bluetooth menu bar icon and select your headphones to connect)

2. Wait a few seconds for the connection to complete

You should see log messages appearing in the Console window immediately. These messages show the entire Bluetooth audio negotiation process happening in real-time.

Step 6: Review the Captured Logs

The Console will display several log entries showing how macOS and your headphones negotiate the Bluetooth audio connection. Below is an example log with detailed explanations.

The Log: Line-by-Line Explanation

1. Device Capability Check (48 kHz Support)

default    21:33:05.750639+0100    bluetoothd    Bad48KHzCodecs: Disabling 48 KHz - Device is NOT in 48 KHz AAC allowlist

What's happening: macOS maintains an internal list of Bluetooth devices that have been tested and verified to work properly with 48 kHz audio. The Bowers & Wilkins Px7 S2e is not on this allowlist. Even if the headphones claim they support 48 kHz, macOS won't use it. This is a protective measure against devices with buggy 48 kHz implementations that could cause audio problems.
Result: Audio will be limited to 44.1 kHz (CD quality) instead of 48 kHz.

2. HFP (Hands-Free Profile) Setup - Voice Calls

default    21:33:06.121260+0100    bluetoothd    Creating HFPAudioDevice for device EC:66:D1:BF:02:05 with codec: mSBC

What's happening: While setting up music playback (A2DP profile), macOS simultaneously configures the Hands-Free Profile (HFP) for phone calls, Siri, and voice communication.
Technical details:

• Device MAC address: [font=Courier New]EC:66:D1:BF:02:05[/font] (unique identifier for these headphones)

• Voice codec: mSBC (modified Sub-Band Codec) - provides wideband speech at 16 kHz for better call quality than older 8 kHz narrowband codecs

Note: This is separate from music quality. Voice calls and music use different Bluetooth profiles and codecs.

3. Voice Codec Parsing (HFP Capabilities)

default    21:33:06.143723+0100    coreaudiod    ParseSWCodecs uwbsMono 0, uwbsStereo 0, swbMono 0, swbStereo 0, swbStereoFake 0, mStereoSupported 0

What's happening: Core Audio (macOS's audio system) is checking which advanced voice codecs the headphones support. Each "0" means "not supported", "1" would mean "supported".
Codec breakdown:

• uwbsMono/uwbsStereo = Ultra-wideband speech (mono/stereo): Not supported (0)

• swbMono/swbStereo = Super-wideband speech: Not supported (0)

• swbStereoFake = Fake stereo super-wideband: Not supported (0)

• mStereoSupported = Stereo voice calls: Not supported (0)

Translation: These headphones only support basic mono voice codecs, not the advanced high-quality or stereo voice features.

4. Available Voice Codecs Summary

default    21:33:06.145067+0100    coreaudiod    Codecs available. NBS (CVSD): 1, WBS (mSBC): 1, UWBS (AAC-ELD): 0, mSWB:0, Stereo: 0

What's happening: macOS summarizes which voice call codecs are available:

• NBS (CVSD) = Narrowband Speech: Supported (1) - Basic 8 kHz voice quality (sounds like an old phone)

• WBS (mSBC) = Wideband Speech: Supported (1) - Better 16 kHz voice quality (sounds clearer, like modern mobile phones)

• UWBS (AAC-ELD) = Ultra-wideband Speech: Not supported (0) - Premium AAC-based voice codec

• mSWB = Modified super-wideband: Not supported (0)

• Stereo voice: Not supported (0)

For calls: macOS will use mSBC (wideband) for decent call quality.

5-8. Codec Discovery (A2DP Music Profile)

default    21:33:10.270226+0100    bluetoothd    Audio Codec ID VENDOR-SPECIFIC for remote SEID 9
error    21:33:10.471543+0100    bluetoothd    Length of AVDTP Codec Info is too short for Apple Vendor-Specific Codec
default    21:33:10.471637+0100    bluetoothd    Audio Codec ID VENDOR-SPECIFIC for remote SEID 7
error    21:33:10.607426+0100    bluetoothd    Length of AVDTP Codec Info is too short for Apple Vendor-Specific Codec
default    21:33:10.607626+0100    bluetoothd    Audio Codec ID VENDOR-SPECIFIC for remote SEID 5
default    21:33:10.743925+0100    bluetoothd    Audio Codec ID MPEG-2,4 AAC for remote SEID 3
default    21:33:10.880295+0100    bluetoothd    Audio Codec ID SBC for remote SEID 1

What's happening: macOS is asking the headphones: "What music codecs do you support?" The headphones respond with a list of available codecs. Each codec has a SEID (Stream Endpoint ID) - think of it as a numbered slot.
The headphones advertise 5 codec endpoints:

• SEID 9, 7, 5: Vendor-specific codecs (likely proprietary Bowers & Wilkins audio processing features)
   

  • Error messages: These vendor codecs don't follow Apple's expected format correctly, so macOS rejects them as incompatible

• SEID 3: AAC (MPEG-2,4 AAC) - Apple's preferred high-quality music codec ✓

• SEID 1: SBC (Sub-Band Codec) - The mandatory baseline codec that all Bluetooth audio devices must support ✓

Result: Two usable music codecs: AAC and SBC. macOS will prefer AAC.

9-10. Codec Selection

default    21:33:10.880630+0100    bluetoothd    Selected preferred codec AVDTP_CODEC_MPEG_AAC (0x2) out of 5 available endpoints
default    21:33:10.880740+0100    bluetoothd    Selected preferred codec AVDTP_CODEC_MPEG_AAC (0x2) out of 5 available endpoints

What's happening: macOS chooses AAC (codec ID 0x2) as the preferred codec from the 5 available endpoints.
Why twice? This message appears twice, likely confirming the selection for both audio channels or for redundancy.
Why AAC? On macOS, AAC is always preferred over SBC when available because it provides significantly better sound quality at the same bitrate.

11-12. Vendor Codec Rejection (Confirmation)

error    21:33:10.880817+0100    bluetoothd    Length of AVDTP Codec Info is too short for Apple Vendor-Specific Codec
error    21:33:10.880892+0100    bluetoothd    Length of AVDTP Codec Info is too short for Apple Vendor-Specific Codec

What's happening: macOS confirms it's rejecting the malformed vendor-specific codecs from the headphones. These errors are harmless - they just mean the proprietary Bowers & Wilkins features aren't compatible with macOS's expectations.

13. A2DP Stream Configuration (The Main Event!)

default    21:33:11.467514+0100    bluetoothd    A2DP configured at 44.1 KHz. Codec: AAC-LC, VBR max: 244 kbps. 1 frames * (12+709) bytes = 721 per RTP (max=879) every 23.22 ms

What's happening: This is the most important line - it shows the final negotiated Bluetooth music stream configuration.
Breaking it down:

• A2DP configured at 44.1 KHz: Sample rate is 44.1 kHz (CD quality)
   

  • Remember: 48 kHz was disabled earlier because this device isn't on the allowlist

• Codec: AAC-LC: Using AAC Low Complexity profile (the standard AAC variant)

• VBR max: 244 kbps: Variable Bit Rate with a maximum of 244 kilobits per second
   

  • Note: Later logs reveal the actual encoding uses 192 kbps CBR (Constant Bit Rate), so this is just the negotiated maximum ceiling

• Frame structure:
   

  • 1 frame per RTP packet (RTP = Real-time Transport Protocol, the Bluetooth streaming format)

  • 12 bytes = RTP header overhead

  • 709 bytes = AAC-encoded audio data

  • 721 total bytes per packet (12 + 709)

  • Maximum packet size: 879 bytes (extra headroom for variable bitrate bursts)

• Timing: every 23.22 ms
   

  • Each packet contains 1024 audio samples

  • Calculation: 1024 samples ÷ 44,100 samples/second = 0.02322 seconds = 23.22 milliseconds

Translation for non-technical users: Every 23.22 milliseconds (roughly 43 times per second), your Mac sends a small packet of compressed AAC audio data (721 bytes) over Bluetooth to your headphones.

14-18. AAC Encoder Negotiation (Finding the Perfect Settings)

default    21:33:11.486010+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 1, bitrate = 128000, quality (complexity) = 64, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 0 (bits), packetBitSizeMin = 0 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0

What's happening: Core Audio doesn't just blindly use any AAC settings. It intelligently tests multiple encoder configurations to find the optimal balance between quality, latency, and Bluetooth packet size. Think of this as macOS trying on different "outfits" to see which fits best.
Test 1 - High Quality CBR:

• srIn/srOut = 44100: Input and output sample rate both 44.1 kHz (no resampling needed - bit-perfect!)

• chans = 2: Stereo (2 channels)

• bitRateFormat = 1: CBR (Constant Bit Rate)

• bitrate = 128000: 128 kbps (kilobits per second)

• quality (complexity) = 64: High CPU complexity for better encoding quality (0-127 scale)

• VBRQ = -1: VBR Quality setting not used (because this is CBR mode)

• speechOptimization = 0: Disabled (music-optimized encoding, not voice-optimized)

• packetSizeLimit = 0: No packet size limit in this test

• packetBitSizeMin = 0: No minimum packet size

• mMaxPacketSize = 1536 bytes: Maximum 1536 bytes per packet

• mCodecDelay = 2112: Encoder latency is 2112 samples
   

  • Calculation: 2112 ÷ 44,100 = 47.89 milliseconds of encoding delay

• drcConfiguration = 0: Dynamic Range Compression disabled

default    21:33:11.490819+0100    coreaudiod      ... bitRateFormat = 1, bitrate = 128000, quality (complexity) = 32 ...

Test 2 - Medium Quality CBR:

• Same as Test 1, but complexity reduced to 32 (medium)

• Lower complexity = faster encoding, uses less CPU, slightly lower quality

default    21:33:11.492162+0100    coreaudiod      ... bitRateFormat = 3, bitrate = 128000, quality (complexity) = 32 ...

Test 3 - VBR Mode:

• bitRateFormat = 3: VBR (Variable Bit Rate) - bitrate can fluctuate for better efficiency

• 128 kbps average

• Complexity 32 (medium)

default    21:33:11.493346+0100    coreaudiod      ... bitRateFormat = 3, bitrate = 128000, quality (complexity) = 32, VBRQ = -1, ... packetBitSizeMin = 256 (bits) ...

Test 4 - VBR with Minimum Packet Constraint:

• VBR mode with minimum packet size = 256 bits (32 bytes)

• This ensures packets aren't too small, which could waste Bluetooth transmission efficiency

default    21:33:11.494194+0100    coreaudiod      ... bitRateFormat = 3, bitrate = 192000, quality (complexity) = 32, ... packetSizeLimit = 5672 (bits), packetBitSizeMin = 256 (bits) ...

Test 5 - THIS IS THE WINNER! ✓

• bitRateFormat = 3: VBR (Variable Bit Rate)

• bitrate = 192000: 192 kbps average (significantly higher than the 128 kbps tests)

• quality (complexity) = 32: Balanced CPU usage

• packetSizeLimit = 5672 bits: Maximum 709 bytes per packet (5672 ÷ 8 = 709)
   

  • This matches exactly the "709 bytes" we saw in the bluetoothd configuration!

• packetBitSizeMin = 256 bits: Minimum 32 bytes per packet

Why this configuration won:

• Higher bitrate (192 kbps) = better sound quality

• VBR mode = efficient use of bandwidth (complex music passages get more bits, simple passages use fewer)

• Packet size (256-5672 bits) perfectly fits the Bluetooth MTU (Maximum Transmission Unit)

• Complexity 32 = good quality without excessive CPU usage

19-23. Encoder Reconfiguration Events

default    21:35:26.865271+0100    coreaudiod      ... (same 192 kbps VBR config)
default    21:37:35.865684+0100    coreaudiod      ... (same 192 kbps VBR config)
default    21:37:43.660216+0100    coreaudiod      ... (same 192 kbps VBR config)
default    21:38:10.692347+0100    coreaudiod      ... (same 192 kbps VBR config)
default    21:38:12.218420+0100    coreaudiod      ... (same 192 kbps VBR config)
default    21:40:55.879479+0100    coreaudiod      ... (same 192 kbps VBR config)

What's happening: These log entries show the AAC encoder being reinitialized with the same proven configuration (192 kbps VBR, complexity 32).
When does this happen?

• You start or stop music playback

• You switch between different audio apps (Spotify → Apple Music → YouTube)

• System audio routing changes

• Headphones briefly disconnect and reconnect

• macOS adjusts audio priorities

Each time, macOS reinitializes the encoder with the same optimal settings it discovered during the initial tests.

Technical Configuration

| Parameter          | Value        | Explanation                                    |
| ------------------ | ------------ | ---------------------------------------------- |
| Sample Rate        | 44.1 kHz     | CD quality; 48 kHz disabled (not on allowlist) |
| Codec              | AAC-LC       | Advanced Audio Coding - Low Complexity         |
| Bitrate            | 192 kbps CBR | Actually constant despite VBR negotiation      |
| Encoder Complexity | 32 (medium)  | Balanced CPU vs. quality                       |
| Frame Size         | 1024 samples | 23.22 ms per frame                             |
| Packet Size        | 721 bytes    | 12-byte header + 709-byte AAC data             |
| Codec Delay        | 2112 samples | ~48 ms encoder latency                         |

The Process macOS Follows

1. Check device allowlist → Disable 48 kHz (device not approved)

2. Set up voice profile (HFP) → Use mSBC for calls

3. Discover available codecs → Find AAC and SBC

4. Select preferred codec → Choose AAC over SBC

5. Negotiate stream parameters → 44.1 kHz, VBR max 244 kbps

6. Test encoder configurations → Try 5 different settings

7. Select optimal configuration → 192 kbps VBR, complexity 32

8. Stream audio → Send 721-byte packets every 23.22 ms

A Note on Sound Quality

It may be worth noting that, when using the same Bluetooth headphones, the sound quality on macOS is rather better than on Linux. Not enormously so, you understand, but one might say the difference is... perceptible to the discerning ear.
Both systems use AAC encoding over Bluetooth, both operate at 44.1 kHz, and both follow broadly similar technical processes. Yet the macOS implementation does seem to possess a certain refinement in its execution - perhaps in the encoder's architectural elegance, or in the rather more sophisticated manner in which Core Audio handles the signal path.
It's rather like comparing motorcars, really. A Toyota and a Rolls-Royce both have four wheels, an engine, and a steering wheel. Both will convey you from point A to point B. The fundamental principles are identical. Yet one wouldn't claim the experience is quite the same, would one?
The quality, as they say, is in the details of the realisation.

On Linux with BlueALSA:

• You cannot force 320 kbps VBR or CBR - the bitrate is negotiated between the system and the headphones

• Getting detailed logs like these requires modifying the BlueALSA source code with debug statements and recompiling the daemon

• Both 44.1 kHz and 48 kHz are typically available (no allowlist restrictions)

• You can request the AAC "afterburner" mode for maximum encoder quality using the [font=Courier New]--aac-afterburner[/font] flag

On macOS:

• Logging is built-in via Console.app - no compilation required

• The system automatically tests and selects optimal encoder settings

• Device allowlists protect against buggy hardware implementations

• The Core Audio architecture provides a cleaner signal path

This guide was created by capturing real Bluetooth connection logs and analyzing the internal behavior of macOS's Bluetooth audio stack.

default    21:33:05.750639+0100    bluetoothd    Bad48KHzCodecs: Disabling 48 KHz - Device is NOT in 48 KHz AAC allowlist
default    21:33:06.121260+0100    bluetoothd    Creating HFPAudioDevice for device EC:66:D1:BF:02:05 with codec: mSBC
default    21:33:06.143723+0100    coreaudiod    ParseSWCodecs uwbsMono 0, uwbsStereo 0, swbMono 0, swbStereo 0, swbStereoFake 0, mStereoSupported 0
default    21:33:06.145067+0100    coreaudiod    Codecs available. NBS (CVSD): 1, WBS (mSBC): 1, UWBS (AAC-ELD): 0, mSWB:0, Stereo: 0
default    21:33:10.270226+0100    bluetoothd    Audio Codec ID VENDOR-SPECIFIC for remote SEID 9
error    21:33:10.471543+0100    bluetoothd    Length of AVDTP Codec Info is too short for Apple Vendor-Specific Codec
default    21:33:10.471637+0100    bluetoothd    Audio Codec ID VENDOR-SPECIFIC for remote SEID 7
error    21:33:10.607426+0100    bluetoothd    Length of AVDTP Codec Info is too short for Apple Vendor-Specific Codec
default    21:33:10.607626+0100    bluetoothd    Audio Codec ID VENDOR-SPECIFIC for remote SEID 5
default    21:33:10.743925+0100    bluetoothd    Audio Codec ID MPEG-2,4 AAC for remote SEID 3
default    21:33:10.880295+0100    bluetoothd    Audio Codec ID SBC for remote SEID 1
default    21:33:10.880630+0100    bluetoothd    Selected preferred codec AVDTP_CODEC_MPEG_AAC (0x2) out of 5 available endpoints
default    21:33:10.880740+0100    bluetoothd    Selected preferred codec AVDTP_CODEC_MPEG_AAC (0x2) out of 5 available endpoints
error    21:33:10.880817+0100    bluetoothd    Length of AVDTP Codec Info is too short for Apple Vendor-Specific Codec
error    21:33:10.880892+0100    bluetoothd    Length of AVDTP Codec Info is too short for Apple Vendor-Specific Codec
default    21:33:11.467514+0100    bluetoothd    A2DP configured at 44.1 KHz. Codec: AAC-LC, VBR max: 244 kbps. 1 frames * (12+709) bytes = 721 per RTP (max=879) every 23.22 ms
default    21:33:11.486010+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 1, bitrate = 128000, quality (complexity) = 64, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 0 (bits), packetBitSizeMin = 0 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0
default    21:33:11.490819+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 1, bitrate = 128000, quality (complexity) = 32, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 0 (bits), packetBitSizeMin = 0 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0
default    21:33:11.492162+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 3, bitrate = 128000, quality (complexity) = 32, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 0 (bits), packetBitSizeMin = 0 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0
default    21:33:11.493346+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 3, bitrate = 128000, quality (complexity) = 32, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 0 (bits), packetBitSizeMin = 256 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0
default    21:33:11.494194+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 3, bitrate = 192000, quality (complexity) = 32, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 5672 (bits), packetBitSizeMin = 256 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0
default    21:35:26.865271+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 3, bitrate = 192000, quality (complexity) = 32, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 5672 (bits), packetBitSizeMin = 256 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0

default    21:37:35.865684+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 3, bitrate = 192000, quality (complexity) = 32, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 5672 (bits), packetBitSizeMin = 256 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0
default    21:37:43.660216+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 3, bitrate = 192000, quality (complexity) = 32, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 5672 (bits), packetBitSizeMin = 256 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0
default    21:38:10.692347+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 3, bitrate = 192000, quality (complexity) = 32, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 5672 (bits), packetBitSizeMin = 256 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0
default    21:38:12.218420+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 3, bitrate = 192000, quality (complexity) = 32, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 5672 (bits), packetBitSizeMin = 256 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0
default    21:40:55.879479+0100    coreaudiod      ACMP4AACBaseEncoder.cpp:692   (0x7fb47f97dc40) @@@@ 'aac ' encoder configuration: srIn = 44100, srOut = 44100, chans = 2, bitRateFormat = 3, bitrate = 192000, quality (complexity) = 32, VBRQ = -1, speechOptimization = 0, packetSizeLimit = 5672 (bits), packetBitSizeMin = 256 (bits), mMaxPacketSize = 1536 (bytes), userBandwidth = 0, delayMode = 0, mCodecDelay = 2112, drcConfiguration = 0, mPrePostFillMask = 0x0

An amusing discovery emerged during this research: both the Bowers & Wilkins Px7 S2e and Sennheiser HD 450BT work perfectly well on macOS—they connect, they play audio, users remain blissfully unaware of any limitation. Yet according to macOS's own logs, these devices are not supported. They are excluded from the 48 kHz AAC allowlist, relegated to 44.1 kHz like common peasants.
Which headphones, then, enjoy this privilege? The answer is as predictable as it is illuminating: Beats.
Apple acquired Beats Electronics for $3 billion in 2014. Since then, Beats headphones have shipped with Apple's proprietary wireless chips—the W1, H1, and now H2. These chips are not merely Bluetooth transceivers; they are trusted devices in the macOS ecosystem.
Headphones with H1/W1/H2 chips receive preferential treatment from bluetoothd:

• 48 kHz AAC support (others are capped at 44.1 kHz)

• Likely higher bitrates than standard AAC-LC

• Optimized audio pipeline routing

• Possibly lower latency

The chips almost certainly maintain persistent encrypted connections, use custom pairing protocols beyond standard Bluetooth, and report extended capabilities that trigger allowlist matching against hardcoded device IDs.

Apple's Rationale

1. Quality Control – They know their chips handle 48 kHz reliably

2. Battery & Stability – Guaranteed experience without edge-case failures

3. Product Differentiation – A tangible reason to buy within the ecosystem

4. Ecosystem Lock-in – Yet another thread in the web

The goal is transparent: the best Bluetooth audio quality on macOS shall be delivered by Beats headphones and AirPods. The Apple audio engineers are perfectly capable of implementing this. They have simply chosen to do so exclusively for their own products.
The so-called "Bluetooth audiophiles" often insist that Beats are inferior to Sennheiser, Bowers & Wilkins, and their ilk. One might safely disregard such opinions with the same confidence one dismisses the pronouncements of fast food connoisseurs on any cuisine.

Summary

On macOS, you are graciously invited to remain within the Apple ecosystem—that is, to consume Apple products exclusively for optimal functionality.
On Linux, you are similarly encouraged to remain within the Linux ecosystem—that is, to use systemd, PulseAudio, PipeWire, ALSA, and whichever resampler happens to be fashionable this quarter, whether you like them or not.
The difference, modest though it may be, is this: on Linux, it remains possible to remove systemd, PulseAudio, and PipeWire, and enjoy the true freedom—the freedom to trust your senses and your ability to think, to understand and to solve problems.

BlueALSA is already configured and ready to use. The ALSA configuration file for BlueALSA is located at:

/usr/share/alsa/alsa.conf.d/20-bluealsa.conf  

$ dpkg -S /usr/share/alsa/alsa.conf.d/20-bluealsa.conf
bluez-alsa:amd64: /usr/share/alsa/alsa.conf.d/20-bluealsa.conf

This file contains optimal default settings that work for most users. These have been carefully selected to deliver the best performance. As audio quality is not a primary concern for Linux developers, you may wish to adjust some of the default settings.

What's Already Configured

The system already defines:

• pcm.bluealsa - The main Bluetooth audio device.

• ctl.bluealsa - Mixer controls for Bluetooth devices.

Note that pcm.bluealsa is a virtual PCM device, not a full virtual sound card. As such, it does not support direct use of ALSA plugins like dmix, dsnoop, or asym to enable software mixing or concurrent access. BlueALSA PCM devices are designed for direct Bluetooth audio streaming and lack built-in multi-client capabilities — only one application can use the PCM at a time.

Optimal Configuration for AAC codec

Here is the complete optimal configuration for AAC codec. Put this in ~/.asoundrc:

# File: ~/.asoundrc  
defaults.pcm.rate_converter "fftrate"  
defaults.bluealsa.ctl.extended "yes"
defaults.bluealsa.softvol "off"  
defaults.bluealsa.codec "aac"   
pcm.!default "bluealsa"

What These Settings Do

• defaults.pcm.rate_converter "fftrate" - Uses high-quality sample rate conversion

• defaults.bluealsa.ctl.extended "yes" - Shows which codec is actually being used

• defaults.bluealsa.codec "aac" - Forces AAC codec for best quality

• pcm.!default "bluealsa" - Makes Bluetooth audio the system default

If you open alsamixer for the BlueALSA virtual PCM device:

alsamixer -D bluealsa

you will see codec controls like:

• AAC Codec Enum - Shows the currently selected AAC codec

• Volume Mode - Switch between "pass-through" and "software"

• Sync - Client delay adjustment

• Battery - Device battery level (if supported)

The codec control lets you verify your defaults.bluealsa.codec "aac" setting is working
The following default settings work well and don't need to be changed:

• Volume mode: 'pass-through' (uses device's native volume control)

• Delay: +0 ms (no extra delay added)

These settings are already optimal for most users.

Important: Do not load aptX or aptX-HD codecs in bluealsad, if you intend to use the AAC codec exclusively.
This ensures only AAC (and mandatory SBC) codecs are available for a2dp playback, as SBC codec cannot be disabled — it is required by the A2DP specification and is always enabled by default in BlueALSA.
To run bluealsad from the terminal, use:

sudo -u bluealsad bluealsad -p a2dp-source -p a2dp-sink -p hfp-ag -p hfp-hf -c -sbc -c aac -c msbc --aac-afterburner --aac-bitrate=320000 --aac-vbr --aac-true-bps  

In the init script /etc/init.d/bluealsad, configure the options accordingly:

BA_OPTS="-S -p a2dp-source -p a2dp-sink -p hfp-ag -p hfp-hf -c -sbc -c aac -c msbc --aac-afterburner --aac-bitrate=320000 --aac-vbr --aac-true-bps"

This configuration avoids codec conflicts and ensures reliable AAC usage.

How BlueALSA Handles Sample Rates (Bit Perfect)

BlueALSA does not perform resampling. When sample rate conversion is required (e.g., from DXD to 48 kHz), it is handled by ALSA using the configured resampler — such as fftrate:

$ cat ~/.asoundrc | grep rate
defaults.pcm.rate_converter "fftrate"

Since the AAC codec supports both 44.1 kHz and 48 kHz, no resampling is needed, and BlueALSA preserves the original sample rate — a concept often referred to as "bit perfect" in macOS contexts. The default BlueALSA configuration avoids unnecessary audio processing that could degrade sound quality.
When your audio player changes sample rates (e.g., from 48 kHz to 44.1 kHz), BlueALSA automatically renegotiates the connection with the Bluetooth device to match the new rate.

How to configure media applications

Note that it is generally not possible to disable resampling in Chromium-based browsers.

MPV Player 

$ cat ~/.config/mpv/mpv.conf
ao=alsa
alsa-resample=yes
alsa-buffer-time=160000
alsa-periods=4

Celluloid:

• Open the Preferences menu.

• Go to the Miscellaneous tab.

• Enter mpv command-line options into the "Extra MPV Options" text box:

ao=alsa alsa-resample=yes alsa-buffer-time=160000 alsa-periods=4

Audacious:

• go to Preferences → Audio → Buffer size

• set 2000 ms

aplay and arecord

aplay -F 40000 -B 160000 input.wav
arecord -F 40000 -B 160000  -V mono -f CD output.wav

Firefox
about:config

media.mediasource.webm.enabled                false
media.cubeb.backend                           alsa
media.resampling.enabled                      false
media.cubeb_latency_playback_ms               160

Configuration Editor for Firefox 
_https://support.mozilla.org/en-US/kb/about-config-editor-firefox

# COMMAND: Start BlueALSA with AAC codec and debug logging  
sudo -u bluealsad bluealsad -p a2dp-source -p a2dp-sink -p hfp-ag -p hfp-hf -c -sbc -c aac -c msbc --aac-afterburner --aac-bitrate=320000 --aac-vbr --aac-true-bps --loglevel=debug  

# DAEMON INITIALIZATION  
bluealsad: [31361] D: log.c:701: FDK-AAC encoder capabilities: AAC=[AAC-LC AAC-SCAL DRC ] SBR=[SBR-PS ] DMX=[none]  
bluealsad: [31361] D: log.c:701: FDK-AAC decoder capabilities: AAC=[AAC-LC HE-AAC AAC-LD AAC-ELD AAC-SCAL DRC ] SBR=[SBR-HQ SBR-PS ] DMX=[2ch 6ch 8ch ]  
bluealsad: [31361] D: storage.c:86: Initializing persistent storage: /var/lib/bluealsa  
bluealsad: [31361] D: main.c:707: Starting main dispatching loop  
bluealsad: [31361] D: main.c:121: Acquired D-Bus service name: org.bluealsa  
bluealsad: [31361] D: bluealsa-dbus.c:404: Registering BlueALSA D-Bus manager: /org/bluealsa  

# AAC CODEC DISCOVERY  
bluealsad: [31361] D: bluez.c:1271: Adding new Stream End-Point: EC:66:D1:BF:02:05: SNK: AAC  
bluealsad: [31361] D: log.c:347: AAC_CODEC: AAC capabilities - Object Type=MPEG2-LC | MPEG4-LC, Sample Rate=8000 Hz | 11025 Hz | 12000 Hz | 16000 Hz | 22050 Hz | 24000 Hz | 32000 Hz | 44100 Hz | 48000 Hz, Channels=Mono | Stereo, VBR=enabled, Bitrate=320000  

# AAC CODEC NEGOTIATION  
bluealsad: [31361] D: dbus.c:43: Called: org.bluez.MediaEndpoint1.SelectConfiguration() on /org/bluez/hci0/A2DP/AAC/source/1  
bluealsad: [31361] D: bluez.c:442: BlueZ endpoint select_configuration called  
bluealsad: [31361] D: log.c:347: AAC_CODEC: _CODEC: A2DP peer capabilities - Object Type=MPEG2-LC | MPEG4-LC, Sample Rate=8000 Hz | 11025 Hz | 12000 Hz | 16000 Hz | 22050 Hz | 24000 Hz | 32000 Hz | 44100 Hz | 48000 Hz, Channels=Mono | Stereo, VBR=enabled, Bitrate=320000  
bluealsad: [31361] D: a2dp-aac.c:664: AAC configuration_select called  
bluealsad: [31361] D: dbus.c:43: Called: org.bluez.MediaEndpoint1.SetConfiguration() on /org/bluez/hci0/A2DP/AAC/source/1  
bluealsad: [31361] D: log.c:347: AAC_CODEC: A2DP selected configuration - Object Type=MPEG4-LC, Sample Rate=48000 Hz, Channels=Stereo (2), VBR=enabled, Bitrate=320000  
bluealsad: [31361] D: bluez.c:637: A2DP Source (AAC) configured for device EC:66:D1:BF:02:05  
bluealsad: [31361] D: bluez.c:640: PCM configuration: channels=2 rate=48000  
bluealsad: [31361] D: bluez.c:642: Delay reporting: unsupported  

# AUDIO STREAMING SETUP  
bluealsad: [31401] D: dbus.c:43: Called: org.bluealsa.PCM1.Open() on /org/bluealsa/hci0/dev_EC_66_D1_BF_02:05/a2dpsrc/sink  
bluealsad: [31401] D: ba-transport.c:316: New A2DP transport: 28  
bluealsad: [31401] D: ba-transport.c:317: A2DP socket MTU: 28: R:672 W:895  
bluealsad: [31361] D: ba-transport.c:1082: Starting transport: A2DP Source (AAC)  
bluealsad: [31361] D: ba-transport-pcm.c:287: Created BT socket duplicate: [28]: 29  
bluealsad: [31361] D: ba-transport-pcm.c:366: Created new IO thread [ba-a2dp-aac]: A2DP Source (AAC)  
bluealsad: [31419] D: a2dp-aac.c:332: AAC_CODEC: Encoder Info - FrameLength=1024, InputChannels=2, MaxOutBufBytes=1536, Delay=1600 samples  
bluealsad: [31419] D: a2dp-aac.c:336: AAC_CODEC: Configuration - Bitrate=320000, Afterburner=enabled, VBR=enabled, Quality=VBR  
bluealsad: [31419] D: a2dp-aac.c:391: PCM IO loop: START: a2dp_aac_enc_thread: A2DP Source (AAC) 

# AAC Frame Monitoring
bluealsad: [31419] D: a2dp-aac.c:419: AAC_CODEC: Frame - Output bytes=497, Target bitrate=320000
bluealsad: [31419] D: a2dp-aac.c:419: AAC_CODEC: Frame - Output bytes=496, Target bitrate=320000
bluealsad: [31419] D: a2dp-aac.c:419: AAC_CODEC: Frame - Output bytes=600, Target bitrate=320000
bluealsad: [31419] D: a2dp-aac.c:419: AAC_CODEC: Frame - Output bytes=469, Target bitrate=320000 

Command Line Options

sudo -u bluealsad bluealsad -p a2dp-source -p a2dp-sink -p hfp-ag -p hfp-hf -c -sbc -c aac -c msbc --aac-afterburner --aac-bitrate=320000 --aac-vbr --aac-true-bps --loglevel=debug

• sudo -u bluealsad: Runs the daemon under a dedicated user—nothing excessive, just sound security practice.

• -p a2dp-source -p a2dp-sink: Enables bidirectional audio. One might call it thorough.

• -p hfp-ag -p hfp-hf: Supports hands-free calling. Useful, if one must.

• -c aac: Enables the AAC codec—rather more refined than the alternatives.

• --aac-afterburner: Activates Fraunhofer’s quality enhancement. It does its work quietly.

• --aac-bitrate=320000: Sets a generous bitrate. One might say it leaves nothing wanting.

• --aac-vbr: Prefers variable bit rate—efficient without being showy.

• --aac-true-bps: Ensures accurate bit-per-second reporting. A minor detail, but a correct one.

• --loglevel=debug: Enables verbose logging. Helpful, if one is inclined to look.

NOTE: To enable debug, you have to compile bluez-alsa with --enable-debug. Then you can run bluealsad daemon with --loglevel=debug.

Security:

./configure --with-bluealsaduser=bluealsad       # D-Bus policy files are automatically generated with the correct user permissions

Running BlueALSA as the bluealsad user is not an indulgence—it is a matter of principle. The daemon operates with minimal privileges, should anything untoward occur.

• Least Privilege: The bluealsad user has no unnecessary access. One might say it knows its place.

• Systemd Sandboxing: Features such as ProtectSystem=strict and IPAddressDeny=any ensure the service remains discreet.

• D-Bus Policy Control: Communication is limited to org.bluealsa. No eavesdropping, no surprises.

• Filesystem Confinement: The daemon is restricted to /var/lib/bluealsa. One might call it tidy.

This is not paranoia—it is simply good form.

Daemon Startup Process

# FDK-AAC library capabilities - what audio formats we can encode/decode  
bluealsad: [31361] D: log.c:701: FDK-AAC encoder capabilities: AAC=[AAC-LC AAC-SCAL DRC ] SBR=[SBR-PS ] DMX=[none]  
bluealsad: [31361] D: log.c:701: FDK-AAC decoder capabilities: AAC=[AAC-LC HE-AAC AAC-LD AAC-ELD AAC-SCAL DRC ] SBR=[SBR-HQ SBR-PS ] DMX=[2ch 6ch 8ch ]

EXPLANATION: BlueALSA checks what AAC formats your system supports. The encoder can handle basic AAC-LC and scalable coding, while the decoder supports advanced formats like HE-AAC for better compression.

# System initialization  
bluealsad: [31361] D: storage.c:86: Initializing persistent storage: /var/lib/bluealsa  
bluealsad: [31361] D: main.c:707: Starting main dispatching loop  
bluealsad: [31361] D: main.c:121: Acquired D-Bus service name: org.bluealsa  
bluealsad: [31361] D: bluealsa-dbus.c:404: Registering BlueALSA D-Bus manager: /org/bluealsa

EXPLANATION: BlueALSA starts up, creates storage for remembering device settings, and registers with the Linux D-Bus system so applications can communicate with it.

AAC Codec Discovery

# Device announces its AAC support  
bluealsad: [31361] D: bluez.c:1271: Adding new Stream End-Point: EC:66:D1:BF:02:05: SNK: AAC  
bluealsad: [31361] D: log.c:347: AAC_CODEC: AAC capabilities - Object Type=MPEG2-LC | MPEG4-LC, Sample Rate=8000 Hz | 11025 Hz | 12000 Hz | 16000 Hz | 22050 Hz | 24000 Hz | 32000 Hz | 44100 Hz | 48000 Hz, Channels=Mono | Stereo, VBR=enabled, Bitrate=320000

EXPLANATION:  The Bluetooth device, that is, BT Headphones, EC:66:D1:BF:02:05 tells BlueALSA it supports AAC audio. It can handle many sample rates from 8kHz (voice quality) up to 48kHz (CD quality), supports mono and stereo, and can use Variable Bit Rate for efficient encoding.

AAC Codec Negotiation

# BlueZ asks BlueALSA to select the best AAC configuration  
bluealsad: [31361] D: dbus.c:43: Called: org.bluez.MediaEndpoint1.SelectConfiguration() on /org/bluez/hci0/A2DP/AAC/source/1  
bluealsad: [31361] D: bluez.c:442: BlueZ endpoint select_configuration called  
bluealsad: [31361] D: log.c:347: AAC_CODEC: _CODEC: A2DP peer capabilities - Object Type=MPEG2-LC | MPEG4-LC, Sample Rate=8000 Hz | 11025 Hz | 12000 Hz | 16000 Hz | 22050 Hz | 24000 Hz | 32000 Hz | 44100 Hz | 48000 Hz, Channels=Mono | Stereo, VBR=enabled, Bitrate=320000  
bluealsad: [31361] D: a2dp-aac.c:664: AAC configuration_select called

EXPLANATION: The Bluetooth system (BlueZ) asks BlueALSA to choose the best AAC settings. BlueALSA looks at what the device (that is, BT Headphones) supports and selects optimal parameters.

# Final configuration is selected and applied  
bluealsad: [31361] D: dbus.c:43: Called: org.bluez.MediaEndpoint1.SetConfiguration() on /org/bluez/hci0/A2DP/AAC/source/1  
bluealsad: [31361] D: log.c:347: AAC_CODEC: A2DP selected configuration - Object Type=MPEG4-LC, Sample Rate=48000 Hz, Channels=Stereo (2), VBR=enabled, Bitrate=320000  
bluealsad: [31361] D: bluez.c:637: A2DP Source (AAC) configured for device EC:66:D1:BF:02:05  
bluealsad: [31361] D: bluez.c:640: PCM configuration: channels=2 rate=48000  
bluealsad: [31361] D: bluez.c:642: Delay reporting: unsupported

EXPLANATION: BlueALSA selects the best quality settings: MPEG4-LC at 48kHz stereo with 320kbps VBR. This provides near-CD quality audio. The PCM is configured to match these settings.

Audio Streaming Setup

# Application requests to play audio  
bluealsad: [31401] D: dbus.c:43: Called: org.bluealsa.PCM1.Open() on /org/bluealsa/hci0/dev_EC_66_D1_BF_02:05/a2dpsrc/sink  
bluealsad: [31401] D: ba-transport.c:316: New A2DP transport: 28  
bluealsad: [31401] D: ba-transport.c:317: A2DP socket MTU: 28: R:672 W:895

EXPLANATION: An application (like mpv) asks to play audio through the Bluetooth device. BlueALSA creates a transport channel with MTU (Maximum Transmission Unit) settings for efficient data transfer.

# Audio encoding starts  
bluealsad: [31361] D: ba-transport.c:1082: Starting transport: A2DP Source (AAC)  
bluealsad: [31361] D: ba-transport-pcm.c:287: Created BT socket duplicate: [28]: 29  
bluealsad: [31361] D: ba-transport-pcm.c:366: Created new IO thread [ba-a2dp-aac]: A2DP Source (AAC)  
bluealsad: [31419] D: a2dp-aac.c:332: AAC_CODEC: Encoder Info - FrameLength=1024, InputChannels=2, MaxOutBufBytes=1536, Delay=1600 samples  
bluealsad: [31419] D: a2dp-aac.c:336: AAC_CODEC: Configuration - Bitrate=320000, Afterburner=enabled, VBR=enabled, Quality=VBR  
bluealsad: [31419] D: a2dp-aac.c:391: PCM IO loop: START: a2dp_aac_enc_thread: A2DP Source (AAC)  
bluealsad: [31361] D: ba-transport-pcm.c:473: PCM resume: 24

EXPLANATION: BlueALSA starts the audio encoding process. It creates a dedicated thread for AAC encoding, with 1024-sample frames, 2-channel stereo input, and the afterburner enhancement enabled. The encoder is now ready to convert your audio into AAC format for Bluetooth transmission.

AAC Frame Monitoring

# AAC Frame Monitoring
bluealsad: [31419] D: a2dp-aac.c:419: AAC_CODEC: Frame - Output bytes=497, Target bitrate=320000
bluealsad: [31419] D: a2dp-aac.c:419: AAC_CODEC: Frame - Output bytes=496, Target bitrate=320000
bluealsad: [31419] D: a2dp-aac.c:419: AAC_CODEC: Frame - Output bytes=600, Target bitrate=320000
bluealsad: [31419] D: a2dp-aac.c:419: AAC_CODEC: Frame - Output bytes=469, Target bitrate=320000

The AAC frame monitoring shows the real-time encoding efficiency of the  Fraunhofer AAC encoder as it processes audio for Bluetooth transmission.
Each line represents one AAC audio frame that has been encoded from PCM audio data. The varying output bytes (469-600) demonstrate the Variable Bit Rate (VBR) encoding at work:

• Target bitrate=320000: The configured maximum bitrate of 320 kbps for high-quality audio.

• Output bytes variation: Shows VBR efficiency - simpler audio passages use fewer bytes (469), complex passages use more (600)

• Real-time monitoring: Each frame is logged as it's encoded in the a2dp_aac_enc_thread (a2dp-aac.c)

The real-time monitoring reveals how AAC intelligently allocates bandwidth based on audio complexity, unlike fixed-bitrate codecs that waste data on simple passages. The afterburner enhancement you enabled further optimizes this process for better audio quality. The frame-by-frame variation is quite normal and indicates the encoder is working rather efficiently, adapting to the musical content as it processes each segment of audio.

• The real-time monitoring appears only when --loglevel=debug is enabled

• The byte variations are typical for VBR encoding with afterburner enabled

• Each frame represents approximately 1024 samples of audio data

• The actual transmission rate averages around the target 320 kbps over time

Notes

This simplified log illustrates the full Bluetooth audio pipeline — from daemon startup to active streaming — with a focus on AAC codec negotiation and configuration. It demonstrates how BlueALSA serves as a bridge between Linux applications and Bluetooth audio devices, handling codec discovery, negotiation, and real-time encoding with quiet efficiency.

ALSA configuration for BlueALSA virtual PCM with AAC codec

$ cat ~/.asoundrc
defaults.pcm.rate_converter "fftrate"
defaults.bluealsa.codec "aac" 
pcm.!default "bluealsa"

BlueALSA Commands

bluealsactl codec $(bluealsactl list-pcms | grep a2dpsrc | head -1) aac

$ bluealsactl codec $(bluealsactl list-pcms | grep a2dpsrc | head -1) 
Available codecs: SBC AAC
Selected codec: AAC

BlueALSA preserves the original sample rate when:

• The source audio is 44.1kHz or 48kHz (the A2DP mandatory rates)

• The Bluetooth receiver supports the same rate

When resampling is needed (e.g., DXD to 48kHz), it is performed by the default ALSA resampler (now fftrate)

Command for Real-Time Sample Rate Monitoring

$ bluecodec
Selected: AAC:40008484e200
MPEG-2,4 AAC <hex:40008484e200> {
  Object Type ( MPEG4-LC )
  Dynamic Range Control ( false )
  Sample Rate ( 48000 Hz )
  Channel Mode ( Stereo )
  VBR ( true )
  Bitrate ( 320000 )
}

$ bluecodec
Selected: AAC:40010484e200
MPEG-2,4 AAC <hex:40010484e200> {
  Object Type ( MPEG4-LC )
  Dynamic Range Control ( false )
  Sample Rate ( 44100 Hz )
  Channel Mode ( Stereo )
  VBR ( true )
  Bitrate ( 320000 )
}

bluecodec() {
    local pcm=$(bluealsactl list-pcms | grep a2dpsrc | head -1)
    local codec=$(bluealsactl --verbose codec "$pcm" | grep "Selected codec" | awk '{print $3}')
    echo "Selected: $codec"
    a2dpconf "$codec"
}

Technical Details

BlueALSA preserves native sample rates because the D-Bus API exposes the actual PCM rate property, and the A2DP specification mandates support for 44.1kHz and 48kHz rates . When source and sink support the same rate, no resampling occurs, maintaining optimal audio quality.
The bluecodec function provides real-time visibility into the actual negotiated configuration, showing whether BlueALSA is transmitting at 44.1kHz, 48kHz, or other supported rates based on the codec capabilities and device compatibility.

On Afterburner and CPU Usage

$ man bluealsad | grep afterburner -A2
       --aac-afterburner
              Enables  Fraunhofer  AAC afterburner feature, which is a type of analysis by synthesis algorithm.  This
              feature increases the audio quality at the cost of increased processing power and overall  memory  con‐
              sumption.

$ cat bluez-alsa-4.3.1-86/src/ba-config.c | grep ENABLE_AAC -A21
#if ENABLE_AAC
    /* There are two issues with the afterburner: a) it uses a LOT of power,
     * b) it generates larger payload. These two reasons are good enough to
     * not enable afterburner by default. */
    .aac_afterburner = false,
    /* By default try not to not use the VBR mode. Please note, that for A2DP
     * sink the VBR mode might still be used if the connection is initialized
     * by a remote BT device. */
    .aac_prefer_vbr = false,
    /* Do not enable true "bit per second" bit rate by default because it
     * violates A2DP AAC specification. */
    .aac_true_bps = false,
    /* For CBR mode the 220 kbps bitrate should result in an A2DP frame equal
     * to 651 bytes. Such frame size should fit within writing MTU of most BT
     * headsets, so it will prevent RTP fragmentation which seems not to be
     * supported by every BT headset out there. */
    .aac_bitrate = 220000,
    /* Use newer LATM syntax by default. Please note, that some older BT
     * devices might not understand this syntax, so for them it might be
     * required to use LATM version 0 (ISO-IEC 14496-3 (2001)). */
    .aac_latm_version = 1,
#endif

The BlueALSA documentation suggests the afterburner “uses a LOT of power.” In practice, testing on an Intel Core i3-3220 (2012) shows average CPU usage of 3.47%, peaking at 6% during playback. One might conclude that the concern is, at best, a trifle overblown.
Tested with:
ASUS USB-BT540 Bluetooth 5.4 Dongle Adapter Compatible with Linux 
Sennheiser HD 450BT Bluetooth Wireless Headphones
Bowers & Wilkins Px7 S2e Bluetooth Wireless Headphones

Sound Quality

AAC over Bluetooth isn’t Hi-Res by any stretch, but with afterburner and VBR at 320 kbps, it delivers transparent, near-CD quality for most listeners. The afterburner enhances perceptual quality through analysis-by-synthesis — it does work rather well. It won’t satisfy a true audiophile, but for the average person, it’s perfectly acceptable.
With AAC, BlueALSA delivers proper AAC sound quality. If you’re unsure what that means, try it yourself using Firefox and YouTube.
Step 1: Disable WebM support in Firefox (media.mediasource.webm.enabled = false). 
Step 2: Play a high-quality AAC audio source, such as: 
Robert de Visée – Prélude et Allemande (Jonas Nordberg, theorbo) on YouTube: _https://youtu.be/qeUcGD4rRRc

Advanced Audio Coding
_https://en.wikipedia.org/wiki/Advanced_Audio_Coding

The FDK-AAC licence

The FDK-AAC codec is open source under a permissive copyright licence that grants broad rights—allowing free redistribution, requiring source availability for binaries, permitting modifications with attribution, and imposing no royalty fees. However, it does not convey patent rights; separate licences are necessary for commercial use.

$ cat fdk-aac/NOTICE 
...
AAC-ELD is considered the best-performing full-bandwidth communications codec 
by independent studies and is widely deployed. AAC has been standardized by ISO 
and IEC as part of the MPEG specifications.

BlueALSA Logging: A Modest Affair

BlueALSA's default logging maintains a certain reserve - quite minimal by design, you see. The logging system resides in src/shared/log.c  with corresponding declarations in src/shared/log.h

The Current Situation

By default, BlueALSA rather keeps to itself with basic error and warning messages. The debug macros are quite simply disabled in release builds:

#define debug(M, ...) do {} while (0)

Rather tidy, though perhaps not terribly informative when things go awry.

Adding Comprehensive Logging

Should one wish for more verbose output, it's really not such a tremendous undertaking. The framework is already there - one merely
needs to sprinkle debug() statements about the codebase:

debug("Transport state changed: %s", state_name);  
debug("Codec negotiation: %s selected", codec_name);

The debug system handles the niceties - thread safety, priority filtering, and rather useful timestamps when built with --enable-debug-time.

A Matter of Compilation

Of course, one must remember to compile with debugging support:

./configure --enable-debug  
make

Quite straightforward, really. The system then provides rather detailed output including file locations, thread IDs, and relative timing .

Notes

The understated approach to default logging keeps BlueALSA rather quiet in normal operation, though the comprehensive debug framework means adding detailed logging is merely a matter of adding a few well-placed statements here and there. Not terribly difficult, as these things go.