I’ve got a BTD 600 usb bluetooth adapter and I’m trying to connect Sennheiser Momentum 4 headphones. Same manufacturer.

When I plug the BTD 600 usb adapter into a windows machine it works as expected:

  • The LEDs start off white, indicating “calls” mode. (The device is transmitting a low-latency high-compression signal. The quality is terrible, but there’s very little lag)

  • As soon as I play music or youtube video or some form of audio, the LEDs on the usb adapter change to purple, indicating “aptX” mode. Audio is clear and there is little latency. The adapter remains in call mode indefinitely (or until I make a call of some sort, which I haven’t tested)

I’ve even tested this out successfully with a steam deck. It works fine, so I know it can work on linux. However, on my Pop_OS! cinnamon desktop I have issues. Upon plugging the BTD 600 usb adapter into Pop cinnamon:

  • The LEDs start off white, and remain white no matter what audio is playing. The device is stuck in “calls” mode; audio quality is terrible (though there is very little lag).

I did some research and found terms like “pulseaudio” and “pipewire” and realized those seem tied to the desktop environment. So, I logged out of Pop_OS! cinnamon and logged in to Pop_OS! Pop (its default desktop environment). Lo and behold, the BTD 600 could “see” audio was being played and switched from “call” mode to “aptX” mode.

My guess is that something about the cinnamon desktop environment isn’t telling the audio controller that audio is playing, but something in the Pop desktop environment (and the windows and steam deck desktop environments) is.

Does anyone know what tells the audio controller audio is playing, or what would “trigger” a usb device into thinking audio is playing?

(For what it’s worth, the adapter seems to handle the bluetooth connection to the headphones independently from the operating system. Bluetooth settings does not see the device. I also purchased an Avantree C81 bluetooth adapter which seems to function in a similar fashion, however its LED does not change color depending on codec used. I’m including it here as the fix for the BTD 600 should be the same fix for the Avantree C81.)

  • lurch (he/him)
    3•20 days ago

    idk but maybe watch your dbus for events when it works and if there are any, you can send one yourself or get your audio apps to do it. just a guess since a lot of stuff goes through dbus nowadays. you could also check the kernel logs, but it’s less likely to help

    • @riquisimoOP
      4•20 days ago

      How do I watch the dbus? I don’t know what that is.

        • @riquisimoOP
          2•19 days ago

          Thank you! Turns out the problem was something else, but I learned about the dbus today too.

      • @lordnikonEnglish
        2•19 days ago

        it’s a log you can find it with journalctl

        journalctl --user -u dbus

        • lurch (he/him)
          3•19 days ago

          that’s not watching the events though, just showing the log of the service for dbus. the events can be watched with dbus-monitor

  • @riquisimoOP
    3•19 days ago

    SOLVED: So I plugged the BTD into the windows machine and did a firmware update, the update software is available on sennheiser’s website. (Not sure if that was needed)

    In Pop_OS! I went into sounds settings and made sure the sound output was to “Digital Output (S/PDIF) BTD 600.” If it’s set to “Analog Output BTD 600” the audio is compressed. I could have sworn that I had tried this before, but apparently not.

    The same thing applies to the C81. Make sure it’s using the digital output to the Avantree C81, not the analog output to the C81.