Develop Reference

How to use AudioTrack.getTimestamp() on Android to calculate latency?

I see many resources recommending that AudioTrack.getTimestamp() be used on modern Android versions to calculate audio latency for audio/video sync.
For instance:
https://stackoverflow.com/a/37625791/332798
https://developer.amazon.com/docs/fire-tv/audio-video-synchronization.html#section1-1
https://groups.google.com/forum/#!topic/android-platform/PoHfyNK54ps
However, none of these explain how to use the timestamp to calculate the latency? I'm struggling to figure what to do with the timestamp's framePosition/nanoTime to come up with a latency number.

So prior to this API, you would use AudioTrack.getPlaybackHeadPosition() which was just an approximation. Thus, to account for latency you had to offset that value with a latency value from one of two hidden methods: AudioManager.getOutputLatency() or AudioTrack.getLatency().
With the new AudioTrack.getTimestamp() API, you get a snapshot of the playhead position at a given time, taken directly at the output. As such, it is fully accurate and already accounts for device latency. Thus there's no need to call any other APIs now to add/remove latency.
The caveat is that this timestamp is only a snapshot, and the docs recommend you don't call this new method very often. So the trick to getting the "current" position is to use your last snapshot and linearly interpolate what the current value should be:
playheadPos = timestamp.framePosition +
(System.nanoTime() - timestamp.nanoTime) * samplerate / 1e9;
This position can then be compared against how many frames you've written into the AudioTrack, by maintaining another counter which increments every time AudioTrack.write() completes:
int bytesWritten = track.write(...);
writtenPos += bytesWritten / pcmFrameSize;
If you're working with ENCODING_AC3, the playhead position reported by AudioTrack is still in terms of samples. You will either need to convert it to bytes, or convert the number of bytes you've written in back into samples. Either way, you will need to know the bitrate of your AC3 stream (i.e. 384000bps)
int bytesWritten = track.write(...);
writtenPos += bytesWritten * samplerate / (bitrate / 8);

How to set time range using seekbar

I stumbled upon this library by Anothem. Basically it provides a SeekBar similar to the default Android one, but with two thumb controls allowing a range to be selected, and some other extras as well.
As at the moment the seekbar can select range between numbers/digits but cannot be used for actual time range selection in 12 hours system like 12am-3pm.
I am tring to achieve the above but with no success.
After looking through stackoverflow i stumbled again at a similar issue but cannot seem to reuse or implement for my case.
Similarly a github repo promised to solve the issue but after running the class, i simply cannot see the changes.
Any suggestions will be highly appreciated!
Here is the class to modify.
How i used it:
RangeSeekBar rangeSeekBar = (RangeSeekBar) findViewById(R.id.seekbar);
rangeSeekBar.setRangeValues(15, 90);
rangeSeekBar.setSelectedMinValue(20);
rangeSeekBar.setSelectedMaxValue(88);

Why are you setting the range values from 15 to 90? If you are trying to depict time, you should set the range values as:
rangeSeekBar.setRangeValues(0,24 * SMALLEST_HOUR_FRACTION);
where SMALLEST_HOUR_FRACTION is the smallest block of time you can select (2 to select every half hour, 4 for every quarter hour (15 minutes), 60 for every minute).
Then, to determine the time the user selected, use:
int minHour = rangeSeekBar.getSelectedMinValue() / SMALLEST_HOUR_FRACTION;
int minMinute = SMALLEST_HOUR_FRACTION * (rangeSeekBar.getSelectedMinValue() % SMALLEST_HOUR_FRACTION);
int maxHour = rangeSeekBar.getSelectedMaxValue() / SMALLEST_HOUR_FRACTION;
int maxMinute = SMALLEST_HOUR_FRACTION * (rangeSeekBar.getSelectedMaxValue() % SMALLEST_HOUR_FRACTION);

Explanation of how this MIDI lib for Android works

I'm using the library of #LeffelMania : https://github.com/LeffelMania/android-midi-lib
I'm musician but I've always recorded as studio recordings, not MIDI, so I don't understand some things.
The thing I want to understand is this piece of code:
// 2. Add events to the tracks
// Track 0 is the tempo map
TimeSignature ts = new TimeSignature();
ts.setTimeSignature(4, 4, TimeSignature.DEFAULT_METER, TimeSignature.DEFAULT_DIVISION);
Tempo tempo = new Tempo();
tempo.setBpm(228);
tempoTrack.insertEvent(ts);
tempoTrack.insertEvent(tempo);
// Track 1 will have some notes in it
final int NOTE_COUNT = 80;
for(int i = 0; i < NOTE_COUNT; i++)
{
int channel = 0;
int pitch = 1 + i;
int velocity = 100;
long tick = i * 480;
long duration = 120;
noteTrack.insertNote(channel, pitch, velocity, tick, duration);
}
Ok, I have 228 Beats per minute, and I know that I have to insert the note after the previous note. What I don't understand is the duration.. is it in milliseconds? it doesn't have sense if I keep the duration = 120 and I set my BPM to 60 for example. Neither I understand the velocity
MY SCOPE
I want to insert notes of X pitch with Y duration.
Could anyone give me some clue?

The way MIDI files are designed, notes are in terms of musical length, not time. So when you insert a note, its duration is a number of ticks, not a number of seconds. By default, there are 480 ticks per quarter note. So that code snippet is inserting 80 sixteenth notes since there are four sixteenths per quarter and 480 / 4 = 120. If you change the tempo, they will still be sixteenth notes, just played at a different speed.
If you think of playing a key on a piano, the velocity parameter is the speed at which the key is struck. The valid values are 1 to 127. A velocity of 0 means to stop playing the note. Typically a higher velocity means a louder note, but really it can control any parameter the MIDI instrument allows it to control.
A note in a MIDI file consists of two events: a Note On and a Note Off. If you look at the insertNote code you'll see that it is inserting two events into the track. The first is a Note On command at time tick with the specified velocity. The second is a Note On command at time tick + duration with a velocity of 0.
Pitch values also run from 0 to 127. If you do a Google search for "MIDI pitch numbers" you'll get dozens of hits showing you how pitch number relates to note and frequency.
There is a nice description of timing in MIDI files here. Here's an excerpt in case the link dies:
In a standard MIDI file, there’s information in the file header about “ticks per quarter note”, a.k.a. “parts per quarter” (or “PPQ”). For the purpose of this discussion, we’ll consider “beat” and “quarter note” to be synonymous, so you can think of a “tick” as a fraction of a beat. The PPQ is stated in the last word of information (the last two bytes) of the header chunk that appears at the beginning of the file. The PPQ could be a low number such as 24 or 96, which is often sufficient resolution for simple music, or it could be a larger number such as 480 for higher resolution, or even something like 500 or 1000 if one prefers to refer to time in milliseconds.
What the PPQ means in terms of absolute time depends on the designated tempo. By default, the time signature is 4/4 and the tempo is 120 beats per minute. That can be changed, however, by a “meta event” that specifies a different tempo. (You can read about the Set Tempo meta event message in the file format description document.) The tempo is expressed as a 24-bit number that designates microseconds per quarter-note. That’s kind of upside-down from the way we normally express tempo, but it has some advantages. So, for example, a tempo of 100 bpm would be 600000 microseconds per quarter note, so the MIDI meta event for expressing that would be FF 51 03 09 27 C0 (the last three bytes are the Hex for 600000). The meta event would be preceded by a delta time, just like any other MIDI message in the file, so a change of tempo can occur anywhere in the music.
Delta times are always expressed as a variable-length quantity, the format of which is explained in the document. For example, if the PPQ is 480 (standard in most MIDI sequencing software), a delta time of a dotted quarter note (720 ticks) would be expressed by the two bytes 82 D0 (hexadecimal).

