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.
bluez5 method: overcomplicated instructions
The method in Bluetooth_Headset#ALSA.2C_bluez5_and_PulseAudio_method describes two different methods:
- using ALSA as a backend, similar to Bluetooth_Headset#ALSA-BTSCO_method but relying on instead of
- 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:
- split the section into two sections, each describing different backend
- drop the ALSA instructions completely, suggest to install
I also think that suggesting to installjust for testing the output is unnecessary, any application using PulseAudio can be used for this purpose.
- 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 working with ALSA. The only feasible method is to use . ALSA instructions should be removed from bluez5 sections until such support becomes available (if it ever becomes available).
- Regarding : a more compact way would be to use speaker-test, although this requires , and 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 , right?
- -- Lahwaacz (talk) 13:02, 1 February 2014 (UTC)
- Speaking of Bluez5 alternatives. Recently, I've created something along those lines. It is still work in progress, however it is already possible to stream audio to headphones (and record music from e.g. phone). If anyone finds it useful, please make some note on the wiki (my editorial skill are very poor). Project location: https://github.com/Arkq/bluez-alsa
- -- Arkq (talk) 22:06, 18 August 2016 (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?
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
Re , 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)
- Is this not considered a bug? Why are there by default two pulseaudio instances when only one is needed? In my case, dropping the second pulseaudio instance solved my bluetooth headset problem. If this is a bug, is it a pulseaudio or gdm bug? -- SeverOraz (talk) 11:21, 27 December 2016 (UTC)
- This also worked here. This really should be default behavior, since most people installing this may wonder why their headset isn't working (myself included, only a few hairs pulled) Parkerlreed (talk) 15:58, 1 May 2017 (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
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.