sonyxperiadev / bug_tracker

Empty repository that is used as a bugtracker for Open Devices project
52 stars 13 forks source link

[Yoshino] Playing audio via usb fails #607

Closed stefanhh0 closed 4 years ago

stefanhh0 commented 4 years ago

Platform: Yoshino Device: Lilac Kernel version: 4.14.186-24246-gd0f1425c91f6¹ Android version: android-10.0.0_r39 Software binaries version: SW_binaries_for_Xperia_Android_10.0.7.1_r1_v8a_yoshino.img Version baseband: 1307-7511_47.2.A.11.228 Build: aosp_g8441-userdebug 10 QQ3A.200605.002.A1 eng.stefan.20200627.122204²

Previously working on Don't know if it worked before or when, I have just bought a new USB C to Micro USB B cable and tried it the first time.

Description As a follow-up on https://github.com/sonyxperiadev/device-sony-yoshino/pull/159 I have bought a new cable to test audio via usb. When connecting a Sennheiser PXC 550 Headset (Micro USB B plug) via USB to my Yoshino/Lilac (USB C plug) trying to play audio is not working.

Probably because of following:

stefan@mars:~/android/pluto/lilac-bugs$ grep audio_hw_usb logcat-audio-via-usb.log 
06-27 18:47:55.115 10056 10062 V audio_hw_usb: usb_set_sidetone_gain: sidetone gain(35) decimal 3162
06-27 18:47:57.413 10056 10073 E audio_hw_usb: usb_get_usbid: error failed to open file /proc/asound/card1/usbid error: 2
06-27 18:47:57.414 10056 10073 E audio_hw_usb: parse card 1 usbid fail
06-27 18:47:57.414 10056 10073 V audio_hw_usb: usb_get_capability: for Capture:
06-27 18:47:57.414 10056 10073 E audio_hw_usb: usb_get_capability: error failed to open config file /proc/asound/card1/stream0 error: 2
06-27 18:47:57.414 10056 10073 E audio_hw_usb: usb_get_device_cap_config: could not get Playback capabilities from usb device
06-27 18:47:57.484 10056 10062 V audio_hw_usb: usb_remove_device: device(0x82000000), card(1)

As a side note, the connected headset is being charged by the phone which is something I don't like. Looked around and found not too much how to disable that, the one thing I tried was: dumpsys battery set -f usb 0 it has not the effect of disabling delivering power to the headset.

Symptoms No sound/audio via USB

How to reproduce Use a headphone with USB jack and connect it via USB to the phone, then play an audio file.

Additional context logcat-audio-via-usb.log


¹) Commit: d0f1425c91f6 can't be found on github.

²) SELinux: enforcing, the build includes following PR's

stefanhh0 commented 4 years ago

When also pullling https://github.com/sonyxperiadev/device-sony-yoshino/pull/161 and removing all USB related stuff from /vendor/etc/common_primary_audio_policy_configuration.xml

Then the USB sound card is available:

lilac:/ # cat /proc/asound/cards
 0 [msm8998tashasnd]: msm8998-tasha-s - msm8998-tasha-snd-card
                      msm8998-tasha-snd-card
 1 [P550           ]: USB-Audio - PXC 550
                      PXC 550 at usb-xhci-hcd.0.auto-1, full speed
lilac:/ # awk -v RS='\0' '{print FILENAME "\n" $0}' /proc/asound/card1/*
/proc/asound/card1/id
P550
/proc/asound/card1/state
ONLINE
/proc/asound/card1/stream0
PXC 550 at usb-xhci-hcd.0.auto-1, full speed : USB Audio
/proc/asound/card1/stream0
Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 192
    Momentary freq = 48000 Hz (0x30.0000)
  Interface 1
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 3 OUT (NONE)
    Rates: 48000
/proc/asound/card1/stream0
Capture:
  Status: Stop
  Interface 2
    Altset 1
    Format: S16_LE
    Channels: 1
    Endpoint: 3 IN (NONE)
    Rates: 16000
