HFP Client SCO audio routing?

I would say yes, moreover you can see that Wide Band speech is disabled: mAudioWbs is false

I’ve now got it to the point where it successfully opens both audio devices, and runs the main pcm loop. When I get the resampler working, it should start passing sound. After that, I’ll bring in the channel adjustments, and then finally, echo cancellation.

I’ve got 2-way audio linked through the hal now.

And asides from a medium pitched howl… well lets just say that its coming together :slight_smile:

And actually, the howl might be related to the extra audio channel that I’m not filtering out yet.

So you can hear sound from USB now?
How can I apply your changes?

Here’s the patch;

Apply it to system/media

Notes:

  1. Don’t plug in the USB sound card until AFTER the hikey960 is booted.
  2. Don’t forget to run the PCM setup command on the bluetooth.
  3. While there is a medium pitched howl, you can actually hear sounds that are sent through in both directions.
  4. I have added the channel manipulations.
  5. There is NO echo cancellation yet.
patch -p1 -i android_system_media.patch 
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/modules/usbaudio/audio_hal.c b/modules/usbaudio/audio_hal.c
|index e93396f..0b66481 100644
|--- a/modules/usbaudio/audio_hal.c
|+++ b/modules/usbaudio/audio_hal.c
--------------------------

I have no moudles directory under system/media !!

Meant to say hardware/libhardware. Sorry.

Still has error.
I think your audio_hal.c may be different from mine, because I checkout the latest source code from master branch today.

$ patch -p1 -t -i android_system_media.patch 
patching file modules/usbaudio/audio_hal.c
Hunk #5 succeeded at 1170 (offset -9 lines).
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 490:

Bad idea to check out lastest master while developing new things, because now you’re not just debugging the new stuff, you’re debugging changes in master. When the new stuff works, then check out master, see if something breaks, and adjust as needed. One thing at a time.

Your output does NOT say that it didn’t work.

Updated patch:

This one has CLEAN AUDIO :slight_smile:
Yep, 2-way clean audio.
You can actually have a conversation across this. Well, at least you could if your ear drums didn’t get blown out by the maximum volume coming out the USB speakers.

It also automatically figures out the card number for each of the two audio cards, so it is no longer necessary to wait until boot before plugging in the USB card.

  1. Remember to set up the BT PCM.
  2. USB output volume is maximum and no way to control (yet).
  3. No echo cancellation.

Fixed the device tree so that the car service starts automatically. Oddly, the solution was adding some car related selinux policies, despite the fact that I’ve got selinux set to permissive. Guess it must have been trying to start the service in some context that didn’t exist, and therefore failing.

Tried adding the PCM configurations to the BTS file… doesn’t seem to have any effect. Weird.

Huh. I think that the key to wideband audio is in the BTS file. Not so much a configuration, as a version of it. After I wasn’t getting anywhere programming the PCM into the BTS file, I tried starting with a different (newer) BTS file, and I think its negotiating a 16 kHz link.

The newer BTS file I’ve been trying is from the service pack here; http://www.ti.com/tool/WL18XX-BT-SP

I think that ultimately, we will need to be able to send the PCM configuration command from the audio HAL, since the audio HAL needs to tell it whether it should be running at 8 kHz or 16 kHz. Now to figure out just how to do that… Although alternatively, we could also do it from bt-sco driver in the kernel upon configuring the rate there.

@doitright Would you please tell us how to fix the device tree so that the car service can start automatically.
Thank you for sharing your accomplishment.

@doitright I have patched hardware_libhardware.patch successfully, but I can not hear sound from USB.
And after hang up the phone, type tinypcminfo -D0 -d0, I got following message:

hikey960:/ # tinypcminfo -D0 -d0                                               
Info for card 0, device 0:

PCM out:

hikey960:/data/tmp # tinycap test.wav -r 8000
Unable to open PCM device (cannot open device '/dev/snd/pcmC0D0c': Device or resource busy)
Captured 0 frames

And I noticed an error message during the phone call:

01-22 04:09:23.753  2230  7974 W StreamHAL: Error from HAL stream in function get_presentation_position: Operation not permitted

Anything I did wrong?
Maybe it is caused by latest source code from master branch?

That looks like something missing or changed in the kernel, might be that something didn’t get detected on boot? You sure the USB card was properly detected? Didn’t get unplugged by accident? Any logs related to the USB audio? I find that the USB device usually gets detected as 0 and the BT as 1.
Ignore StreamHAL, doesn’t matter.
Do ‘logcat | grep usbaudio’
But first get output for the following two;
tinypcminfo -D 0 -d 0
tinypcminfo -D 1 -d 0

I gave you the link to the device tree. Update is added there.

Any patch should be applied to hi3660-hikey960.dts?

Here are the messages of tinypcminfo:

hikey960:/ # tinypcminfo -D 0 -d 0                                             
Info for card 0, device 0:

PCM out:
      Access:	0x000009
   Format[0]:	0x000004
   Format[1]:	00000000
 Format Name:	S16_LE
   Subformat:	0x000001
        Rate:	min=8000Hz	max=8000Hz
    Channels:	min=1		max=2
 Sample bits:	min=16		max=16
 Period size:	min=256		max=2048
Period count:	min=4		max=128

PCM in:
      Access:	0x000009
   Format[0]:	0x000004
   Format[1]:	00000000
 Format Name:	S16_LE
   Subformat:	0x000001
        Rate:	min=8000Hz	max=8000Hz
    Channels:	min=1		max=2
 Sample bits:	min=16		max=16
 Period size:	min=256		max=2048
Period count:	min=4		max=128

hikey960:/ # tinypcminfo -D 1 -d 0                                             
Info for card 1, device 0:

PCM out:
      Access:	0x000009
   Format[0]:	0x000004
   Format[1]:	00000000
 Format Name:	S16_LE
   Subformat:	0x000001
        Rate:	min=44100Hz	max=44100Hz
    Channels:	min=2		max=2
 Sample bits:	min=16		max=16
 Period size:	min=45		max=131072
Period count:	min=2		max=1024

PCM in:
      Access:	0x000009
   Format[0]:	0x000004
   Format[1]:	00000000
 Format Name:	S16_LE
   Subformat:	0x000001
        Rate:	min=44100Hz	max=44100Hz
    Channels:	min=2		max=2
 Sample bits:	min=16		max=16
 Period size:	min=45		max=131072
Period count:	min=2		max=1024

“logcat | grep usbaudio” shows the following:

hikey960:/ # logcat | grep usbaudio
01-23 09:20:15.659  2216  2237 D modules.usbaudio_hal.hikey: adev_set_parameters: kvpairs: card=1;connect=67108864;device=0
01-23 09:20:15.934  2216  2237 D modules.usbaudio_hal.hikey: adev_set_parameters: kvpairs: card=1;connect=-2113929216;device=0
01-23 09:44:02.277  2216  9130 D modules.usbaudio_hal.hikey: adev_set_parameters: kvpairs: hfp_enable=false
01-23 09:44:37.851  2216  2216 D modules.usbaudio_hal.hikey: adev_set_parameters: kvpairs: hfp_set_sampling_rate=8000
01-23 09:44:37.851  2216  2216 D modules.usbaudio_hal.hikey: adev_set_parameters: kvpairs: hfp_enable=true
01-23 09:44:37.851  2216 13794 D modules.usbaudio_hal.hikey: runsco: USBCARD: 1, BTCARD: 0
01-23 09:44:37.852  2216  2216 D modules.usbaudio_hal.hikey: adev_set_parameters: kvpairs: hfp_volume=11
01-23 09:44:37.852  2216 13794 D modules.usbaudio_hal.hikey: runsco: failed to open PCM near/in
01-23 09:44:46.293  2216  2216 D modules.usbaudio_hal.hikey: adev_set_parameters: kvpairs: hfp_enable=false

If I setup usb_config as:

struct pcm_config usb_config = {
.channels = 2,
.rate = 44100,
.format = PCM_FORMAT_S16_LE,
.period_size = 1024,
.period_count = 2,
.start_threshold = 0,
.silence_threshold = 0,
.stop_threshold = 0,
};
I got the following messages:

01-23 09:56:37.998  2213  9013 D modules.usbaudio_hal.hikey: adev_set_parameters: kvpairs: hfp_enable=true
01-23 09:56:37.998  2213 13860 D modules.usbaudio_hal.hikey: runsco: USBCARD: 1, BTCARD: 0
01-23 09:56:37.999  2213  9013 D modules.usbaudio_hal.hikey: adev_set_parameters: kvpairs: hfp_volume=11
01-23 09:56:38.014  2213 13860 D modules.usbaudio_hal.hikey: runsco: failed to open PCM near/out
01-23 09:56:44.574  2213  9013 D modules.usbaudio_hal.hikey: adev_set_parameters: kvpairs: hfp_enable=false

Ok, so its looking like the issue you are having is that not all USB sound cards are created equal. The “failed to open PCM near/out” means that it is unable to open the write (output to speaker) stream on your USB card, likely because your card is already open. My card appears to allow me to open multiple streams. Your workaround for this is likely going to be a lot more involved than what I’ve implemented, since you are going to have to ensure that that you either close existing streams before opening, or use the existing streams, but block other processes from accessing them while you are streaming SCO.

In addition, since your card is incapable of 48 kHz, you will have to make more changes to the code than you have already. The resamplers and buffers will have to be adjusted. It should be sufficient to replace all instances of 48000 with 44100, but also be aware that because your USB card is not operating at an even multiple of the SCO sample rate, the resampling process will be a lot heavier on CPU usage.

What card are you using?
I’m using a Vantec NBA-200U: http://www.vantecusa.com/products_detail.php?p_id=155
Reasons I chose that card are;
1) Microphone input,
2) Line input for AMFM radio,
3) >= 4 output channels (cars pretty much universally have 4 output channels)

Mine is this one. I think Creative should be supported by linux kernel, because it’s a famous brand.
http://support.creative.com/Products/ProductDetails.aspx?catID=1&CatName=Sound+Blaster&prodID=22772&prodName=Sound+BlasterX+G1

I suppose the output of the USB sound card is occupied by the ring tone, It’s too fast to open the write stream.
Maybe add sleep(1) before opening the stream can resolve the problem. I’ll test if adding a delay can make it work tomorrow.