Android App

Walt - KZ1F

was the mic and headset Android, in other words you got Opus properly wired?

W4WHL

No i wish.  I have no idea how to compile the codec using NDK, so I have to wait till its natively supported in android 5.

Unless you have some advise on this subject.

William
W4WHL


Walt - KZ1F

I thought your, whatever it is, had been updated. Do you know if it even will be updated?

W4WHL

Yes its in development, no date given for update.  My phone has upgraded to Android 5, but don't really want to develop on my phone.

William

Walt - KZ1F

Well, here is a thought. You said you were using Android Studio. Make a virtual device that runs Lollipop.  You should be able to define your tablet and tell it that it has 5.1, I think that is 23. So, as far as testing it, on that device, yes, that would be iffy for now but you can test it in the virtual device.

W4WHL

There is a bug with the VM.  UDP forwarding does not work. I have tried everything, but no luck with the emulator for UDP.

William

Walt - KZ1F

William, I thought you'd like to see. This was a test I did awhile back. Now I know how to upload, I thought you'd like to see this. It was a very static filled night.
https://www.youtube.com/watch?v=skxUt866pGo

W4WHL

Nice

W4WHL

It looks similar to one of my java test on the PC.  Thanks for the metering code snippet in the other thread.  I see now that each 32 bit word is made up of a 16bit meter ID and a 16 bit value. 

My biggest hurdle is finding what I need in the API code.  Not being a programmer, its hard for me to find this stuff.  But once shown I learn quick.  I'm having fun with it.

William

Ken - NM9P

Very nice, Walt. William, have you considered using just one dot on the panadapter trace instead of a whole bar? Would it save any processing juice? I actually prefer the line trace rather than the whole "filled under the trace" way. But I'm aware that people are pretty passionate about their preferences in this matter. Ha.

Walt - KZ1F

At the end of the day WIlliam, that is what counts. I will take a stab at Ken's question, likely not as the GPU is passed the data. Aside from that it is expecting an image and that is what is sent from the radio. It is, essentially incredibly inexpensive.
1) get it working, 2) get it working correctly, 3) if, AND ONLY IF, there is a performance issue, find the hot spot and optimize it. In a week or so I will have the Opus code done.

W4WHL

Nice, are you compiling based on Opus source code, writing your own, or using Android 5?

Ken, not sure what you mean by just one dot.  But if you mean a line of dots, vs a solid line, it makes no noticeable difference at all. Going from a mini waterfall to almost full screen, had no noticeable affect at all either. 

I like my rainbow panadapter, I think I will keep that for now.  Time to move on and tackle a new thing.  Next is metering. 

William

W4WHL

Also, I plan on using my own waterfall for now, and not use the waterfall tile from the radio.  Since I don't want or need off screen data.   The entire waterfall is only about 15 lines of code  One less vita packet I have to process.

Not sure if this is the best idea, and may revisit it later, but for now I'm perfectly happy with what I have working.

William

Walt - KZ1F

The nice thing about being author is it will follow you're every whim.

Walt - KZ1F

Android and Linux

Walt - KZ1F

Frankly the whole remote thing is relatively meaningless on Linux, although it does run on my laptop so...maybe but I'll use my tablet instead. The technology of this laptop is pre-Li-Ion.

W4WHL

Fullscreen Panfall with S-Meter

https://www.youtube.com/watch?v=uflJTYRSbhA

Sorry about the bright waterfall, the camera makes it way brighter than it is in person

Ken - NM9P

I like it! I never would have thought of the color shift on the panadapter trace. Nice touch. I like the color shift on the waterfall that SSDR has, this does it one better, especially for times when not using the waterfall. Too bad you can't port this over to iPad! I would love to play with it. Ken - NM9P

W4WHL

Testing the Android App with the CMD micro.  This was a simple test of some new code.  As you notice in the video.  The waterfall no longer shifts with frequency.  Instead the frequency line marker moves.  The waterfall recenters  when you run the frequency marker off screen.  I'm just using the CMD micro to tune around to test the code.  Eventually the code will be updated to move the frequency by swiping the screen.


https://www.youtube.com/watch?v=jmoz_L_WM_g

W4WHL