/proc/asound/card1/usbbus
001/002
/proc/asound/card1/usbid
1395:0046
/proc/asound/card1/usbmixer
USB Mixer: usb_id=0x13950046, ctrlif=0, ctlerr=0
Card: PXC 550 at usb-xhci-hcd.0.auto-1, full speed
  Unit: 3
    Control: name="Headset Capture Volume", index=0
    Info: id=3, control=2, cmask=0x0, channels=1, type="S16"
    Volume: min=-3060, max=0, dBmin=-1500, dBmax=0
  Unit: 3
    Control: name="Headset Capture Switch", index=0
    Info: id=3, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 6
    Control: name="PCM Playback Volume", index=0
    Info: id=6, control=2, cmask=0x0, channels=1, type="S16"
    Volume: min=-6144, max=3072, dBmin=-933, dBmax=466

The very few files that are playable in general are then as well playable via USB.

logcat-audio-plays-via-usb.log

MarijnS95 commented 4 years ago

So I was hard-pressed on blaming /proc/asound/card1/usbid even if kernel code seemed fine, until we checked the AOSP default implementation (that is also in the audio policy - we must remove it since no duplicates should exist) working properly. Adb over wifi the file indeed exists, then I scrolled up in the logs: the device is disconnected before seeing that line. This AOSP default impl is fully software, receiving a decoded PCM stream and sending it straight to the USB controller. The CAF HAL on the other end tries to configure the DSP for whatever playback and offload the entire thing from the SoC. And that's where things get messy, let's paste some logs in chronological order:

