Hello! I could you or other ofono developer please look at my comments below and say how we can continue with these problems? Now another month passed and I really would like to continue in effort to implement HSP/HFP profiles with audio support on Linux desktop. On Wednesday 08 January 2020 22:25:37 Pali Rohár wrote: > 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
