Good day to all.
I'm delighted to see so many names here that are familiar at my ears since I
study CSound :D
I'm developing a synth app for Android using channels, starting from the
multitouch.xy example.

I've been experiencing strange behaviours on different devices. Some people
are helping me and it appears that there are lots of glitches in some
devices (Samsung s7 edge, One plus one and others) and is perfect on others
(on my Motorola G4). I think I should increase hardware buffer. I use this
configuration:

-odac -b256 -B1024 --realtime -dm0 -+msg_color=0
nchnls=2
0dbfs=1
ksmps=32
sr = 44100

What is strange is that it looks like there is no relation about power of
the device or version of android and the problems with the buffer, that is
already very - very big (and latency is unfortunately already too much large
at 1024, it should be decreased, not increased).

How can I do to make it better? Is there a path you can suggest me to
optimize things?

Also: is it possible to programmatically change the hardware buffer after
having loaded the psd? (I can do it by loading the string and look for the
-B directive, but it sounds to me like a bit of hacking) :-)

Thank you in advance and big (very very big) compliments.



--
View this message in context: http://csound.1045644.n5.nabble.com/CSound-for-Android-glitches-tp5755508.html

Yes, and I will give the user a chance to tune his app, but I was wondering
if there was a way to fix it (and reduce the buffer) before, at build time:
would recompiling with some different parameters fix it?

Thank you and thanks for all the docs.



--
View this message in context: http://csound.1045644.n5.nabble.com/CSound-for-Android-glitches-tp5755508p5755510.html

One thing to try is also setting the CSD to 48000 for sr. I think
there are ways to interrogate the particular devices buffer sizes and
sr, then elect to use that.

On Wed, Apr 5, 2017 at 10:01 AM, Beppi  wrote:
> Yes, and I will give the user a chance to tune his app, but I was wondering
> if there was a way to fix it (and reduce the buffer) before, at build time:
> would recompiling with some different parameters fix it?
>
> Thank you and thanks for all the docs.
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/CSound-for-Android-glitches-tp5755508p5755510.html

You saved me. Thank you. I did not understand that hardware buffer is
actually something that depends from... well... hardware... and I thought it
was configurable.
Now it's easy to understand why high-end devices gave more problems.

Just do this:
        int deviceSampleRate = 44100;
        int deviceBufferSize = 1024;

        AudioManager audioManager = (AudioManager)
this.getSystemService(Context.AUDIO_SERVICE);
        try {
            deviceSampleRate =
Integer.parseInt(audioManager.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE));
        } catch (Exception e) {}
        try {
            deviceBufferSize =
Integer.parseInt(audioManager.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER));
        } catch (Exception e) {}
        softwareBufferSize = deviceBufferSize / 4;




--
View this message in context: http://csound.1045644.n5.nabble.com/CSound-for-Android-glitches-tp5755508p5755528.html