06-27 18:47:37.855     0     0 I usb 1-1 : new full-speed USB device number 2 using xhci-hcd
06-27 18:47:37.991     0     0 I usb 1-1 : New USB device found, idVendor=1395, idProduct=0046
06-27 18:47:37.991     0     0 I usb 1-1 : New USB device strings: Mfr=1, Product=2, SerialNumber=0
06-27 18:47:37.991     0     0 I usb 1-1 : Product: PXC 550
...
06-27 18:47:38.227  1026  1554 I UsbAlsaDevice: OUTPUT JACK connected: true
06-27 18:47:38.228  1026  1554 I UsbAlsaDevice: INPUT JACK connected: true
...
Then, an unfortunate crapton of expired audioserver lines...
...
06-27 18:47:38.436   776  9906 W AudioTrack: restoreTrack_l(28): dead IAudioTrack, PCM, creating a new one from getPosition()
06-27 18:47:38.439   776  9906 W AudioTrack: restoreTrack_l(28): dead IAudioTrack, PCM, creating a new one from obtainBuffer()
06-27 18:47:38.441   776  9906 E NuPlayerRenderer: AudioSink write error(-32) when writing 1064 bytes
06-27 18:47:38.442   776  9906 W AudioTrack: restoreTrack_l(28): dead IAudioTrack, PCM, creating a new one from getPosition()
06-27 18:47:38.444   776  9906 D AudioTrack: stop(28): called with 11620350 frames delivered
06-27 18:47:38.445   776   907 W AudioSystem: ioConfigChanged() closing unknown output 101
06-27 18:47:38.445   776  9232 D NuPlayer: restartAudio timeUs(7889511), dontOffload(0), createDecoder(1)
06-27 18:47:38.448   672   713 I chatty  : uid=1041(audioserver) /vendor/bin/hw/android.hardware.audio@2.0-serviceݮOK�H��J �y expire 102 lines
06-27 18:47:38.450   815  2017 V C2Store : in ~ComponentModule
06-27 18:47:38.451   815  2017 V C2Store : unloading dll
06-27 18:47:38.454   776  9906 W AMessage: failed to post message as target looper for handler 76 is gone.
06-27 18:47:38.455   776  9906 I chatty  : uid=1013(media) NuPlayerRendere identical 2 lines
06-27 18:47:38.456   776  9906 W AMessage: failed to post message as target looper for handler 76 is gone.
06-27 18:47:38.533  1026  1072 D UsbDeviceManager: push notification:Verbundenes Gerät wird über USB aufgeladen
06-27 18:47:40.764     0     0 E afe_apr_send_pkt: request timedout
06-27 18:47:40.765     0     0 E afe_send_cmd_port_start: AFE enable for port 0x7000 failed -110
06-27 18:47:40.765     0     0 E msm-dai-q6-dev soc: qcom,msm-dai-q6:qcom,msm-dai-q6-usb-audio-rx: fail to open AFE port 0x7000
06-27 18:47:40.765     0     0 E msm-dai-q6-dev soc: qcom,msm-dai-q6:qcom,msm-dai-q6-usb-audio-rx: ASoC: cpu DAI prepare error: -110
06-27 18:47:40.765     0     0 E soc_pcm_prepare: Issue stop stream for codec_dai due to op failure -110 = ret
06-27 18:47:40.766     0     0 E USB_AUDIO_RX: ASoC: backend prepare failed -110
06-27 18:47:41.789     0     0 E adm_close: ADM cmd Route timedout for port 0x7000
06-27 18:47:41.789     0     0 E MSM8998 Media1: ASoC: failed to startup some BEs
06-27 18:47:42.293     0     0 E msm_pcm_playback_close: CMD_EOS failed, cmd_pending 0x8
06-27 18:47:43.235   696  1532 I chatty  : uid=1041(audioserver) /system/bin/audioserver� expire 1 line
06-27 18:47:43.237   696  1532 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 1532 (TimeCheckThread), pid 696 (audioserver)
06-27 18:47:43.299  9967  9967 I chatty  : uid=1041(audioserver) crash_dump64 expire 2 lines
06-27 18:47:43.300   822   822 I /system/bin/tombstoned: received crash request for pid 1532
06-27 18:47:43.325     0     0 E __q6asm_cmd: timeout. waited for response opcode[0x10bcd]
06-27 18:47:43.325     0     0 E q6asm_srvc_callback: cmd = 0x10d94 returned error = 0xa sid:1
06-27 18:47:43.325     0     0 E         : q6asm_memory_unmap DSP returned error [ADSP_ENOTREADY] map handle 0xb0852968
06-27 18:47:43.325     0     0 E q6asm_audio_client_buf_free_contiguous: Memory_unmap_regions failed -1
06-27 18:47:43.325  9967  9967 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-27 18:47:43.325  9967  9967 F DEBUG   : Build fingerprint: 'Sony/aosp_g8441/lilac:10/QQ3A.200605.002.A1/eng.stefan.20200627.122204:userdebug/test-keys'
06-27 18:47:43.326  9967  9967 F DEBUG   : Revision: '0'
06-27 18:47:43.326  9967  9967 F DEBUG   : ABI: 'arm64'
06-27 18:47:43.327  9967  9967 F DEBUG   : Timestamp: 2020-06-27 18:47:43+0200
06-27 18:47:43.327  9967  9967 F DEBUG   : pid: 696, tid: 1532, name: TimeCheckThread  >>> /system/bin/audioserver <<<
06-27 18:47:43.328  9967  9967 F DEBUG   : uid: 1041
06-27 18:47:43.328  9967  9967 F DEBUG   : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
06-27 18:47:43.329  9967  9967 F DEBUG   : Abort message: 'TimeCheck timeout for IAudioPolicyService command 1'
06-27 18:47:43.329  9967  9967 F DEBUG   :     x0  0000000000000000  x1  00000000000005fc  x2  0000000000000006  x3  000000724b1ff650
06-27 18:47:43.330  9967  9967 F DEBUG   :     x4  0080000000000000  x5  0080000000000000  x6  0080000000000000  x7  0000000000008000
06-27 18:47:43.330  9967  9967 F DEBUG   :     x8  00000000000000f0  x9  00000072db9974e0  x10 0000000000000000  x11 0000000000000001
06-27 18:47:43.331  9967  9967 F DEBUG   :     x12 000000724b1ff7e0  x13 0000000000000030  x14 ffffffffffffffff  x15 0000000000000000
06-27 18:47:43.331  9967  9967 F DEBUG   :     x16 00000072dba638c0  x17 00000072dba41020  x18 000000724abc2000  x19 00000000000000ac
06-27 18:47:43.332  9967  9967 F DEBUG   :     x20 00000000000002b8  x21 00000000000000b2  x22 00000000000005fc  x23 00000000ffffffff
06-27 18:47:43.333  9967  9967 F DEBUG   :     x24 000000724b1ffd50  x25 000000724b1ffd50  x26 00000072dc5ef138  x27 00000000000fd000
06-27 18:47:43.333  9967  9967 F DEBUG   :     x28 0000000000000000  x29 000000724b1ff700
06-27 18:47:43.334  9967  9967 F DEBUG   :     sp  000000724b1ff630  lr  00000072db9f5170  pc  00000072db9f51a0
06-27 18:47:43.343  9967  9967 F DEBUG   : 
06-27 18:47:43.343  9967  9967 F DEBUG   : backtrace:
06-27 18:47:43.343  9967  9967 F DEBUG   :       #00 pc 00000000000821a0  /apex/com.android.runtime/lib64/bionic/libc.so (abort+176) (BuildId: 99d256d401014e290f38edaacced78da)
06-27 18:47:43.344  9967  9967 F DEBUG   :       #01 pc 0000000000008a74  /system/lib64/liblog.so (__android_log_assert+324) (BuildId: f50213b8f3b2fc979d7f34d2e789e295)
06-27 18:47:43.344  9967  9967 F DEBUG   :       #02 pc 0000000000010250  /system/lib64/libmediautils.so (android::TimeCheck::TimeCheckThread::threadLoop()+352) (BuildId: 93b091f88fc9cef7d1a790a3164ed033)
06-27 18:47:43.345  9967  9967 F DEBUG   :       #03 pc 00000000000137c0  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+312) (BuildId: 4c3553fbc250e29a1f8f60b47123b3b4)
06-27 18:47:43.345  9967  9967 F DEBUG   :       #04 pc 00000000000e230c  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36) (BuildId: 99d256d401014e290f38edaacced78da)
06-27 18:47:43.346  9967  9967 F DEBUG   :       #05 pc 0000000000083d98  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 99d256d401014e290f38edaacced78da)