I just bought a new Samsung Galaxy tab S 10.5.  This tablet is a dual processor 1.9 ghz Quad core and a 1.3 ghz Quad core.

Exynos™ 5 Octa ( A13 1.9Ghz Quadcore + A7 1.3 Ghz Quadcore)

 Lollipop 5.02 is also now available.  So time to get working on that OPUS audio

William

Ken - NM9P

Oh boy!  the fun starts!
Congrats on the new tablet.

James Whiteway

Good deal! I've been looking at the same tablet. Nice, very thin and great screen res , with pretty good battery life. james WD5GWY

DH2ID

Hi William, I've got the same one. Runs really fast. Now the only thing missing is just your App...

W4WHL

Walt,

Maybe you can help me with something!

I am trying to scale my waterfall correctly.  Lets say I have the following;
screen px witdh =2560
screen dp witdh =1280
surfaceview width dp = 1248
surfaceview width px = 2496

We have a ratio of px/dp = 2

So based on this I create a waterfall stream based on surfaceview dp width of 1248, x=1248.

I set paint strokewidth to 2, so that 2 real pixels are colored for each dp.  so when drawing my points I will draw first pixel at 0, second at 2, 3rd at 4, etc.  But for some reason there is a fine spce between the points that causes 1000+ little black lines in the waterfall.

Of course I can up the **** width to account for this, but I want the **** width to be dynamic based on the surfaceview dp size.  This way the app will work with all 1280dp wide screens.

On galaxy tab 4 which has a px width of 1280, and a dp width of 1280, the ratio is 1:1.  Setting **** width to one fo this display works fine.  But on my new tablet with a 1280dp w and 2560px w display, I get the fine horizontal lines.  So why doesn't setting **** width to (px/dp) work?

I hope the above makes any since.  Any ideas?

William

James Whiteway

William, I thought that the higher res tablets like the Galaxy upconverted the resolution on apps that were written at a lower resolution. Or maybe, I'm just dreaming. Is there a function in Java that could check the resolution of the device that an application is running on and set the app's resolution accordingly?
james
WD5GWY

(forgive my ignorance if this turns out to be a dumb question!)

W4WHL

James you have to scale the app yourself.  But there are methods to do this.  Android uses density pixels for most things.  For example all 10" tablets have a DP of 1280x800 regardless of actual pixel count.

However when drawing in a Surfaceview, it uses actual pixels.  However I want my surfaceview to use density pixel values.

My issue was using paint strokewidth.  To scale all my values for a surfaceview with a higher res screen I was using this math scale=ScreenRes/DPRes.  I would then multiply all my values by scale. 

The issue I discovered was, strokewidth of 1 is not really 1 pixel.  Took me forever to find this.

So the new math is scale=(ScreenRes/DPRes) +0.5f
Pixel width = 2560
DP width = 1280
so scale = (Pixel Width/DP Width)+0.5f = 2.5, so now to paint 1 density pixel, I set paint.strokewidth(scale);

Don't ask me how this works, as I could only find the formula, and no reference to why.  But it solved my issue.

William



So this issue has been solved,

W4WHL

I had limited success with audio today.  I was able to get dax (floating point) audio working sort of.  I get audio, but its extremely choppy.  This can be a couple things, but I think its related to how fast my app processes the network data.  I have to play some more.  The audio sounds like pauses between packets, so it has a stuttering choppy sound.  Anyone have any ideas what I could look at?

I had zero success with OPUS, I just can't get the decoder to work.  I will keep playing.

 William

W4WHL

I figured out what my DAX issue was, I have some thread blocking happening.  This is just a programming fault I will have to solve.  My waterfall draw is blocking network reads.  This is causing waits on network reads.  For a test I killed all draws from the waterfall. and the dax audio was smooth as silk. 

So now I know where the issue is, and I'm pretty sure how to solve it, but it will take some time.

It seems that working with codecs in android is some magic voodoo.  So I need to read up on implementing codecs.  But I'm fairly confident with time, I will solve opus too.

William

W4WHL

Dax audio working, i changed the threading and now no audio stuttering and full waterfall fps.


https://www.youtube.com/watch?v=a2RoJFgwTdw

Bob G W1GLV

Bill, is the waterfall version available to play with?