Microphone support

[rapiz1]

Sorry if this is not the right place to ask. I'm using this module for my headset and in modes other than HSP/HFP, the microphone doesn't work. And HSP/HFP has very bad quality. According to here, A2DP supports microphone, though there could be some doubts. So is there any way to support high quality sound and recording in the mean time?

[userofryzen]

I have been reading this topic. Some possible to merge with that git so we can obtain better micro input?

[EHfive]

It's about FastStream codec. Not every A2DP codec has microphone support.

[Hayao0819]

There is a link to this issue in the comment of AUR that I maintain. Is there anything relevant?

[userofryzen]

The possibility of use the microphone of the Bluetooth device without having to loose so much quality in the audio output I think. Have you connected to a good mobile phone the device and call? Vs call with the computer connected to a device with micro? The quality difference are ...quite big (I am speaking of HSP hfp not ad2p . It's appear that ad2 p have micro feature in so many systems and not linux

[rapiz1]

It's about FastStream codec. Not every A2DP codec has microphone support.

@EHfive So is it reasonable for this project to have the feature? Or it's out of scope?

[EHfive]

#1 (comment)

Since a2dp api part of @pali 's patchset is merged, this repo being source incompatible with current PulseAudio. Also, the patch merging cycle is a bit long.
Therefore, I would like to make this repo as a temporary workaround for extra codecs support instead of merging it to upstream.

My initial purpose of creating this repo is that add LDAC support to GNU/Linux. And this project is being out of tree. I would not making huge changes to current codebase (no new features).

Inspired by https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/288, I am thinking about making a daemon which can handles all HSP/HFP/A2DP profiles and provides apis to several audio servers(Pipewire, Pulseaudio, ...).

You can keep this issue open for status tracking.

[userofryzen]

But the thing to support good audio quality with hsp and micro is not going to be supported here if I am understanding well. Right?
I mean we will have to choose between good sound quality with music or good quality in videoconference for example.

[btreecat]

@rapiz1 so I have the same issue, but only on my desktop it seems. My laptop is using the same lib for aptx support.

The main software diff between my systems is my laptop is on XFCE and my desktop KDE. Are you running KDE for your desktop?

I have no yet experimented with moving my USB Bluetooth dongle to my laptop and trying again to work out if it's a hardware/driver issue or not.

I think because I am able to use my laptop however, the problem likely does not exist within the lib itself but rather the audio/bluetooh device management tools on top.

[ashrafuzzaman]

Love the effort guys. If we get the microphone support then it would have been perfect.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cpitclaudel]

You can keep this issue open for status tracking.

I think it would be good to keep it open (re stale)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[userofryzen]

Pali is making many advances for them patches being merged. But we are waiting to pulsesudio to release a new versions that never is releasing xD

[mcarans]

Sadly there has been a dispute between Pali and the Pulseaudio mods and development there has stopped. Hence this project is very much needed.

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/288#note_713222

[EHfive]

Maybe a standalone bluetooth audio daemon handling both HSP/HFP and A2DP would be preferred.

[EHfive]

PipeWire devs are working on their way. PipeWire already added hsphfpd support, it even got LDAC support now.

https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/dd8573a5c244c624ff2ae46c3f15664c0b65e448

[pali]

Hi there!

I'm Pali, author of the pulseaudio pull request which improved HSP, HFP and A2DP bluetooth profiles and added support for some new codecs. It looks like that pulseaudio developers locked my pull requests and also my account to mute me so I would not be able to write any response. And they have not wrote me anything, nor informed me about fact that they give me a ban. I was just contacted by users what happened. Basically it was clear about half year ago that nothing would be merged.

So do not trust what would pulseaudio developers write, they would be probably lying, because they can, now when they muted me.

I was contacted by more pulseaudio users, so I will write group reply here:

So what to now? I need to say, forget about pulseaudio. Also forget about my work, it is lost, at least in my mind. I will never contribute to pulseaudio project anymore. One of the pulseaudio developers was such rude that today via private IRC chat (after giving me a ban) wanted from me a permission for my work, so they could re-use it in their own pulseaudio project. I guess you know what was my reply. I can call such man only bastard.