The audioserver times out waiting for something, the DSP errors being the likely culprit...

@stefanhh0 Just in case I'd like to see the expired messages. Would you mind building with the broken caf_common_primary... configuration again, boot the device and wait a bit for logs to clear, run adb logcat -c to empty them out (over adb wifi), then start a log capture right before inserting the headphones and playing back some audio?

stefanhh0 commented 4 years ago

When removing compressed_offload in all the routes of /vendor/etc/common_primary_audio_policy_configuration.xml deep_buffer is forced which has no problems playing the files. So there is something broken in compressed_offload, however the research finding and fixing the root cause will be done in https://github.com/sonyxperiadev/device-sony-yoshino/pull/161.

Also removing all USB related entries from /vendor/etc/common_primary_audio_policy_configuration.xml is mandatory since else it is not possible to play audio files via USB connected headphones at all.

Regarding the power delivery, it seems to be the case, that there is no way preventing the phone delivering power to the headset and in consequence draining the battery from the phone.

I will put the annotated log playing a single file that fails because of compressed_offload directly to PR161.

Conclusion is, there are currently two problems:

  1. When compressed_offload is activated most ogg vorbis files can't be used.
  2. Connecting headphones via USB breaks audio.

This bug report should remain open until the issues are resolved and the fix for it has been merged back.

MarijnS95 commented 4 years ago

Also removing all USB related entries from /vendor/etc/common_primary_audio_policy_configuration.xml is mandatory since else it is not possible to play audio files via USB connected headphones at all.

That's good to know: I was initially under the impression that merely removing compressed_offload from their routes made it work: audio is decoded in CCodec, then passed as deep-buffer, but it looks like the CAF HAL doesn't play audio to USB either way.

Note that removing the entire USB configuration from /vendor/etc/common_primary_audio_policy_configuration.xml works because of my mistake: we're still including the usb configuration from the AOSP software implementation in /vendor/etc/audio_policy_configuration*.xml.

