I’ve been stuck on this for a few days now.
I tried issuing the command from the alsa driver, but I think that it wasn’t opening the alsa driver until after the SCO stream was already running, causing the audio only to work correctly in one direction.
I’ve tried also putting a single rate into the BTS file, and it just doesn’t seem to work from there at all.
Usually PCM configuration is applied via HCI VS command suring controller initialization and never changed, For me the best place is at the end of the ll_setup function in drivers/bluetooth/hci_ll.c. Why do you want to change this dynamically ? btw, not sure about that point but a HCI reset can be necessary to validate the vendor configuration.
Because SCO supports 2 sample rates, being 8k and 16k.
The strange thing is that it doesn’t work from the BTS file, which is loaded at the same place you suggested.
Its looking to me like this controller is actually pretty terrible when it comes to SCO. The standard 043e command contains enough data to set up the PCM without resorting to a VS.
I think I’m looking in the wrong place for the problem. I added a debugfs entry to send a bunch of different VS commands out with some variations – offsets, rising/falling edge, etc. When I run the commands, there is a clear difference in the sound coming in, but it doesn’t fix the sporadic broken incoming audio problem.
I think that what changes that is actually closing and opening the pcm in the audio HAL, which would place the problem in hisi_i2s.c or related.
I’m getting really close on this one now.
It has something to do with WHEN it is sent.
This VS command MUST be sent to the BT chip for EACH SCO connection. That includes during a call if you switch from BT to headset and back to BT. Note that this is apparently NOT how it is supposed to work, it is not supposed to need the VS command to be sent like that, it is supposed to work even from the BTS script, but that isn’t working. I think that something in the process of setting up a call is causing the PCM configuration to be reset.
Closing and reopening the PCM has no impact, but I found that if I send the VS command just a bit earlier in the process, it creates good sound much more reliably.
I’m currently triggering it from the audio HAL, immediately before opening the pcm.
Interesting, but you’re right this is not the expected behavior. Once PCM is configured, controller keep the configuration and start using PCM when SCO link is in place. Typically, after both devices have negociated codec via AT commands (AT+BCS…), SCO link is established. Maybe the VS command needs to take place just before this SCO connection…
The earliest point where I can run the command is from the top of bta_hf_client_sco_conn_open(…). Unfortunately, it is still not reliable, and I still get severely distorted sound on some connections.
The interesting thing is that the horribly broken sound that comes in does follow generally the sound that is input to the far end of the connection. That, and the fact that the outgoing sound is always good.
So I may have to probe the i2s again, this will hopefully tell me if the problem is on the sending side or the receiving side.
