| Thread Previous • Date Previous • Date Next • Thread Next |
On 08.10.2015 15:03, Michał Sawicz wrote:
W dniu 08.10.2015 o 14:57, Simon Fels pisze:That would a use case, yes, but still really a workaround for a corner case. However that wouldn't work with our implementation playing the role of the audio gateway strictly requires a modem with voice call capabilities.. no way to inject your VoIP stack here. It also hardly depends on how the hardware is build. For HFP on most Android devices the audio is directly routed from the microphone to the BT chip without involving the CPU so we can gurantee you're even able to inject your VoIP audio data.You mean you can't use Skype with a BT headset? Sounds like we'll get flack over that.
That depends. We're bound to the audio routing capabilities we get with the Android HAL implementation. Also lets differentiate HFP and HSP here. The HFP implementation is meant for voice call capabilities with a modem and that is how we deal with it at the moment. The other thing is HSP which is just meant for headsets without voice call control capabilities. With HSP we should be able to set things up that you can use it for Skype or whatever VoIP system you want. However we still need to figure how that is possible with the Android audio HAL.
My only point is this: since I believe we should have a generic mechanism for reading the per-device and user-overridable bits of that file, I see no reason for implementing special exceptions for this use case to *prevent* the user changing it.
We will only read whatever file this has in only once for Bluetooth on start and then take with what we were configured for. If that changes across restarts of the service then it does. However I still see only corner cases where this is required to be adjusted by the user for Bluetooth. It should for sure be nothing which is changeable in the settings app for a normal user as he wouldn’t really know what he is dealing with ..
regards, Simon
| Thread Previous • Date Previous • Date Next • Thread Next |
