Pulseaudio / bluetooth / hearing aid problem

[nmm1]

From searching the Web, I am not the only person who has hit this, but the incidence is very low indeed, and it will take a little describing. I am running Debian 10.4 on a 9 year old (high-quality) AMD desktop - the system details are complicated but almost certainly irrelevant, except that it has NO audio hardware (in or out) except that in the (a) built-in graphics card and (b) GEForce graphics card (which I use). I bought a Belkin Bluetooth USB dongle, and followed Web instructions to get it going - with the usual false starts. That dongle then connects to a Resound Phone Clip+, which connects to my hearing aids.

However:

Turning on things (hardware and software) in the right order connects all that together. The various /var/log files show the dongle, the Pulseaudio Volume Control app. shows it, turning on Pulseaudio tracing shows it and gets the MAC address right, every resetting operation on Bluetooth or Pulseaudio or starting/stopping of audio applications (speaker-test or mplayer) causes noises of the form I would expect, and there's no error shown anywhere.

The first time I did that, I used mplayer to play a .wmv, and it worked. So I went away, intending to test it on Web videos (youtube etc.) later. When I came back, I had made NO changes, everything in the previous paragraph was the same, but there was no sound. I tried several of the incantations on the Web for such an issue, attached the dongle to each of the Pulseaudio sinks in turn, rebooted several times, etc. etc. - but no joy.

When it fails, the Pulseaudio Volume Control app. shows it, but it is greyed out and won't allow me to change the volume. I turned on debug-level tracing, watched it as I connected, and there wasn't even a hint. Unfortunately, I do NOT have the same information for the time it worked and, obviously, can't repeat the test. The nearest I could find to a diagnostic in the failing cases was:

D: [pulseaudio] sink.c: set_port() operation not implemented for sink 1 "bluez_sink.<MAC address>.a2dp_sink"

I can find nothing in the documentation that helps with this. One possibility would be if I could find a mechanism to trace the audio pathway AND what codecs it is using at each stage, which might at least tell me where the pathway is breaking.

Anyway, thanks for any help

Regards,
Nick Maclaren.

[LE_746F6D617A7A69]

Your description of a problem is lacking even most basic information -> no one can help without knowing what You did and how.

The most fundamental information needed here is the vid and pid number of Your BT dongle - this allows to identify the device model, which is needed because some BT dongles need bluez-firmware package to work.

Anyway, the most basic things to check are:
1. Delete connections remembered by the BT manager and pair Your device again (btw: which BT manager You're using?)
2. Check if the bluetoothd service is running. If not, try to reconnect the USB BT dongle and see what's in the logs.

[nmm1]

Thank you.

The most fundamental information needed here is the vid and pid number of Your BT dongle - this allows to identify the device model, which is needed because some BT dongles need bluez-firmware package to work.

I did that even before I started testing that, AND installed updates AND rebooted. If you reread my post, you will see that I stated explicitly it worked ONCE, and that it ALWAYS connects - missing firmware is implausible. In case you are still doubtful, I get the following from the logs when I connect it:

grep 'Jun 18 17:3[56789].*' *.log debug messages

daemon.log:Jun 18 17:35:22 asmodeus bluetoothd[1976]: /org/bluez/hci0/dev_<MAC address>/fd1: fd(36) ready
daemon.log:Jun 18 17:35:22 asmodeus rtkit-daemon[2003]: Supervising 1 threads of 1 processes of 1 users.
daemon.log:Jun 18 17:35:22 asmodeus rtkit-daemon[2003]: Successfully made thread 2069 of process 1999 (n/a) owned by '1000' RT at priority 5.
daemon.log:Jun 18 17:35:22 asmodeus rtkit-daemon[2003]: Supervising 2 threads of 1 processes of 1 users.
debug:Jun 18 17:35:22 asmodeus rtkit-daemon[2003]: Supervising 1 threads of 1 processes of 1 users.
debug:Jun 18 17:35:22 asmodeus rtkit-daemon[2003]: Supervising 2 threads of 1 processes of 1 users.

Plus, as I said, running pulseaudio --log-level=debug shows that pulseaudio is getting hold of its MAC address and implying strongly that everything is fine - I quoted the only line that looked like a diagnostic, and it was only at 'debug' level.

Identification numbers of the dongle might be useful (yes, I had already looked), but I found nothing in the logs, and don't know how to obtain them otherwise - that's not the sort of thing that commodity suppliers tell mere customers!

Anyway, the most basic things to check are:
1. Delete connections remembered by the BT manager and pair Your device again (btw: which BT manager You're using?)
2. Check if the bluetoothd service is running. If not, try to reconnect the USB BT dongle and see what's in the logs.

Been there - done that - see the above logs. It's blueman, incidentally - and, as I said, its graphical interface told me it had connected successfully AND pulseaudio is connecting to that MAC address AND I hear that on my hearing aids! There's no way that ANY sound from the computer can reach them except via that Bluetooth dongle! No, failing to connect is not the problem - failing to match codecs might be, but I can't find any information on that, which is why I mentioned it in my last paragraph.

And, to repeat, it worked once and has not worked again - and my first failing tests followed the successful one with NO configuration changes, though I have done some since. That's what really baffles me.