Inaccurate timing issue

[Markus Kaczmarek]

Hello!

I'm working on an application that works as a sequencer for a drum machine.

The sequencer has sixteen steps to a bar and the time for a sixteenth note is calculated like this:

private void calculateTempo()
{
    _quarterNote = 60000/_tempo;
    _sixteenthNote = (_quarterNote/4);
}

I've had great success in controlling the internal sequencer simply by using Thread.sleep(_sixteenthNote).

Say we have a tempo of 120 BPM, this gives us 60000/120 = 500 ms => 500/4 = 125 ms per sixteenth note.

However, I'd like to output sync messages to external devices via MIDI.

MIDI expects to recieve these messages of 24 Pulses Per Quarter note, this is 6 pulses per sixteenth note.

This means 125/6 ~=20.83333......

I've successfully output the timing messages via an outputstream and managed to recieve a tempo. It plays, but it drifts heavily +- 1,5 BPM

Thread.sleep only accepts milli seconds for parameter and it would appear I need something more accurate than this handy feature.

I've been told that this kind of accuracy is virtually impossible to reach with a system like Android. 

The OS, VM, multithreading, etc are too much of a load for this low-level approach.

Would it be necessary to use a peripheral unit like maybe a PIC or 555 timer to accomplish this?

Regards

/M

[Ytai Ben-Tsvi]

First of all, Thread.sleep() has an overload that takes nanaoseconds as a second argument.

Second, the amount of jitter you'll see depends a lot on the way you connect the IOIO to the Android. OpenAccessory is the best for this purpose.

Regarding whether or not Android is suitable for that, it has nothing to do with "load" as you put it. It has to do with how responsive the OS is. Simply bumping the priority of the IOIO thread (using Thread.currentThread().setPriority(Thread.MAX_PRIORITY)) from your setup() method might be enough.

Try and see...

Otherwise, you can achieve perfect precision with custom firmware.

/M

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ioio-users+...@googlegroups.com.
To post to this group, send email to ioio-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ioio-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[LimitlessLED LED]

i can get millisecond timing with android and ioio

it all depends how you code it

tip, dont create any new variables in the loop, else the gc will cause stutter

also you need a wait command  and use a timer not a sleep command.

[Markus Kaczmarek]

Whoops, little typeo there.

I'm currently using Timer.scheduleAtFixedRate for my timing clock messages. I'll try to use System.nanotime or the nanosecond overload of Thread.sleep instead.

I finally got my firmware upgraded and now I can use OA. The multiplexed keyboard I asked about a while ago is a lot more responsive now. :)

I have several threads running, Is it enough to set the one that requires the most attention to max priority or do I need to set the IOIO main activity to a higher priority too?

[LimitlessLED LED]

you can run a loop sleeping for 30ms, and when you get closer to your required time slice, you can then run it in a tight 1ms loop.

ive seen that done in few java realtime programs.

also you can keep a nanosecond timer of how long your routine took to run, and subtract that off your next timeslice.

[LimitlessLED LED]

OA is not an option, as there is bugger all devices that support it. 

[LimitlessLED LED]

out of 36 android 4.0.3 or higher devices I tested, only 2 supported OA.  

[Ytai Ben-Tsvi]

Would you please share which models you've tested with?

I think that for the most part mainstream devices with Android 4.x do have support.

[Rich Mayfield]

Hamish,

Can you share how you coded a loop to achieve that timing? 

-Rich