Also I was contacted by more software companies that they would like to cooperate with me for consultancy to fix bluetooth audio support in their linux systems. This just prove the fact that Linux bluetooth audio support is poor and there are not so many people who understand problematic around it. For this I need to say, that my work was from beginning hobby project, I'm not paid by working on bluetooth audio support. And because it was just hobby project, I do not have a free time for working at it anymore.

Pulseaudio developers from beginning were not intersted in any improvements in bluetooth audio. I guess that this @EHfive repository is reason for that. If I know this at beginning I would never spend time to try any communication with pulseaudio.

@EHfive: you are smart and understand bluetooth problematic. In case you are interested for a bluetooth audio consultancy in some companies, I can send contacts. If not I will write replies to that software companies that it would be easier for them to switch to other operating system with better bluetooth audio support (Windows, Mac OS X).

Pulseaudio developers finished their 2 years job: Ensure that audio bluetooth support on Linux stay poor. My patches are about 2 years old and for this time there was no progress.

All users, please do not write me support emails, rather switch to Windows or Mac OS X where bluetooth audio is working out-of-the-box. Power users switch to e.g. @EHfive fork or maybe pipewire.

And if you are thinking that I should rebase my work on pipewire project, forget about it: I cannot open any pull request even in pipewire project and also in any other freedesktop project (I tried it now... another thing which nobody told me that this is banned). Also do not forget that I cannot write any replies to my original pull requests.

For reactions, please use only emojis to this post. Please do not write any replies, this is @EHfive issue about microphone support. I hope that @EHfive understand that some (this) reaction was required and this was only place which people are reading and where I can put it. I will not respond to it.

So long, and thanks for all the fish!

[EHfive]

Hi @pali, thanks for your 2 years work, sadly they are not accepted by PulseAudio devs.

Glad that you invited me, I am afraid that I am not capable to perform as a consultancy.

My fork actually comes 2 months later than your patchset on mailing-list. Although my fork is about LDAC initially, If I knew that before @ValdikSS mentioned me on #1 than I would not create this repo.

It's pity that you got banned from freedesktop gitlab (hosting both PulseAudio and PipeWire). I wonder would you still continue the work on hsphfpd? Since PipeWire has hsphfpd support.

[pali]

Since PipeWire has hsphfpd support.

This does not mean anything. Moving discussion here.

I wonder would you still continue the work on hsphfpd?

Do you mean daemon part which implements those profiles? Do you have a use case for it? pulseaudio and pipewire already are out of the game and I do not know any other audio project which would be interested in it.

[EHfive]

With works of many people (include me), PipeWire now supports LDAC/ aptX/ aptX HD and mSBC (on hsphfpd or ofono).

Since I just moved to PipeWire. and I am intend to deprecate this project soon or later (#145 (comment)). For anyone who still interested in microphone support on GNU/Linux, please move to PipeWire community or PulseAudio community.

Close.

[pali]

@EHfive: I'm not surprised in your movement.

Pulseaudio admins/maintainers blocked for years every bluetooth improvement and when it come to starting explaining things, they stopped communicating, saying that everything is total lie, started lying, then blocking and banning so people would not be able to write reaction to their comments.

Anyway, pipewire has (or had) fatal issues which make it impossible to implement stable SCO transports and also hsphfpd integration. Details are here: pali/hsphfpd-prototype#11 (comment)

So I'm not sure now, if it make sense to have hsphfpd project still available. Pulseaudio is dead, pipewire has fatal SCO issues and no interest to fix it and there is no other audio server which can be used for bluetooth.

[EHfive]

@pali I believe they do have interests. Maybe they just don't know or don't have time (the project is mainly maintained by only one person @wtay).

It's pity that PA admins still has not unbanned you.

[sheepdestroyer]

It's pity that PA admins still has not unbanned you.

PA admins did unban him,
However he was promptly rebanned by someone external to the PA project. An Xorg CoC team member acting as a CoC enforcer for all of freedesktop's gitlab and hosted projects apparently.

[soredake]

and I am intend to deprecate this project soon or later

Does pipewire supports sbc hd/xq? If not the quality of sound on my sbc-only headphones will be bad. I asked in bugtracker but no one answered https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/249#note_732636

[EHfive]

@soredake No. Actually those are just several parameters on sbc encoder, maybe we would have it in future, see https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/348.

Please move to #147 for discussions on PipeWire.