-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Audio glitch on some devices (sample rate specific) #89
Comments
Pinging @danomatika to see if this issue should be filed on libpd rather? Added libpd/libpd#245 |
By looking at the dump of audioflinger through adb, we could observe severe underruns and overruns for audio glitch cases. They are negligible in other cases including hello-oboe where there is no audio glitch. |
Did you ever find a solution? I'm seeing similar things, but only when recording. I'm writing audio input out to a file using writesf and about 50% of the time I'm getting really bad crackling sounds. How are you debugging this @rpattabi? I can't figure out where to start looking - profiling the app doesn't seem to do anything (CPU usage is low). |
@cerupcat I think you're running into exact problem I was/am seeing, especially with recording. I wasn't even storing the recording. If I disable audio input, no glitch in my case. There is no easy way to debug this. As I mentioned, take a look at audioflinger dump: https://developer.android.com/ndk/guides/audio/audio-latency#verify-youre-using-a-low-latency-track. It might throw some ideas. As a workaround, I found out some devices work without glitch on specific samplerate (different from their native samplerate). Really not a sustainable solution considering the number of devices out there. A fix in libpd or pd-for-android is required for this. As mentioned no issues with oboe on these devices at any samplerate when I checked. |
Is there way to use oboe and livid together?
…Sent from my iPhone
On May 16, 2019, at 4:40 AM, Ragu Pattabi ***@***.***> wrote:
@cerupcat I think you're running into exact problem I was/am seeing, especially with recording. I wasn't even storing the recording. If I disable audio input, no glitch in my case.
There is no easy way to debug this. As I mentioned, take a look at audioflinger dump: https://developer.android.com/ndk/guides/audio/audio-latency#verify-youre-using-a-low-latency-track. It might throw some ideas.
As a workaround, I found out some devices work without glitch on specific samplerate (different from their native samplerate). Really not a sustainable solution considering the number of devices out there.
A fix in libpd or pd-for-android is required for this. As mentioned no issues with oboe on these devices at any samplerate when I checked.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@rpattabi are using a solution currently? |
@cerupcat Sorry about the very late response. Not using any solution. Just the workaround (which may not work in all cases) of changing samplerate, different from native samplerate, for specific devices. I will update this thread if there is anything better. You do too please. |
Probably integrating oboe into libpd is the long term solution for such problems. More details here libpd/libpd#284. |
Case 1: Audio glitch on
Xiaomi Redmi Note 4 (mido)
if native sample rateXiaomi Note 4 reports 48 kHz as native sample rate. However, the playback crackles with pd-for-android (1.0.2 and the recent 1.1.0) when we use this sample rate.
This issue is reproducible through
PdTest
sample project on this device. Playback is fine with lower sample rates like 44.1 kHz.This must be bug in libpd or pd-for-android since playback through oboe with native sample rate works fine without any glitches. This can be verified with hello-oboe sample project.
We have reason to believe that this is the case for all Xiaomi Marshmallow and newer devices.
Case 2: Audio glitch on
samsung SM-G960F (samsung starlte)
if 44.1 kHzThis is the reverse of case 1. This device works without audio glitch if native sample rate is used (48 kHz). However, if we use 44.1 kHz, we hear crackling.
The text was updated successfully, but these errors were encountered: