Hello! On Wednesday 08 January 2020 14:34:32 Denis Kenzior wrote: > Hi Pali, > > > 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. I looked at dundee, but it does it is separated service, not on org.ofono So it looks like it does not fit into HSP / HFP needs. Currently you can list all audio cards by DBus call: "org.ofono", "/", "org.ofono.HandsfreeAudioManager", "GetCards" and so this (or some new) call should list all HSP and HFP devices/cards for audio application (pulseaudio). Audio application (e.g. pulseaudio) really do not want to handle two separate services to monitor and process HSP/HFP devices. For audio application are HSP and HFP devices equivalent, they provide same features: SCO socket, API for controlling microphone and speaker gain; plus optionally specify used codec. So having two separate services which fully divided for audio application purpose does not make sense. So it is possible that both HSP and HFP audio cards would be available via one audio API? Because I do not see how it could be done via design like dundee. > You can then implement the same API interfaces for setting up the HSP audio > stream as oFono does today (i.e. https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/handsfree-audio-api.txt), This API is unusable for both HSP and HFP audio streams. In pulseaudio it is somehow used, but it is not suitable. In part of designing hsphfpd I created a new DBus API for audio application to fit for audio daemons. See org.hsphfpd.AudioAgent: https://github.com/pali/hsphfpd-prototype/blob/prototype/hsphfpd.txt#L600-L663 Main objection for handsfree-audio-api.txt is that it does not provide information about locally used codec and somehow mixes air codec and local codec. In my hsphfpd.txt I used term "AgentCodec" for bluetooth local codec and term "AirCodec" for bluetooth air codec format. Another objection against handsfree-audio-api.txt API is that it is bound to HF codecs (via number) and does not support for pass e.g. CSR codecs. What is completely missing in that API is controlling volume level. And also API does not provide socket MTU information or ability to change/specify which codec would be used. So something like org.hsphfpd.AudioAgent API in my hsphfpd design would be needed. > 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. Non-audio APIs which are needed to export (for both HSP and HFP profiles): * battery level (0% - 100%) * power source (external, battery, unknown) * ability to send "our laptop" battery level and power source to remote device * send text message to embedded display * process button press event (exported via linux kernel uinput) (plus all telephony related operations, but those are already supported and provided by ofono) > If you decide this is something you want to pursue, then I'm happy to host > this in the oFono tree. > > Regards, > -Denis -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