How to convert WiFi level (i.e. -45 , -88 ) in to percentage?

How to convert WiFi level (i.e. -45 , -88 ) in to percentage ?
I want to convert WiFi level in % . I get WiFi level using level ( in dBm format)
I try lot of google but not get proper ans

Problem with this is that is very dependent on the receiving antenna. Some antennas register no useable signal at -90 dBm, some already at -80. You will have a hard time finding 0% (100% strictly being 0dBm).
I have created a Wifi scanner application where I use -100dBm as 0% and 0dBm as 100%, in Java it turns into something like this (MIN_DBM being -100):
public int getPowerPercentage(int power) {
int i = 0;
if (power <= MIN_DBM) {
i = 0;
} else {
i = 100 + power;
}
return i;
}

This is what Microsoft does for dBm <> percent conversion:
https://stackoverflow.com/a/15798024/2096041
Basically -50 .. 0 dBm maps linear to 100 .. 0 %.
Like MS, i would prefer to sit on the safe side and not use -100 as 100% as some answers here suggest.

The WifiManager class has a function calculateSignalLevel, but as it states here, it results in an error if numLevels is greater than 45. Possible workaround could be something like this:
double percentage = WifiManager.calculateSignalLevel(int rssi, 40) * 2.5;
but of course, this will be in steps of 2.5 percents - I don't know your use case but maybe this is sufficient.
As others have stated, calculating percentages is problematic, and there's no simple precise solution for that.

You could derive the percentage from the signal-to-noise ratio, rather than the signal intensity alone, if this information is available. This is probably the desired metric.
An android.net.wifi.ScanResult does not publish the neccessary information (as of Dec 2012), but you might be able to get this information through other means.
Signal = Noise => unusable signal, so you could set 0dB SnR = 0%. Also you could set 10dB SnR to 90% (90% of the signal power is not drowned out in noise), and 100% = no noise at all. More generally,
p = 100% * (1 - 10^(SnR / (10dB)))

Polar Wearlink Bluetooth packet

i am looking at the code of a project called MyTracks:
http://code.google.com/r/jrgert-polar-bluetooth/source/browse/MyTracks/src/com/google/android/apps/mytracks/services/sensors/PolarMessageParser.java?r=ebc01faf49550bc9801633ff38bb3b8ddd6f5698
Now I am having problems with the method isValid(byte[] buffer). I don´t understand what exactly is he checking here. We want to know if the first byte in the array is the header containing 0xFE. I don´t quite understand the following lines :
boolean goodHdr = ((buffer[0] & 0xFF) == 0xFE);
boolean goodChk = ((buffer[2] & 0xFF) == (0xFF - (buffer[1] & 0xFF)));
return goodHdr && goodChk;
any ideas?

Ewoks is correct, refer to this blog post:
http://ww.telent.net/2012/5/3/listening_to_a_polar_bluetooth_hrm_in_linux
"Digging into src/com/google/android/apps/mytracks/services/sensors/PolarMessageParser.java we find a helpful comment revealing that, notwithstanding Polar's ridiculous stance on giving out development info (they don't, is the summary) the Wearlink packet format is actually quite simple.
Polar Bluetooth Wearlink packet example
Hdr - Len - Chk - Seq - Status - HeartRate - RRInterval_16-bits
FE - 08 - F7 - 06 - F1 - 48 - 03 64
where
Hdr always = 254 (0xFE),
Chk = 255 - Len
Seq range 0 to 15
Status = Upper nibble may be battery voltage
bit 0 is Beat Detection flag."

&0xff simply converts signed byte to unsigned int for doing the comparison

First line is checking is received buffer are starting with 0xFE as it should be with this Polar Wearable.
Second line is checking if length byte is correct as well because it's value by specification is 255-value writen is size byte..
This together is super simple verification that messages are correct (more complicated implementation would include CRC or other verification methods). cheers