Even if we are going to look at and solve the issue in https://github.com/sonyxperiadev/device-sony-yoshino/pull/161, can you post the following logs? Don't forget to clear logs beforehand so that I'm not seeing mixups, and the files are smaller overall. This time including kernel buffers too: -b default,kernel -c.

  1. For completeness, a log of USB audio with purely PR #161. That's what you posted above, but without the expired lines;
  2. A log of USB audio without compressed_offload in the sources attribute for their routes. This is what I initially assumed working; EDIT: looks like I got that file, for a working compress-offload case with MP3 already here: https://github.com/sonyxperiadev/device-sony-yoshino/pull/161#issuecomment-650686571;
  3. A log with the USB nodes removed entirely. This is mostly to have a stable point if we ever need to look at information surrounding it.
MarijnS95 commented 4 years ago

Yeah, so we have a log for 2. in https://github.com/sonyxperiadev/device-sony-yoshino/pull/161#issuecomment-650686571, that's something we can work with:

06-28 05:32:56.881   674  7364 D audio_hw_primary: enable_audio_route: apply mixer and update path: deep-buffer-playback usb-headset
06-28 05:32:56.885     0     0 E q6core_send_get_avcs_fwk_ver_cmd: DSP returned error[ADSP_EUNSUPPORTED]
06-28 05:32:56.885     0     0 E q6core_get_avcs_api_version_per_service: failure in getting AVCS version

06-28 05:32:58.927     0     0 E afe_apr_send_pkt: request timedout
06-28 05:32:58.927     0     0 E afe_send_cmd_port_start: AFE enable for port 0x7000 failed -110
06-28 05:32:58.927     0     0 E msm-dai-q6-dev soc: qcom,msm-dai-q6:qcom,msm-dai-q6-usb-audio-rx: fail to open AFE port 0x7000
06-28 05:32:58.927     0     0 E msm-dai-q6-dev soc: qcom,msm-dai-q6:qcom,msm-dai-q6-usb-audio-rx: ASoC: cpu DAI prepare error: -110
06-28 05:32:58.927     0     0 E soc_pcm_prepare: Issue stop stream for codec_dai due to op failure -110 = ret
06-28 05:32:58.928     0     0 E USB_AUDIO_RX: ASoC: backend prepare failed -110
06-28 05:32:59.951     0     0 E adm_open: ADM open timedout for port_id: 0x7000 for [0x7000]
06-28 05:32:59.952     0     0 E msm_pcm_routing_reg_phy_stream: adm open failed copp_idx:-22
06-28 05:32:59.952     0     0 E msm_pcm_playback_prepare: stream reg failed ret:-22
06-28 05:32:59.952     0     0 E msm-pcm-dsp soc: qcom,msm-pcm: ASoC: platform prepare error: -22
06-28 05:32:59.953     0     0 E soc_pcm_prepare: Issue stop stream for codec_dai due to op failure -22 = ret
06-28 05:32:59.954     0     0 E MSM8998 Media1: ASoC: prepare FE MSM8998 Media1 failed
06-28 05:32:59.954   674  7364 E audio_hw_primary: pcm_open_prepare_helper: pcm_prepare returned -1
06-28 05:33:00.975     0     0 E __q6asm_cmd: timeout. waited for response opcode[0x10bcd]

It retries and fails many times, with a variation on the latter error messages likely as a waterfall effect on the initial configuration failure. I anyway don't understand: Analog Front End? Shouldn't USB audio be decoded to a PCM stream and sent directly over the wire, for the headphone DAC to do the digital->analog conversion?

stefanhh0 commented 4 years ago
  1. For completeness, a log of USB audio with purely PR 161. That's what you posted above, but without the expired lines;

pure-161-via-usb-logcat.log

  1. A log with the USB nodes removed entirely. This is mostly to have a stable point if we ever need to look at information surrounding it.

without-usb-config-via-usb-logcat.log

MarijnS95 commented 4 years ago
  1. Looks like that was the wrong question to ask, all we see now is: audio_hw_primary: adev_open_output_stream: ignore set device to non existing USB card, use output device(0x2) Can you try the same, this time starting the clear+capture before connecting the device?

  2. Thanks. I should have anticipated no logs at all coming from the AOSP software USB module, it "just works". (Except APM initially not understanding where to route the sound? W APM_AudioPolicyManager: getOutputForDevices() could not find output for stream 3, sampling rate 44100, format 0x1000000, channels 0x3, flags 0x11)

stefanhh0 commented 4 years ago

Can you try the same, this time starting the clear+capture before connecting the device?

logcat.log

MarijnS95 commented 4 years ago

Thanks! That's the exact same issue as 2., let's see if we can find some time to dig into it and fix it. Meanwhile I'm trying to find users on other platforms (Nile, Ganges, Tama, Kumano, Seine) with access to USB headphones or a USB DAC. Otherwise I'll buy one myself to validate all the other platforms.

06-28 14:51:57.278     0     0 E q6core_send_get_avcs_fwk_ver_cmd: DSP returned error[ADSP_EUNSUPPORTED]
06-28 14:51:57.278     0     0 E q6core_get_avcs_api_version_per_service: failure in getting AVCS version
06-28 14:51:57.279     0     0 E         : send_afe_cal_type cal_block not found!!
06-28 14:51:59.286     0     0 E afe_apr_send_pkt: request timedout
06-28 14:51:59.286     0     0 E afe_send_cmd_port_start: AFE enable for port 0x7000 failed -110
06-28 14:51:59.286     0     0 E msm-dai-q6-dev soc: qcom,msm-dai-q6:qcom,msm-dai-q6-usb-audio-rx: fail to open AFE port 0x7000
06-28 14:51:59.286     0     0 E msm-dai-q6-dev soc: qcom,msm-dai-q6:qcom,msm-dai-q6-usb-audio-rx: ASoC: cpu DAI prepare error: -110
06-28 14:51:59.286     0     0 E soc_pcm_prepare: Issue stop stream for codec_dai due to op failure -110 = ret
06-28 14:51:59.287     0     0 E USB_AUDIO_RX: ASoC: backend prepare failed -110
06-28 14:52:00.310     0     0 E adm_open: ADM open timedout for port_id: 0x7000 for [0x7000]
06-28 14:52:00.310     0     0 E msm_pcm_routing_reg_phy_stream: adm open failed copp_idx:-22
06-28 14:52:00.310     0     0 E msm_compr_configure_dsp_for_playback: stream reg failed:-22
NukeMania commented 4 years ago

Hello, i don't know if it's related but google did deprecated usb host function also my creative x7 usb dac no longer works with stock android-9.0 maple ( i can control device from phone but no sound passthrough to device via usb connection) https://source.android.com/devices/accessories/aoa2

MarijnS95 commented 4 years ago

@NukeMania That deprecation is only part of their "Open Accessory Protocol". The underlying "standard USB audio class interface" is available in our kernel and HAL, and the audio policy plus underlying code is still available in AOSP. As far as I'm aware these are two separate things and shouldn't affect the way audio over USB works, without their invention.

