Playing sound with flash.media.Sound.loadPCMFromByteArray generates clicks

[delahee]

Hello !

I tried multiple entry points for sound playing api, so far it works realllly well.

One minor hiccups is loadPCMFromByteArray, when I load a file and play it with this API on windows - debug, there is a "click" on sound startup ( I guess some buffers or setup is not okay )
Other entry points like :

new lime.media.AudioSource( lime.media.AudioBuffer.fromBytes( ))
flash.media.Sound.fromFile()
new lime.media.AudioSource( lime.utils.Assets.getAudioBuffer())
flash.media.Sound.fromAudioBuffer( lime.media.AudioBuffer.fromBytes( ))

Do work flawlessly withut glitch/click though so it's really a loadPCMFromByteArray thing.

I'll change my sound path but you may want to have a look at loadPCMFromByteArray
Thanks a lot.

ps : I use openfl for lime-switch stuff

Keep me posted if you want a full reproducible example with source, I'll upload something
Bye and thanks a lot for the awesome work.

gallop_loop.zip

[jgranick]

Thanks for letting us know 😄

You said it works if you use AudioBuffer, does your code look at all like this code from loadPCMFromByteArray?

https://github.com/openfl/openfl/blob/develop/src/openfl/media/Sound.hx#L500-L504

[delahee]

Sorry I havent understood clearly :) The source with the glitch is the one you linked. Me, I l fell back on : flash.media.Sound.fromAudioBuffer( AudioBuffer.fromBytes( ... )) So I kinda guess something diverges in the loadpcm scenario :) Keep me posted if you want a full sample. Bye :) Le mer. 6 mars 2019 à 19:37, Joshua Granick <notifications@github.com> a écrit :

…

Thanks for letting us know 😄 You said it works if you use AudioBuffer, does your code look at all like this code from loadPCMFromByteArray? https://github.com/openfl/openfl/blob/develop/src/openfl/media/Sound.hx#L500-L504 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2144 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnVXAk-ASuKUtNcRQoXPdyTWqvwRE5Fks5vUArmgaJpZM4bg5yf> .

[jgranick]

Okay! Thank you 😄

Using your description, I reproduced the problem. Flash has the same problem!

Turns out, the loadPCMFromByteArray method does not expect the WAV file container. When try copying the bytes for your sound to position 736 (which appears to be the offset to the initial data), the click goes away.

Use the loadCompressedDataFromByteArray method and we'll use AudioBuffer.fromFile internally to decode the file and advance automatically around the file headers 😉

[delahee]

Oh okay I never heard the glitch/click in my flash version of Dkh, it is interesting. Thank you for your time. ❤ Le mer. 6 mars 2019 à 22:00, Joshua Granick <notifications@github.com> a écrit :

…

Okay! Thank you 😄 Using your description, I reproduced the problem. Flash has the same problem! *Turns out,* the loadPCMFromByteArray method does *not* expect the WAV file container. When try copying the bytes for your sound to position 736 (which appears to be the offset to the initial data), the click goes away. Use the loadCompressedDataFromByteArray method and we'll use AudioBuffer.fromFile internally to decode the file and advance automatically around the file headers 😉 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2144 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnVXLPoUZnuubO8Jcg8_PJX9g3ciGiHks5vUCxvgaJpZM4bg5yf> .

[delahee]

After checking I skipped the header in my actual code. Nevermind I ll submit a full example after a few checks around your lead. Thanks! Le mer. 6 mars 2019 à 22:03, David Elahee <david.elahee@gmail.com> a écrit :

…

Oh okay I never heard the glitch/click in my flash version of Dkh, it is interesting. Thank you for your time. ❤ Le mer. 6 mars 2019 à 22:00, Joshua Granick ***@***.***> a écrit : > Okay! Thank you 😄 > > Using your description, I reproduced the problem. Flash has the same > problem! > > *Turns out,* the loadPCMFromByteArray method does *not* expect the WAV > file container. When try copying the bytes for your sound to position 736 > (which appears to be the offset to the initial data), the click goes away. > > Use the loadCompressedDataFromByteArray method and we'll use > AudioBuffer.fromFile internally to decode the file and advance > automatically around the file headers 😉 > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#2144 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAnVXLPoUZnuubO8Jcg8_PJX9g3ciGiHks5vUCxvgaJpZM4bg5yf> > . >

[jgranick]

I did just add some code to handle the number of samples specified. Perhaps we were adding a click at the end of the file, not before, or weren't handling the offset properly. Does Flash respect the position of the incoming byte object?

[delahee]

Yep position is respected in flash. I ll reproduce tomorrow and will keep you posted if we have to reopen. Thanks :) Le mer. 6 mars 2019 à 22:09, Joshua Granick <notifications@github.com> a écrit :

…

I did just add some code to handle the number of samples specified. Perhaps we were adding a click at the end of the file, not before, or weren't handling the offset properly. Does Flash respect the position of the incoming byte object? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2144 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnVXEsEaFCX-49Auf5sbwULOhCR5kU8ks5vUC6JgaJpZM4bg5yf> .

[jgranick]

I just made some commits that I think may help 😄

[delahee]

Aww thanks Le mer. 6 mars 2019 à 22:26, Joshua Granick <notifications@github.com> a écrit :

…

I just made some commits that I think may help 😄 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2144 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnVXF7iyhrlcml-gAwxTO19fOI8OPSEks5vUDKEgaJpZM4bg5yf> .

[delahee]

Okay I confirm that the bug was caused by position not taken into account. I am testing the fix right now.

[delahee]

Something else I just discovered, on cpp target haxe.io.input does not advance bytearray position, which was the cause of the bug on my side. I'll investigate.

[delahee]

And okay I fixed my wav reader to retain byteinput pos rather than byte array pos ( and retrieved your fix ) and everything works.
Thank you very much :)