I am testing Soundpool on a Moto-E running 5.1. It often starts with excellent latency - but then the audio begins hanging for a hundred milliseconds or more with the following message:
06-26 15:03:49.213 3865-9536/? E/DEBUG MESSAGE: Play Note BEFORE
06-26 15:03:49.331 299-876/? D/audio_hw_primary: out_set_parameters: enter: usecase(0: deep-buffer-playback) kvpairs: routing=8
06-26 15:03:49.331 299-876/? V/msm8916_platform: platform_get_output_snd_device: enter: output devices(0x8)
06-26 15:03:49.331 299-876/? V/msm8916_platform: platform_get_output_snd_device: exit: snd_device(headphones)
06-26 15:03:49.331 299-876/? D/audio_hw_extn: audio_extn_set_anc_parameters: anc_enabled:0
06-26 15:03:49.331 299-876/? E/soundtrigger: audio_extn_sound_trigger_set_parameters: str_params NULL
06-26 15:03:49.334 3865-9536/? E/DEBUG MESSAGE: Play Note AFTER
The DEBUG messages are mine. The others are system generated. Notice I am losing over 100ms. I checked my sample rate and it is good. It also doesn't happen for every note. May I ask if anyone is familiar with this type of error?
It is not an error. Your phone enters in sleep mode: you can stream music with long buffers (via the deep_buffer) and between each buffer refill, your CPU enter to sleep.
It is a normal behavior to spare the battery.
A quick solution is to comment the section containing the flags AUDIO_OUTPUT_FLAG_DEEP_BUFFER in the $system/etc/audio_policy.conf:
deep_buffer {
sampling_rates 8000|11025|12000|16000|22050|24000|32000|44100|48000
channel_masks AUDIO_CHANNEL_OUT_STEREO
formats AUDIO_FORMAT_PCM_16_BIT
devices AUDIO_DEVICE_OUT_EARPIECE|AUDIO_DEVICE_OUT_SPEAKER|AUDIO_DEVICE_OUT_WIRED_HEADSET|AUDIO_DEVICE_OUT_WIRED_HEADPHONE|AUDIO_DEVICE_OUT_ALL_SCO|AUDIO_DEVICE_OUT_AUX_DIGITAL|AUDIO_DEVICE_OUT_PROXY|AUDIO_DEVICE_OUT_LINE
flags AUDIO_OUTPUT_FLAG_DEEP_BUFFER
}
Or, to use a soft like this one https://forum.xda-developers.com/apps/magisk/module-universal-deepbuffer-remover-t3577067
Related
I am trying to get audio working on a board to which we're porting Android.
Currently, sounds played with usages such as USAGE_ALARM (4) are audible, whereas sounds played with usages such as USAGE_MEDIA (1) are silent.
For the audible usages, we can see calls to the Audio HAL:
...
D AudioFlinger: Client defaulted notificationFrames to 11025 for frameCount 22050
D AF::TrackHandle: OpPlayAudio: track:64 usage:4 not muted
D audio_hw_primary: out_set_parameters: enter: kvpairs: routing=2
D audio_hw_primary: out_set_parameters: exit: code(0)
I audio_hw_primary: start_output_stream_primary... 0xf3856000, device 2, address , mode 0
I audio_hw_primary: select_output_device(), headphone 0 ,headset 0 ,speaker 2, earpiece 0,
I audio_hw_primary: get_card_for_device adev: 0xf3828000, device: 2, flag: 0, card_index: 0xf3856158
W audio_hw_primary: card 0, port 0 device 0x2
W audio_hw_primary: rate 48000, channel 2 period_size 0xc0
W StreamHAL: Error from HAL stream in function get_presentation_position: Operation not permitted
...
Whereas for silent usages, we see only:
...
D AudioFlinger: Client defaulted notificationFrames to 11025 for frameCount 22050
D AF::TrackHandle: OpPlayAudio: track:65 usage:1 not muted
W StreamHAL: Error from HAL stream in function get_presentation_position: Operation not permitted
...
I thought that /vendor/etc/audio_policy_configuration.xml might be important. I've paired it back to just having one output, but nothing has changed.
<attachedDevices>
<item>Speaker</item>
...
<defaultOutputDevice>Speaker</defaultOutputDevice>
<mixPorts>
<mixPort name="primary output" role="source" flags="AUDIO_OUTPUT_FLAG_PRIMARY">
<profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
samplingRates="48000" channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
...
<devicePorts>
<devicePort tagName="Speaker" type="AUDIO_DEVICE_OUT_SPEAKER" role="sink" >
</devicePort>
...
<routes>
<route type="mix" sink="Speaker"
sources="primary output"/>
What part of AOSP is responsible for the routing of different usages?
Why do some work and other are silent?
I have a custom android AOSP ROM with a peculiar problem: The volume can only be set to either 0% or 100%. As a result, the volume buttons just turn the sound on or off. If I use the volume slider instead, and the volume is not muted, it jumps immediately to 100%. The volume is not reduced even momentarily.
Interestingly, the volume for ringtones and alarms is not affected and can be set as usual.
The problem occurs via headphones, internal speakers, and HDMI out.
I tried setprop ro.config.media_vol_steps 30, and that does work in that it changes the number of volume steps in the slider - but it does not affect the output volume. I found nothing in logcat, this is the only suspicious thing (I set the volume via slider to a low value):
02-08 06:18:43.117 1813 2298 V audio_hw_primary: out_set_parameters: routing=1024
02-08 06:18:43.670 22493 22493 I vol.Events: writeEvent touch_level_changed STREAM_MUSIC 3
02-08 06:18:44.127 22493 22493 I vol.Events: writeEvent touch_level_done STREAM_MUSIC 3
02-08 06:18:46.575 22493 22493 I vol.Events: writeEvent dismiss_dialog touch_outside
02-08 06:18:46.581 22493 24066 I vol.Events: writeEvent active_stream_changed UNKNOWN_STREAM_-1
02-08 06:18:46.695 1813 2298 V audio_hw_primary: out_set_parameters: routing=1024
02-08 06:18:49.842 1813 2298 D audio_hw_primary: out_standby
What could cause this? E.g. does the hardware report the current volume back to the UI (then it could be a driver problem)?
In your ROM, a fixed-volume (full) is set. Its a resource configuration. Usually done for HDMI devices.
I have a MusicService for MediaPlayback, wich uses a MediaPlayer with the settings:
player.setWakeMode(getApplicationContext(), PowerManager.PARTIAL_WAKE_LOCK);
player.setAudioStreamType(AudioManager.STREAM_MUSIC);
and those Listeners are set:
OnPreparedListener, OnCompletionListener, OnErrorListener, OnSeekCompleteListener
The MediaPlayer is used for mp3-Playback. When one Song is finished, onCompletion is called. Then PlayNext is called, wich resets the MediaPlayer, then sets the Datasource with the URI of the next Track. Uri is loaded with:
Uri trackUri = ContentUris
.withAppendedId(android.provider.MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, songId);
Then the Player is prepared, then the player is started. This is working fine, but only sometimes, when the Device is locked and played about 1-3 Songs while it was locked and the next Song should start, the Player doesn't prepare until i hit the power button. Figured out, that if I don't hit the PowerButton it takes the Player about 2 Minutes to prepare.
I've Logged everything now and made a few custom outputs with Log.e(...).
This is put out before prepare() (prepareAsync() delivers the same result) is called:
E/MusicService: Preparing now...
This is put out, when onPrepared is called:
E/MusicService: Player prepared.
So this is the full Device-Output after "Preparing now..." is put out:
04-02 13:54:55.506 12517-12517/at.htlleonding.musync E/MusicService: Preparing now.
04-02 13:54:55.525 811-888/? E/libsuspend: Error writing to /sys/power/state: Device or resource busy
04-02 13:54:55.544 246-14756/? D/offload_visualizer: thread exit
04-02 13:54:55.546 246-14754/? V/offload_effect_bundle: offload_effects_bundle_hal_stop_output output 1879 pcm_id 9
04-02 13:54:55.546 246-14754/? D/hardware_info: hw_info_append_hw_type : device_name = speaker
04-02 13:54:55.549 246-14752/? E/audio_hw_primary: offload_thread_loop: Compress handle is NULL
04-02 13:54:55.549 246-924/? D/audio_hw_primary: adev_close_output_stream: enter:stream_handle(0xb5bfa640)
04-02 13:54:55.549 246-924/? D/audio_hw_primary: out_standby: enter: stream (0xb5bfa640) usecase(3: compress-offload-playback)
04-02 13:54:55.555 246-924/? W/AudioFlinger: moveEffectChain_l() effect chain for session 0 not on source thread 0xb59fa000
04-02 13:54:55.611 246-15030/? I/FFmpegExtractor: android-source:0xb1834060
04-02 13:54:55.820 811-888/? E/libsuspend: Error writing to /sys/power/state: Device or resource busy
04-02 13:54:55.972 246-15030/? I/FFMPEG: [mp3 # 0xae2f4400] Skipping 0 bytes of junk at 2177007.
... Then theres no output until i hit the PowerButton. Then the Song is prepared.
If someone is interested in the full output after I hit the PowerButton until "Player prepared" is called, I created a Gist here.
Sidenote:
While the App is used, a few Album-Covers are displayed in some Fragments. They are loaded with Picasso, so I don't need to worry about memory caching. Some ImageViews are filled without Picasso (for example the ImageViews that hold the drawables of my PlayerControls). Maybe there are Problems with the memory/resources?
I might have found the answer in another thread where some faced the same problem while streaming music here.
My final solution is to use a WakeLock, wich I require before preparing a Song and release again onPrepared and onError and onDestroy of my Service. It's important to release it again to save Battery. Make sure to check if the WakeLock is held before releasing it.
I create my WakeLock like this in onCreate of my Service:
PowerManager pm = (PowerManager) getApplicationContext().getSystemService(Context.POWER_SERVICE);
wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MusicService");
aquire:
wakeLock.acquire();
release:
if(wakeLock.isHeld())
wakeLock.release();
Tested the Playback now for about 10 Minutes and didn't stop until now. I don't know if this is a very battery-saving solution
I have a problem seeking HLS (.m3u8) playlist on native VideoView.
I've built an Activity that when pressing on ImageView it opens up a new Activity via Intent and start playing an HLS video using native VideoView (I'm aware of the issues with HLS on Android) but when going back to Activity A after seeking in Activity B, Activity A freezes GUI for approx. 30 seconds (When pressing on UI element in Activity A, I see ANR) and then it "release" the GUI again.
Problem is when I try to use :
mVideoView.seekTo(position);
mVideoView.start()
UI in Activity B seems OK, video will not seek actually freezes and when I back pressed I get this:
LogCat:
Shutting down current MediaPlayer
System.outīš Close in OkHttp
[CDS]close[41023]
[CDS][DNS] getAllByNameImpl netId = 0
[getaddrinfo]: hostname=31.168.5.3; servname=(null); cache_mode=(null), netid=0; mark=0
[getaddrinfo]: ai_addrlen=0; ai_canonname=(null); ai_flags=4; ai_family=0
[CDS]rx timeout:60000
[socket][3] connection /31.168.5.3:8089;LocalPort=47817(0)
[CDS]connect[/31.168.5.3:8089] tm:90
ANR Key Analyze: No Key event currently.
ANR Key Analyze: Previeous Event null,finish at 1970-01-01 02:00:00.000`
And After approx. 30 seconds:
[CDS]EAGAIN in Recvfrom
[CDS]read byte is 0
surfaceDestroyed callback -, this = com.brightcove.player.view.BrightcoveSurfaceView{8b5c8c0 V.E..... ........ 0,8-1280,728}
Layout: x=0 y=8 w=1280 h=720, frame=Rect(0, 0 - 1280, 720), this = com.brightcove.player.view.BrightcoveSurfaceView{8b5c8c0 V.E..... ........ 0,8- 1280,728}
It looks as if the connection when setting Video Uri is keeping a connection open and only a timeout releases it or something like this.
It happens only on one device, Lenovo 7-inch Tablet with OS 5.0 (Lollipop), on other it does not happen.
Also, when playing regular mp4 streams I didn't encounter this problem.
Any help will be appreciated.
I'm using an extra thread for AudioTrack to play back a wave file I have previously recorded in another activity.
When I start playback, I get the following output in LogCat:
09-13 09:13:13.207: WARN/Archive(1066): audioplayThread is running..., state is: READY
09-13 09:13:21.187: WARN/Archive(1066): wave file /mnt/sdcard/myrecording/myrecording_3_12-09-2011_14-14.wav
09-13 09:13:22.582: WARN/Archive(1066): audioPlayer bufferSize 4090
09-13 09:13:22.582: WARN/Archive(1066): audioPlayer wave length 206432
09-13 09:13:22.601: DEBUG/AudioHardware(75): AudioHardware pcm playback is exiting standby.
09-13 09:13:22.601: DEBUG/AudioHardware(75): openPcmOut_l() mPcmOpenCnt: 0
09-13 09:13:22.683: WARN/AudioFlinger(75): write blocked for 82 msecs, 1 delayed writes, thread 0xcb08
09-13 09:13:24.816: WARN/Archive(1066): playbackHeadposition is: 49591
09-13 09:13:24.816: WARN/Archive(1066): audiostate is: 3
09-13 09:13:26.089: WARN/AudioTrack(1066): obtainBuffer() track 0x298b18 disabled, restarting
09-13 09:13:27.214: WARN/AudioTrack(1066): obtainBuffer() track 0x298b18 disabled, restarting
09-13 09:13:28.332: WARN/AudioTrack(1066): obtainBuffer() track 0x298b18 disabled, restarting
09-13 09:13:29.457: WARN/AudioTrack(1066): obtainBuffer() track 0x298b18 disabled, restarting
...
I just saw the logcat: obtainBuffer() track 0x298b18 disabled, restarting ..
that is to say : you have not got audio data and the input audio stream have been stopped .so the buffer must wait for the audio stream in. i think you should check the inputstream and the read method. you must ensure that you have read the audio data continuously.
I've had the same problem before. I used vitamio bundle which is a counterpart of Android's Media Player and has more audio support. Try adding this code to your manifest:
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
I hope this helped.
I have observed the same issue when number of written samples is not divisible by number of channels.
For example:
number of channels: 2
mAudioTrack.write(buffer, 0, 75);