Big sound lag on some Android.

  • > The performance of the Apps is far much better than android making it easier to create Apps that need performance, also the colours display is super, I find much easier to create Graphics for the Game Design on iOS than Android

    Hmmm, no, absolutely not true. Maybe if you compare a $1000 iPhone with a $300 Samsung, but if you compare iPhone with similarily priced Samsung it definitely does not look better. My 4 year old S6 Galaxy still looks better than most iPhones to me, although this is obviously somewhat subjective.

    BadMario

    Sure why not, everyone has his own test in it

    Jejeje are we gonna do Apple vs Samsung match? I'm not Apple fanboy so I don't think I will be good for this.

    Just for the record, I was giving my personal opinion not general, I have my test and you have yours and every one has its own and its all cool.

    For me still looks way cleaner iPhones compared to Samsung because of the saturation is too strong on Samsungs phones, if you playing long hours with Samsung it hurts the eyes and they get tired much quickly but that's my personal opinion, but I know some people they prefer Samsung colours and its fine for me.

    Maybe if you compare a $1000 iPhone with a $300 Samsung

    Not that far, you can just compare (S8 Vs iPhone 8) they are about the same price

  • For me still looks way cleaner iPhones compared to Samsung because of the saturation is too strong on Samsungs phones, if you playing long hours with Samsung it hurts the eyes and they get tired much quickly but that's my personal opinion, but I know some people they prefer Samsung colours and its fine for me.

    You can turn off the color boost on Android in the Display settings, if that is what you refer to.

  • fredriksthlm

    Probably has to be more configurated and tuned? not sure maybe,

    I have to come back to it after I finish the iOS version as I didn't want to distract too much with the Android version, I honestly thought that I have to redo all the Graphics for Android because of the colours that's why I stay away from testing on it at the moment, I will have to look probably some tutorial to how to configure the Samsung display and test again in the future and maybe it will look smoother, not sure lets see.

    Thanks

  • Ok Constructors. More information on Android + Audio + Chrome / Webview audio lag.

    So, according to Google.

    Chrome assesses the device capabilities based on Android OS returning a value for baseLatency

    this value

    BaseLatency TEST http://rtoy.github.io/webaudio-hacks/tests/osc.html

    if the value is "high" Chrome adds a ton of latency into the audio path to avoid audio glitching.

    apparently the value returned is erroneously too high (far too high) on most of the Android phones currently out there. even on powerful phones capable of much lower latency.

    This is where the 300-400ms lag is coming from.

    Ive noted on the two phones I have direct access to

    Cubot power. Very little lag on the app.website , returns a baseLatency of 256 frames

    On the MOTO G5. 300ms lag on the app/website/ returns a baseLatency of 3200 frames.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • FYI Google are now tracking this as a Chrome issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=1014614

    It looks like it might be possible to override the base latency, but it creates an awkward problem. Firstly this is only necessary for Android; secondly if you specify too low a value on a device that really doesn't support it, you could end up with lots of audio glitches, which is worse. So using that is like rolling the dice and randomly making it either better or worse. I'm always skeptical of implementing any such measures, since we can expect the next bug report to be "when I set a low custom latency, some devices have awful audio glitches", and they'd expect us to fix that... which means going back to where we started.

  • FYI Google are now tracking this as a Chrome issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=1014614

    Oh... I raised my bug on the Android tracker but they closed it to track the issue against this bug in the Chrome tracker instead. But they stated that the bug is in Android ?? (reporting too high latencies to chrome) not in Chrome?. Unless they have maybe resolved the issue in latest Android?

    Hmm , I dont know. But it is good that Google have at least acknowledged the issue and are looking into it. (Although you would think a company the size of Google would be all over these sort of issues long before joe public starts to raise them, makes me a little nervous about the organisation there.).

  • From my testing it actually is a bug in Chrome since the bug does not appear in Samsung Internet. So it makes sense that the bug is tracked in Chrome.

    Although you would think a company the size of Google would be all over these sort of issues long before joe public starts to raise them

    Even their resources are limited compared to unleashing millions of people onto it. You're bound to find things that nobody found before.

  • There is a delay and I don’t know what to do, half a second on my device when playing sound ... It’s even funny when you press the button that something opens and the sound just starts playing ... It’s good that my games are not related to sound games but another story, I regret those who will do something related to the sound, users will scare it away and no one will install it. It's all about software developers.

  • Hi Ashley

    Did you imply that there is a way to force different lower audio latency hints to solve this issue?

    It may not be appropriate for games but the feature is ubiquitous on desktop audio apps.

    i.e. is there a way at runtime to say have a slider that the user could set the AudioContext 'latencyHint: lower to test the results.

    If audio started popping/glitching they could raise it. If there was lag without glitching they could lower it to find the best sweet spot

    Even if they had to restart the app to do so each time.

    If this could be implemented into C3 that would be awesome but Im not necessary asking for a new feature.

    just confirmation that maybe something could be done, perhaps just in scripting ???

    for those ur us who are hampered by the audio lag on android.

    I quote a response from one of the chrome developers under chrome bug 1014614

    “…your particular application, you could try constructing the AudioContext with 'latencyHint: 0.003'. Chrome will try to set the latency to about 3 ms (look at baseLatency to see what the actual value is). This may cause lots of audio glitches on your device. But it could also work well….”

    How would we do this in C3?

  • In practice 90%+ of users won't change the default. You'll either get complaints about latency, or complaints that the audio is glitching, depending on which default you choose. There isn't a good way to get it to work by default right now - I think the best thing to do is to wait and see if Google can fix it first.

  • Ashley Totally appreciate what you are saying but looking through the bug thread I dont think it is very high priority for them so I cant see it being resolved any time soon. I mean it looks like the issue has been around since the dawn of android if not at least the release of webaudio.

    Also, for audio apps users would actually appreciate the ability to set latency manually if they could improve things. again for games not such a good idea as players just want things to work. but for audio apps users would not be phased.

    What about allowing us to enter in a number (say for example 0.003) in the latency hint audio properties in place of selecting "interactive". (i believe it is allowed in the webaudio api according to the chrome dev reply previously quoted) . Could be under experimental features maybe?

  • We're going in circles here. If you set too low a latency, then you hear audio glitches instead, which is worse. So that is not a solution; it's something that works sometimes, only by chance.

    As far as I gather, the situation is that there are three classes of devices:

    1) Devices supporting low-latency audio and they say they support low-latency audio. These work fine.

    2) Devices supporting low-latency audio that don't say they support low-latency audio. These have high latency, but could have low latency if the latency is manually reduced.

    3) Devices which don't support low-latency audio and don't say they support low-latency audio. These have high latency and there is nothing that can be done about it. Manually reducing the latency will result in audio glitches.

    The only opportunity for improvement is with type 2. However these devices are lying about their capabilities, and that's the real root cause of the problem here. How do you tell them apart from type 3? I don't see any easy way to do that at all. It seems like a really hard problem. Both type 2 and type 3 say they don't support low-latency audio, and if you mix them up, type 3 will start having audio glitches.

    You can just leave it up to the user to configure the latency themselves, but most users won't bother, and they can also misconfigure it themselves, such as taking a type 1 device that works fine, and then breaking it.

    I don't see any good path to take here: the real problem is Android manufacturers misconfiguring their devices. But it is too late for devices already released. And adding user-configurable settings results in equal or worse problems.

    And even if the issue for type 2 devices is somehow fixed, there will still be type 3 devices out there with high latency, and there's nothing that can be done for them. So Android devices with high latency will continue to exist, even if the Chrome issue is fixed.

  • just to add, finally , maybe for consideration in the future,

    And adding user-configurable settings results in equal or worse problems

    this is not true for audio apps,

    all pro audio applications have facility to set the latency/audio buffer.

    this is to allow the user to lower latency as much as possible for real time playing of digital instruments when recording

    and then raise as much as needed to allow as much processing time as needed when playing back multiple tracks with effects etc without the requirement for real-time playing.

    the signal to the user that they have set the latency/buffer too low is audible glitching. i.e. The glitching is actually needed it is a good thing.

    i.e. When playing a real-time digital instrument, When the user hears the glitching after lowering the latency they would then raise the latency just a little to find the lowest viable value where there is no glitching.

    all examples in leading music production software below.

  • There's a difference between music production software and consumer apps. Audio professionals can be reasonably expected to configure the various technical settings for their software correctly. Consumers using an app cannot be expected to do that. I speak from experience of having been developing consumer software for over 10 years: if you have a setting, most people won't ever touch it; of those who touch it, many will misconfigure it and then end up coming to you for support.

    If we add an audio latency setting, for every person who uses it to fix a problem, someone else will configure it wrong, get glitched audio, and (because figuring out who to blame is actually really hard), some of them will blame you as the app developer, and some of those app developers will blame us.

    The right solution, as always, is to fix the root cause of the issue.

  • "

    If we add an audio latency setting, for every person who uses it to fix a problem, someone else will configure it wrong, get glitched audio, and (because figuring out who to blame is actually really hard), some of them will blame you as the app developer, and some of those app developers will blame us.

    "

    This, some complex settings could cause a lot of problems, has been mentioned multiple times in the past.

    But now with Scripting, that looks really good place to put all thous options or not?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)