Bluetooth headset audio boost

[jprostko]

Hello,

I am new to Sailfish OS, having experimented with it first on the PinePhone, and then the OnePlus One. I now am running Sailfish X (version 3.3.0.16) on the Sony Xperia 10+, and have essentially made it my daily driver for now.

That all said, one of the first things that bugged me was that the audio of my Bluetooth headsets was really low. I wanted to share my fix in case anybody else has the same problem. I also want to share it in case anybody else has a better way to go about doing this. While the method I used is easy to implement, I would think there is probably a better way to go about it.

Here is what I came up with.

1.) SSH into your phone, become root (via devel-su su - or similar), and create a custom udev rule under /etc/udev/rules.d. I created a file called 9999-bt-audio-boost.rules with the following contents, where the 9999 prefix was used so I was assuring it ran last after all other udev rules. I used vi on the OS itself to create the file, but there’s other ways to go about getting the file into place:

ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/bin/sleep 3", RUN+="/sbin/runuser -l nemo -c 'pactl set-sink-volume @DEFAULT_SINK@ 200%'"

2.) Run the following so that your udev rule will trigger when a Bluetooth device is attached:

udevadm control --reload-rules && udevadm trigger

Now anytime a Bluetooth headset connects to a phone, the volume output for the device will double. Note that in my case anyway, this only really works if you already are listening to music, and it may take a cycle of connecting and disconnecting to get it to take.

Other than hearing the volume increase, you can check if the volume change applied by looking at the output of pactl list sinks and seeing if the front-left and front-right volumes are at 200%.

Things you can tweak:

1.) The time to sleep before running the pactl command. While 2 seconds worked reliably with one headset of mine, 3 seconds was the only way to have the volume boost happen for another. It is best to test this out while having music actively playing so that the audio boost happening is obvious. You should strive to use the lowest number possible number here.

2.) The volume percentage can be adjusted. While the one device worked well with 175%, the other one only gave me some headroom if I used 200%. Again, the lowest number that allows you to reach the desired usual listening volume with a few volume rocker clicks of headroom should be used.

3.) While @DEFAULT_SINK@ worked properly on my Xperia 10+, it’s possible it won’t work on your device. In my case, the index for the device increments every time the device is connected (until it eventually “rolls over”), and so using @DEFAULT_SINK@ was reliable in my case compared to a fixed number. While I would think other devices would behave similarly, I haven’t gotten around to doing testing on my other devices.

Now, I would have liked to filter this udev rule against some custom attribute common to Bluetooth headsets, but none were present that I could find when looking at the output of udevadm monitor -e and similar. Because of this, this rule runs anytime a Bluetooth device is connected, regardless if it is an audio device or not (unless the system classifies it in a different device class). While this will not be a problem if you only ever connect custom headsets, it could cause issues if you are not using a Bluetooth headset, but attach some other sort of Bluetooth device. This could then inadvertently perhaps cause your speaker or headphones (via headphone jack) volume to boost. I haven’t tested this, but I wanted to point it out just in case.

I also would have preferred not to put in the 3 second sleep at all since that is a blocking operation for a few seconds, but it was the only reliable and easily-configured way I could come up with for solving this problem.

Thanks for reading, and again, direct me elsewhere if there is a better way of doing this so I can take a look.

Thank you.

[apozaf]

Well, you could simply buy new, better, louder earphones. F.ex. the KZ-E10 TWS earphones with 5 drivers each. They blow up your ear if you move the lever to more than 2/3 and are quite cheap but comparable to 500€+ stuff. They sound fantastic. Just a recommendation.
Each earpiece is equipped with 1x 10mm double magnetic dynamic driver, 2x 30095 balanced armature drivers and 2x 50060 BA. In additions to this, this model carries a Qualcomm QCC3020 chip with Bluetooth 5.0 tech.
For 50€ you won’t find anything near it. And: they are really, really loud and sound fantastic.

[jprostko]

Thanks for the recommendation.

I really would prefer not having to buy newer headsets, as my OnePlus Bullets Wireless 2 and AfterShokz Trekz Air headsets have worked well for me thus far on previous phones, and I am only seeing problems in Sailfish X. I am not opposed to getting a new headset, but it would be more of a last resort kind of thing that I would do if I would know 100% it would solve my problem.

Oddly enough, today I noticed that these headsets are far too loud now with the boost I put into place when making a phone call, as I cannot comfortably use either set due to not being able to reduce the volume any further. In fact, the volume rocker seems to be using my 200% as the minimum volume, and it will only go higher from there. I need to test sometime when I have a patient caller, but I suspect during a call I’ll have to drop the volume from 200% to 50% when taking a call with the exact same headsets.

In other words, I don’t think the headsets are the problem. I think that there must be an issue with how the volume control in Sailfish X works…at least on certain phones anyway.

I see there is this thread, which seems to indicate that there’s problems with the volume setup. The main complaint there is about the minimum volume, which is indeed now a problem for me, but only with phone calls.

[jprostko]

Just following up on my post in case anybody looks at this later.

I found that my car’s Bluetooth receiver needed further delay before the boost, so I ended up having to increase the sleep amount. The 200% boost was definitely ideal for it as well, since all other audio in the car (radio, Android auto, etc.) needs to be set at around 20/100 volume to be at good listening volume, and without the boost, I have to use 40/100 with Sailfish. With the boost, naturally it is 20/100 like all other audio sources. I also tried the Sony WH-1000XM4 headphones with my phone, and they work well with the 200% boost.

In the end, I ended up getting rid of the udev rule and instead am using the Situations app, since it handled my phone call scenario as well. I have a one-line bash script run to boost the sink volume to 200% when any of my desired Bluetooth headsets are connected, and when there is a phone call and one of those headsets connected, another one-line bash script is run to is set back down to 100%. I thought I would need lower than 100%, but it was actually ideal. Once the call ends, I have the boost script run again, and then all is well.

Using Situations is definitely better since I can specify which devices I want involved (instead of the volume being boosted regardless of connected Bluetooth device), and it also allows the flexibility to handle the calling scenario pretty much perfectly. I can also utilize it if I want to add in different delays for different devices before the boost, although I doubt I’ll get around to doing that, since everything “just works” now.

I think the 200% boost was also responsible for the minimum volume being way too loud on a phone call, as it almost feels like an overflow situation where the volume indicator has no clue what is going on and is basically at maximum volume even though it is set to minimum. Cutting the volume back to the normal 100% on a phone call via Situations works perfectly and I’ve never been able to reproduce that “minimum volume problem” ever again.

I hope in the future I can get rid of this workaround (since ideally there should be no reason to boost at all), but this works well enough for now.

[crun]

the issue with my BT headphones is that the microphone level is very low on sf

[xneo]

I think it would make sense to have an built in solution in SFOS… Buying new earphones is one thing… New car because BT volume is low is another thing

[ApB]

Since this happens to many (including me in the car -and its annoying) shouldn’t we post it on the bugs sections???

[carmenfdezb]

I have the same issue with my Huawei FreeBuds3 and it’s a pity because they are the most confortable headphones I ever use, so I don’t want to use others.
I hope Jolla fix this issue soon, meanwhile I will try the solution that @jprostko describe here (thank you for that!)

[carmenfdezb]

I’m using your solution with Situations app. When I connect my bluetooth headsets, I run the next command: pactl set-sink-volume @DEFAULT_SINK@ 200%
That works fine, but If I turn off and then turn on my bluetooth, it doesn’t increase volume. I think it’s a problem with Situations app, because If I stop and start Situations, it works fine.
I would like to know if you have this same issue.

[peterleinchen]

I guess you need to add a stop situation calling the reset script.
Normally Situations takes care of restoring settings after the situation is not present anymore. But in case of making use of bash scripting Situations is not able to know how to restore.
So creating a new situation where you define ‘device not connected’ and calling the reset one-liner should do the trick.

[jprostko]

@apB Thanks for posting a bug for this problem. I haven’t checked in the forum for some time, but saw you posted a solution.

[jprostko]

Below is what I did with Situations, where using the “At situation end” condition comes in handy. Keep in mind I will use placeholder names for my Bluetooth headsets so it’s more of an example. This works pretty well for me, although there are the cases where I may need to shut my Bluetooth headset off and back on again to get things working. It is rare due to the long sleep of 7 seconds I am using so things play nicely with my car’s receiver.

Situation: Bluetooth headset attached
When: Bluetooth Headset 1 OR Bluetooth Car Receiver
What: /home/nemo/audio_fix/bt_audio_boost.sh

Essentially this will just boost the audio when a Bluetooth headset is attached.

Situation: Phone call with Bluetooth headset
When: Bluetooth Headset 1 OR Bluetooth Car Receiver
What: /home/nemo/audio_fix/bt_audio_dampen.sh AND /home/nemo/audio_fix/bt_audio_boost.sh
(Ensure you check the checkbox for "At situation end" for the bt_audio_boost.sh command.)

This will dampen the volume back to normal 100% during a call, and then when the call is over it will boost the audio back up again. You could probably get away with running a different script without the sleep time in the beginning, but I wanted to keep things simple.

Currently how my bash scripts look (make sure the files are executable, or else you they won’t run):

[nemo@Xperia10Plus ~]$ cat audio_fix/bt_audio_boost.sh 
#!/bin/bash

sleep 7 && pactl set-sink-volume @DEFAULT_SINK@ 200%
[nemo@Xperia10Plus ~]$ 
[nemo@Xperia10Plus ~]$ cat audio_fix/bt_audio_dampen.sh 
#!/bin/bash

pactl set-sink-volume @DEFAULT_SINK@ 100%

[ApB]

TBH i am not much of a fan of solutions/workarounds like that. If a user has to mess up with the terminal then something is wrong. And has to be solved. Hence the bug report.

Or at least if there is no way around it i would prefer a graphical way of doing things like that. Ie. a pulse audio mixer app.

[carmenfdezb]

Thanks for your answer but it doesn’t work because you can change the volume level of a device bluetooth if it’s not connected. Plus, when you disconnect the headphones bluetooth and connected it again, the volume level for this device is set to 100 by default.
It’s a pity because it’s a good idea meanwhile this bug is fixed, but it doesn’t work for me, or I’m doing something wrong or it’s a bug in Situations app, so I would like to know if it works for @jprostko

[carmenfdezb]

Sorry, I wrote my post before reading your post.
Thank you for your help!! I just had to add ‘sleep 7’ to my script.

[jprostko]

Agreed. A bug definitely needed filed since this is just a dirty workaround. I just wasn’t sure how widespread the problem was until I saw more replies to this post.

Thanks again for filing the bug.

[jprostko]

I’m sure you’ll find cases where things don’t work as you like, but it works for the most part. I’ve still had times where the boost never kicked in during certain scenarios, but most of the time it does work. You can likely make the sleep less than 7 seconds as well, but I had to end up using that due to the way the receiver in my car interfaces with the phone.

Hopefully the bug that ApB filed will help this get fixed so we don’t have to resort to workarounds such as this. On the plus side, this helped me learn about Situations, which I also use to shut my WiFi off at night, as well as lower my ring volume. I know it can do lots of other cool things as well, but I just haven’t thought them up yet.

[carmenfdezb]

Yeah, I use ‘sleep 5’ at the moment and it works fine for me. I didn’t think that sleep command is needed, when I use “Actived connection”=my headphones bluetooth.

On the other hand, I’ve noticed that when I use pactl set-sink-volume @DEFAULT_SINK@ 200%, phone volume is inscreased to 200% too (see with command pacmd list-sinks, index=0). To solve that you can add a command pactl set-sink-volume 0 100% or use sink name instead of sink id: pactl set-sink-volume <sink_name> 200%

[Schrdlu]

I was having the same kind of problem (low maximum volume) with some of my bluetooth buds (under Xperia 10 ii, 4.3.0.12). In my case, it seems to be linked to the invalid handling of volume in AVRCP.

May be not universal, but for me the solution was to disable avrcp in bluez :

Edit “/usr/lib/systemd/system/bluetooth.service” to add “–noplugin=avrcp” parameter to the ExecStart command :

ExecStart=/usr/libexec/bluetooth/bluetoothd --noplugin=avrcp -n $TRACING

Restart the bluetooth service :

systemctl daemon-reload
systemctl restart bluetooth

Unpair and repair the problematic headset.

[carmenfdezb]

Thanks! This solved my problem temporary and I hope that Jolla can fix it.
Although touch control doesn’t work now, at least I can listen music in a reasonable volume level