As for your Creative X7 you might want to capture some logs. Perhaps we can spot something interesting, even if just helping SODP (since we obviously can't touch stock).

NukeMania commented 4 years ago

@MarijnS95 thanks for explanation i wasn't sure about that once maple goes to stable phase i will gladly provide the logs as for necessary but maple is my daily driver yet i can't be involved into sodp sorry :(

edit: i didn't unlock yet :lol i just waiting impatiently over months :) i can't compromise my device until sodp goes stable phase and i don't wanna play with unofficial ports

MarijnS95 commented 4 years ago

@NukeMania No worries: you said your USB DAC is broken on stock, correct? I would love to see stock logs on USB audio :wink:

EDIT: And in case your stock maple has root, make that a logcat -b default,kernel so that we can see dmesg as well.

MarijnS95 commented 4 years ago

@NukeMania Regarding your edit: You can still grab logs on a locked device. Simply enable developer mode, enable adb debugging, connect it to a PC and run adb logcat. Pipe the output somewhere, then connect to the DAC and play some audio.

stefanhh0 commented 4 years ago

@NukeMania Maple is already pretty stable as of now on Android 10, however the SODP project itself especially on the current development branches can be considered only to be relatively stable and stability tends to fluctuate from to to time. With bigger changes it is normal that previously working features break or that there is a development time until previously working features are available again at all. That is e.g. esp. the case when one of the following situations occurs:

So Android 10 will be stable only after the project moves on to Android 11 and Linux Kernel 4.19. However Maple is already stable on Android 9, like all other phones. So you could use that one.

To set the expectations right, stable must not be mixed up with bug free. So even on a stable AOSP branch you most likely encounter bugs and/or flaws that may or may not be fixed by the developers that are involved here.

Since you put so much emphasis on that you need a stable resp. working device in your posts here then maybe SODP is not for you. However you could give it a try and return to stock any time.

NukeMania commented 4 years ago

@MarijnS95 logcat attached i don't know if it's useful but when i start playing a song then adb connection terminating logcat.log

@stefanhh0 my intention is not to open a argue but my expectations are different than yours and some of people like me, don't see phones like a toy lacking in its essential features i just waiting over months like for rild,screen and deep sleep issues those are my base expectations but based on my past experiences i don't wanna a phone that even i can't call someone if i i have to call in time so it was very embarrassing in past and I don't want to experience the same nonsense again also if i can use stock android-9.0 why i have to deal with sodp android-9.0

and i am sorry if i just muddle your bug report edit: i just did want to inform that deprecation for usb host that's all

MarijnS95 commented 4 years ago

but when i start playing a song then adb connection terminating

@NukeMania How did you connect the two together simultaneously? There's the option for wireless adb debugging (over the network), but perhaps easier is to:

  1. Clear the logs using adb logcat -c;
  2. Disconnect from the computer (in case of using a cable), connect to the DAC, and play some audio;
  3. Connect to the computer again, and collect logs.

That said, does it fall back to speakers when trying to play audio over USB?

NukeMania commented 4 years ago

@MarijnS95 you're correct i did connected the device over wifi adb it does fallback to speakers thanks for suggestion , logcat.log in attachment logcat2.log

MarijnS95 commented 4 years ago

@NukeMania Unfortunately those logs are totally different to the point where I can't even compare them with those from @stefanhh0. It is indeed quite possible that that "Open Accessory Protocol" is muddying the waters here: a lot of lines include that word "accessory" where Stefans include none. Now I assumed that shouldn't be a requirement for anything, but either the device doesn't register as soundcard until some "magic handshake" over that "AOA" protocol, or stock doesn't pick it up the sound card at all.

In contrast, this is what I expect to see, a snippet from Stefans log:

06-28 14:51:47.180  1123  1483 I UsbAlsaDevice: OUTPUT JACK connected: true
06-28 14:51:47.182  1123  1483 I UsbAlsaDevice: INPUT JACK connected: true
06-28 14:51:47.182   700   700 D APM::HwModule: createDevice: adding dynamic device type:0x4000000,@:card=1;device=0; to module primary
06-28 14:51:47.184   676   676 D audio_hw_primary: adev_set_parameters: enter: card=1;connect=67108864;device=0
06-28 14:51:47.185   676   676 V audio_hw_usb: usb_get_capability: for Playback:
[Followed by pretty much `cat /proc/asound/card${usb_card}/stream*`]

So unfortunately there's nothing I can do to help you, nor do these logs help us understand whether USB audio through the CAF HAL really works OOTB like that. Thanks for providing the logs regardless!

In any case I might as well buy a USB sound card (or even one of those cheap external dongles) to test this all out, compare behaviour on rooted stock, and get the entire thing resolved.

stefanhh0 commented 4 years ago

Fixed with: https://github.com/sonyxperiadev/device-sony-yoshino/pull/161

MarijnS95 commented 4 years ago

I'd almost ask to leave this open if it weren't for a personal note to buy a USB sound card and test it on other platforms through the CAF HAL/DSP :grin: