ios/safari audioContext with wrong sampleRate

[electromotif]

We're using assets in 44.1 kHz, playback in 48kHz results in crackles/pops in audio.

Observed on iphone X running ios 12.1.4, Howler 2.1.1

The Howler-internal unload() and creation of a new audioContext does not seem to cure it this time. Safari on an ipad air2 running same ios release creates an audioContext with a 44.1kHz rate. Also interesting is that playback on headphones does not have the crackling.

related to issue 434 Also see https://bugs.webkit.org/show_bug.cgi?id=154538 https://bugs.webkit.org/show_bug.cgi?id=168165

Update: recoded assets to 48kHz. Playback still crackly. 'Kill me'. :o)

[st-h]

Commenting because I think I am currently searching for a similar solution and the symptoms you describe seem very related - however, I stopped using howler very recently because the needs of our app have changed quite a bit.

My issue is described in detail here https://stackoverflow.com/questions/54982847/crackles-and-noises-when-playing-ios-web-audio-with-simple-graph

I also opened a bug within the apple bug tracker today

What I observed is:

• playback issues appear on iOS devices only (works fine on android and macOS)
• issues are independent of the browser being used (tried safari and chrome)
• issues are independent of the sample rate being used (iPad Pro consistently reports 44.1kHz, while iPhone 6s reports 48kHz - the issue can be reproduced on both at both sample rates with the same audio file)

Are you observing the degraded audio playback all the time, or does it sometimes work correctly?

[miltoncandelero]

Just to add more inconclusive info:

We are working on a game using the OpenFL toolchain, but audio is achieved using howler so it applies.

We got feedback that "after a while" the game sounds crackle and get all statick-y on an iPhone 7 (11.4) and iPhone 7 (12.1). We couldn't recreate the issue on our old AF ipad.

We found that we had 2 soundfiles that had a sample rate really low and didn't match the rest of the files (all other files where 44.1khz)

We normalized the sample rate (to 44.1) and for good measure the bitrate too (128kbps) and are waiting for more feedback. Will update as we get more info.

[electromotif]

Are you observing the degraded audio playback all the time, or does it sometimes work correctly?

We get it on our testing/qa Iphone X, and like you noticed, on Safari and Chrome.

On another Iphone X, running the same ios version, it does not appear.

iphone 7, XR and ipad is fine. At this time. :o)

[miltoncandelero]

Ok, anyone has any idea what is going on? I am panicking a little here.

I had the QA team test the sample tests from https://howlerjs.com/assets/howler.js/tests/ and they tell me that EVERYTHING sounds glitchy. Webaudio and html5 audio alike. (on an iPhone X)

[IriySoft]

Same issue here. Any ideas, anyone?..

[miltoncandelero]

Still having issues with this. Please, did anybody find any workarround?

[jacobclarke92]

Big oof on this one being a dead end so far, but I'll add my experiences. My team did work out it was caused by sample rate mismatch between 48k and 44.1k -- this mismatch can be across audio file played in or out of howler, and also includes videos.

If anyone needs to do this in bulk we wrote a quick script to make this sanity checking and fixing more manageable because we have heaps of audio files (requires mac and ffmpeg)

#!/bin/bash

linebreak="\
-----------------------------"

# get folder path
echo -n "Drag a folder to recursively scane for and fix MP3s not set to 44100 sample rate and press [ENTER]: "
read folderpath
echo "$folderpath"

# check if entered path is a folder
if [ -d "${folderpath}" ]; then

    # set foldername and basefolder vars
    foldername=`basename "${folderpath}"`
    cd "${folderpath}"

    find . -name "*.mp3" | while read fname; do
        if [[ ! $fname == *"_old.mp3"* ]]; then
            sampleRate=`ffprobe -v error -show_format -show_streams "${fname}" | grep sample_rate`
            if [ "$sampleRate" != "sample_rate=44100" ]; then
                echo "$fname"
                echo "$sampleRate"
                newName="${fname}_old.mp3"
                exec `mv "${fname}" "${newName}"`
                echo "ffmpeg -i \"${newName}\" -ar 44100 \"${fname}\""
                exec `ffmpeg -i "${newName}" -ar 44100 "${fname}" > /dev/null 2>&1`
                echo "${linebreak}"
            fi
        fi
    done

fi

Now that fixed the original "crackling" issue, however we're now experiencing a new issue that sounds like bitcrushing or distortion exclusively on iPad Pro so far ... fun times.

Chime in if any of you have any new insights after all this time!

[miltoncandelero]

