Talk:Bluetooth headset

From ArchWiki
(Redirected from Talk:Bluetooth Headset)
Jump to: navigation, search

Tested headsets

Added tested headsets section. Not really Arch Specific, but it is very helpful for Linux users out there looking to use a bluetooth wireless headset with Linux. Couldn't find any wiki or site that lists similar tests so I placed it here... --Divan Santana (talk) 17:50, 12 August 2013 (UTC)

  • Parrot Zik doesn't actually work that brilliantly - I have a terrible lag, and there is no microphone support.
Agreed that there is no mic support. Mine pretty much never stutters, but does lag behind in real time sometimes. Most of the time it's not noticeable for me unless playing a game. Divan Santana (talk) 16:04, 13 September 2013 (UTC)

Might be nice to turn this section into a table, with exact models, adapters, what works, what doesn't, etc. Vlsd (talk) 20:17, 28 January 2014 (UTC)

bluez5 method: overcomplicated instructions

The method in Bluetooth_Headset#ALSA.2C_bluez5_and_PulseAudio_method describes two different methods:

  1. using ALSA as a backend, similar to Bluetooth_Headset#ALSA-BTSCO_method but relying on bluez instead of bluez4
  2. using PulseAudio as a backend - this is tested in the article with Audacious, which is configured to use PulseAudio as a backend

I see two possible solutions:

  1. split the section into two sections, each describing different backend
  2. drop the ALSA instructions completely, suggest to install pulseaudio-alsa

I also think that suggesting to install audacious just for testing the output is unnecessary, any application using PulseAudio can be used for this purpose.

-- Lahwaacz (talk) 14:25, 27 December 2013 (UTC)

Point 1. Regarding bluez5 vs bluez4 -- Its fine to have a bluez5 implmentation since bluez4 method differs. The problems I encountered had numerous unanswered replies on the forums. ie. a user can pair but not connect.
Point 2. Regarding pulseaudio -- My understanding is that pulseaudio is not required in bluez4 but is in bluez5.
Point 3. -- Any app can be chosen to test, but the point is that a app needs to be chosen and the user needs to know how to select pulseaudio otherwise they will not know.
-- Netskink (talk) 12:02, 11 January 2014 (UTC)
Regarding ALSA: there is no current or planned way to get bluez working with ALSA. The only feasible method is to use pulseaudio-git. ALSA instructions should be removed from bluez5 sections until such support becomes available (if it ever becomes available).
Regarding audacious: a more compact way would be to use speaker-test, although this requires alsa, alsa-utils and pulseaudio-alsa installed.
Vlsd (talk) 20:29, 28 January 2014 (UTC)
This page should focus on bluez5, any bluez4 information will be removed as soon as there is working bluez5 alternative.
The section in question is really bloated, let's drop ALSA completely as Vlsd suggested - applications without PulseAudio support should work just fine through pulseaudio-alsa, right?
-- Lahwaacz (talk) 13:02, 1 February 2014 (UTC)
ALSA is vital for JACK Audio Connection Kit users.
Jbrickman0000 (talk) 17:28, 12 April 2014 (UTC)

Is the tip about pulseaudio-git still valid?

The version of the official pulseaudio package is now 6.0, which is greater than the pulseaudio-git AUR package. Can someone clarify if this tip is still valid?

—This unsigned comment is by Jevonearth (talk) 17:47, 20 April 2015‎. Please sign your posts with ~~~~!


GDMs pulseaudio instance captures bluetooth headset

I have solved the problem metioned here Bluetooth_headset#Connecting_works.2C_but_I_cannot_play_sound using another method than changing file permissions. Pulseaudio supports different configuration files per user ~/.config/pulse/defaul.pa. Since the is a home directory for the gdm user I have created a default.pa file in that home dir which tells the pulseaudio instance for gdm to instantly unload its bluetooth modules (if present):

#!/usr/bin/pulseaudio -nF
#

# load system wide configuration
.include /etc/pulse/default.pa

### unload driver modules for Bluetooth hardware
.ifexists module-bluetooth-policy.so
  unload-module module-bluetooth-policy
.endif

.ifexists module-bluetooth-discover.so
  unload-module module-bluetooth-discover
.endif

--Moormaster (talk) 19:28, 13 October 2015 (UTC)

GDM

Re [1], I guess the idea was to use this on Arch? There's no indication that this works, nor what it does, however. There's no mention of bluetooth, as in #GDMs pulseaudio instance captures bluetooth headset -- Alad (talk) 11:23, 22 October 2015 (UTC)

Yes it works without disabling pulseaudio in gdm. Gnumdk (talk) 13:01, 22 October 2015 (UTC)
Then feel free to add it back with proper explanation. -- Lahwaacz (talk) 15:53, 22 October 2015 (UTC)
This solution works because it does not load any bluetooth modules. It also completely ignores all other settings made in /etc/pulse/default.pa (by not using .include statement). This might be worth to be mentioned in the article. --Moormaster (talk) 09:51, 23 October 2015 (UTC)

Error in the Pairing works, but connecting does not section

If one runs pulseaudio in system mode the suggestions in Pairing works, but connecting does not are not right. The following is suggested:

   If that still does not work, or you are using PulseAudio's system-wide mode, also load the following PulseAudio modules (again these can be loaded via your default.pa or system.pa): 
   module-bluetooth-policy
   module-bluez5-device
   module-bluez5-discover

but according to Tanu here and my own experience this doesn't work. The load of module-bluez5-device fails and it is not intended to be loaded from default.pa or system.pa. If you are in system mode, only add

   ### Bluetooth modules
  load-module module-bluetooth-policy
  load-module module-bluez5-discover

to your system.pa. Also make sure, that allow-module-loading = yes is set in your daemon.conf. This is not recommended, but AFAIK the only way, because module-bluez5-device must be loaded dynamically during run time. As a last step, I also needed to add /etc/dbus-1/system.d/pulseaudio.conf with:

   <!DOCTYPE busconfig PUBLIC
    "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
    "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
   <busconfig>
           <policy user="pulse">
               <allow own="org.pulseaudio.Server"/>
               <allow send_destination="org.pulseaudio.Server"/>
               <allow receive_sender="org.pulseaudio.Server"/>
           </policy>
   </busconfig>

as I found here

After that I was able to use pulseaudio with bluez5

--Deisi (talk) 10:50, 31 January 2016 (UTC)

Workarounds

In many places it is known as a solution to restart pulseaudio when the latency is to high between what the media is actually being played and what the receiver plays. I've found a small trick which consists in stopping the bluetooth transmission.

To do that you have to:

1. Once you have the latency problem with the bluetooth already connected, select another output device like the computer speaker.

2. Wait for like 3 seconds, because once you change the output, the bluetooth will still transmit a mute silence sound until it goes into "standby".

3. When the 3 seconds have passed (or the headset is in entirely silence), you can change back the output to the bluetooth device, then the transmission starts right away and with no latency.

--Fenisu (talk) 14:40, 11 February 2016 (UTC)

Sort tested headsets alphabetically

I sorted the headsets alphabetically and added separators, but it got reverted. I think it's easier to follow if the headsets are sorted alphabetically.

-- Creak (talk) 00:29, 24 March 2016 (UTC)

Click "Model". You can also sort the other columns. Such is the magic of sortable tables - and adding them is one small change, rather than a huge diff, too. -- Alad (talk) 00:42, 24 March 2016 (UTC)
Indeed, it's better! Might still be interesting to sort the first column though: https://en.wikipedia.org/wiki/Help:Sorting#Initial_sort_order_of_rows -- Creak (talk) 00:50, 24 March 2016 (UTC)