Do you have a reasonable solution also for second issue?
HSP profile has always been a problem child. It isn't really all that
useful as a profile, and given how minimal it is, the right place for it
always seemed to be inside Pulse Audio itself. This is what Marcel & I
agreed upon back about 8-9 years ago anyway.
You are advocating that HSP is still useful, particularly with vendor
extensions. Which is fair enough, but now you have to figure out how
and where to put this support.
As mentioned earlier, one idea you can explore is to create a small
daemon (or maybe it can even be part of ofonod itself) that will handle
HSP client/server roles. See for example the dundee daemon that is part
of ofono.git. dundee handles Bluetooth DUN profile and might be a good
model / starting point for what you're trying to accomplish.
You can then implement the same API interfaces for setting up the HSP
audio stream as oFono does today (i.e.
which would make PulseAudio's job much easier, since the audio stream
aspects would be essentially identical to HFP. If you're part of
oFono's tree, then in theory many implementation aspects could be reused.
If you want to provide some higher-level APIs for external applications,
then HSP specific interfaces (APIs) can be added as needed.
If you decide this is something you want to pursue, then I'm happy to
host this in the oFono tree.