Now that fixed the original "crackling" issue, however we're now experiencing a new issue that sounds like bitcrushing or distortion exclusively on iPad Pro so far ... fun times.

We had both issues. We solved the bitcrushing distortion using 48khz audio and taking the hit on the crackling noise. A bit of crackling was better than the big distortion.

Also tried using m4a, aac, ogg, MP3, and even wav audio: same issue with all.of them. We settled on leaving all formats (except wav) and letting howler do the automatic format picking in a hail Mary attempt.

[jacobclarke92]

We had both issues. We solved the bitcrushing distortion using 48khz audio and taking the hit on the crackling noise. A bit of crackling was better than the big distortion.

Oh that's quite interesting, so you're saying using 48k exclusively stopped the distortion? Because exclusively using 44.1k on audio and videos definitely stopped the crackling for us. We're only using mp3s.

Jesus just can't win hey. We're working on a big learning app for kids on the spectrum, and they can be sensitive to auditory anomalies and issues like that, it's quite the problem :(

We found more cases of crackling than distortion due to crackling only being an issue on most older iPads, but I'd say that's mostly due to parents not buying the latest greatest things for the kids -- totally expected and understandable, but I guess the scales may tip in a few years if the issues is still around.

Knowing this new information makes me think it might be possible to do device detection and swap fetching of different sample rate files but my god that'd be a big undertaking...

[jespertheend]

I'm not using howler but I am using AudioContext and seeing a similar issue. All our files are 48khz. I still haven't been able to fix this. It seems to vary between builds so I haven't been able to pin point the exact issue. One thing I do know is that I can consistently reproduce the issue by opening the web page while headphones are connected, and then disconnecting the headphones.

[Ronsku]

I'm getting crackles from following setup / device / browser combinations and there seems to be no way around it: All combinations of: Device: iPhone 5, (iOS 10), iPhone 6 (iOS 12), iPhone 11 Pro (iOS 13) Sample rate: 22.05khz, 44.1khz, 48khz, 88.2khz Bit Rate: 96kbit/s, 128kbit/s, 320kbit/s File formats: mp3, ogg Audio file: Separate & Sprited Howler.js Version: 2.1.3

Every time I get crackling sounds, no matter how I configure my sound file. Is there some configuration I can do on Howler's side to match it up with the sound files?

This is a huge problem with the sound engine, is someone looking into this?

[themoonrat]

I don't know if this is the exact issue you guys are having, but there is a known issue with iOS not resetting it's sample rate correctly, which produces the same issues you are seeing.

https://github.com/Jam3/ios-safe-audio-context

I use a variant of that hack each time the content becomes 'active' again

[miltoncandelero]

I don't know if this is the exact issue you guys are having, but there is a known issue with iOS not resetting it's sample rate correctly, which produces the same issues you are seeing.

https://github.com/Jam3/ios-safe-audio-context

I use a variant of that hack each time the content becomes 'active' again

@goldfire Any chance this can be implemented into howler? or maybe a similar workaround? (Sorry I can't pr myself, my js is really crappy :( )

[paulmasri]

Just in case it's relevant, over on the Steinberg forum they're talking about iOS sample rate issues and crackling, which they put down to the increased CPU required for sample rate conversion.

[rvanderspuy]

Having the same problem! Luckily defaulting to html5 audio has been a temporary workaround so far.

Just for context: the problem I was experiencing was just with the iPhone 5s, IOS12. The audio became gradually degraded and distorted until it didn't play at all. I was initially using a combination of 48khz and 44.1khz mp3 in my source, but normalised them to 44.1 based on the comments here. This didn't solve the problem. I'm still not sure what's going on, it the degradation is sound may be due to simply poor performance. (I'm using Howler in a physics based game, which is very CPU intensive.)

[dbFlower]

any workaround yet? having the same problem.

[ErikSom]

I also would like to find a proper work around for this one

[fknorn]

Yep, same here :( Any workaround found? I'm getting this crackling sound when using NoSleep.js together with Howler...

Update: I actually managed to solve it too. The import clue from the discussion above was that all sample rates should be the same.

In my use case, I have a bunch of files played through Howler that are synthesised voice snippets from Amazon Polly; those ship with a 24kHz sample rate. So I dug into NoSleep.js, took their hacky auxiliary base64-encoded mp4, converted it to an mp4 file, converted its audio track to 24kHz (ffmpeg -i ./video.mp4 -c:v copy -ar 24000 ./video_24000.mp4), base64-encoded it again and reinjected into NoSleep.js — and voilà, the crackling sound effect was gone!

[singham2000]

Did anyone get it working ?

[dbFlower]

已收到