Mine:
01-19 07:23:53.931 2430 2875 D HeadsetClientStateMachine: AM -> HF 4 11
01-19 07:23:53.931 2430 2875 D HeadsetClientStateMachine: hfp_enable=true mAudioWbs is false
01-19 07:23:53.931 2430 2875 D HeadsetClientStateMachine: Setting sampling rate as 8000
01-19 07:23:53.932 2430 2875 D HeadsetClientStateMachine: hf_volume 11My sample rate is 8000, because I setup “AT+BAC=1\r” ?
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 
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:
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
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.
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 permittedAnything 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=falseOk, 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)
