getTunerVolume is a show stopper!

as it does not give fine tuned results.

from very silent environment 0.2 it jumps immediately to highest max 0.6 while just talked
with low voice. there is no way to differ between low voice and loud speaking.

it should just give same results as we would get from iOS AVFramework getpeak for channel.

any idea when this will be fixed? (there are a lot of posts in the forum about that)
thx
chris [import]uid: 4795 topic_id: 15758 reply_id: 315758[/import]

any news here? [import]uid: 4795 topic_id: 15758 reply_id: 61447[/import]

It’s 1 year we’ve been saying that gettunervolume is not working… but so far, the official answer from ansca has always been something like “gettunervolume IS working correctly, you’re just using it wrong”.

Honestly, I’ve no idea why they are not interested in looking at this problem… [import]uid: 9158 topic_id: 15758 reply_id: 61489[/import]

I see.
Same Problem here… what should we do wrong.
There is even a sample code around and
it just shows wrong values… a blind does see that

chris
[import]uid: 4795 topic_id: 15758 reply_id: 61541[/import]

+1

:slight_smile: [import]uid: 3458 topic_id: 15758 reply_id: 61580[/import]

i am on travel right now, otherwise I would do it myself:

could anyone just post a simple demo that shows the tunerVolume as numbers in realtime, to play for the AnscaTeam.

Than they could do the changes needed to make it proper running. (as they say its working).

I just expect, to see a number value from -1 or whatever … total silence and step by step increasing while speaking louder, till I have to blow strong into the mic to get the highest value. +1 or anything else as limit.

Not as now, from total silence 0.28 to normal speaking jumping up to 0.6 and thats it. nothing really in the middle and no change to get if its a really loud speaking or just normal environment sound. AND… it does work perfect on native iOS (i have several speaking apps in the market so i know what i am talking about :slight_smile:

cheers
chris

[import]uid: 4795 topic_id: 15758 reply_id: 61582[/import]

Essentially what you’re describing is the Simple Tuner example Ansca already provides in the SDK download :slight_smile: All they have to do is change a couple lines of code to spit out the raw unadjusted value from getVolume.

But yes I agree would be clear test of how the value jumps right to .58 or so, and never goes beyond…so it’s a poor way to get real volume ranges. Would be nice to fix, I already had to abandon Corona in favor of PhoneGap for a project due to the “incomplete” audio tuner implementation.

Max [import]uid: 3458 topic_id: 15758 reply_id: 61600[/import]

its really a pity

BUTTTTTT

I Wish, HOpe and guess… OUR Writing right now, may push them again to have a look into that code… they do a quiet good job… and we are all not perfect

SOOO
ANSCA>>TEAM

Check that Code again :slight_smile: We will all be very happy about… and develop some nice apps… WHEN THIS WORKS :slight_smile:

cheers
chris
[import]uid: 4795 topic_id: 15758 reply_id: 61673[/import]

I don’t know… discussions about getTunerVolume not working correctly start every now and then but so far Ansca has not taken the thing seriously.

I mean, this bug has been reported the first time on September, 2010:
http://developer.anscamobile.com/forum/2010/09/14/trying-get-microphone-volume-using-gettunervolume

Then again every few months until now…

I’ve submitted two official bug reports, one probably 10 months ago and the second 2/3 months ago (the first one was “accidentally deleted”).
Probably, the most clear example showing where the problem is, was made by duff333:
http://developer.anscamobile.com/forum/2011/08/06/gettunervolume-not-returning-expected-values

So, the problem is clear, there are some simple examples showing where the bug is.

Guys, let’s try to send emails to ansca pointing them to the post by duff333… I already tried many times, but maybe if we join they’ll hear us :wink:

I mean, it’s not that I want it fixed NOW, I just want to hear an official word from ansca (especially from the ansca developer who worked on that part of code).
[import]uid: 9158 topic_id: 15758 reply_id: 61734[/import]

I know this problem has been pending for some time and I took a look at the sample app and the Corona code and found that there are different problems on different platforms.

On Mac and iOS, the getVolume returns values that don’t reflect the volume received. The tuner frequency seems correct.

On Android, the getVolume returns values that reflect the volume, but the tuner frequency is not working.

In looking at the underlining code we determine that the problem is a byte swapping issue. We believe we know what needs to be fixed but it’s complicated because we need something that works across all platforms: Mac/iOS, Android, and Windows. It needs to be implemented in a way that doesn’t break existing code because some of it’s implemented in common code and some in platform-specific code.

We hope to find a workable fix and get this in a daily build soon.

-Tom
[import]uid: 7559 topic_id: 15758 reply_id: 61785[/import]

Tom, thanks for the answer.
I really, really appreciate you taking time to explain the situation in detail :slight_smile: [import]uid: 9158 topic_id: 15758 reply_id: 61790[/import]

Tom,

Greatly appreciate the response and to hear you’re seriously looking at this issue now. Can’t wait to finally be able to use this in my Corona projects the way it was meant to work!

best

Max
[import]uid: 3458 topic_id: 15758 reply_id: 61832[/import]

I’m finding getTunerFrequency has a ceiling of 4KHz

Anyone agree?

Im testing on iPhone 4s [import]uid: 97524 topic_id: 15758 reply_id: 71330[/import]

Any news about that??? Its months since the last Statement.

Still I do not get proper Values. It seems a bit improved, but
no comparision to the original API results.

Silent = 0 than normal speaking jumps already to 0.5 and a bit louder to 0.59
the maximum.

So its impossible to differentiate between a normal Talk Value and screaming for example.

In my case I need to trigger an action only when blown into the microphone (only than it should go to maximum value)… but for now also a normal voice triggers maximum value :frowning:

Its really time to fix that, otherwise that API feature is useless and should not even shown in the API List, as it is more confusing than useful.

chris
[import]uid: 4795 topic_id: 15758 reply_id: 77295[/import]

Hi!

Maybe a stupid question, but why I get “-inf” when i try to print the return value from getTunerVolume?

...  
  
 local v = gravacion:getTunerVolume()  
 local vdb = 10 \* math.log( v )  
 local texto = tostring( vdb )  
 print("Volume en dB: "..texto)   
  
...  

TIA [import]uid: 44013 topic_id: 15758 reply_id: 81086[/import]

and even if you don’t get -inf
that function is not working proper!

I am sorry to say. since months we wait for a proper working solution.
I love Corona and it helped me a lot,
but in some cases I can just shake my head.

For example that function is as it is not working for over a year now (just read back in the comments)

the result is starting from around 0.1 and while normal speaking volume it jumps to its
full limit 0.59… and THATS It!

You can’t measure if someone is screaming or blowing in the mic…
every normal speech into the mic can trigger the maximum value.

USELESS

I really hope that feature… as long its now in the bug list and user request… come soon
working PROPER

thx
chris
[import]uid: 4795 topic_id: 15758 reply_id: 81087[/import]

Thanks for your reply, Chris!

I was reading several post about this problem and figured out this one was solved yet.

I’ll keep waiting.

Tanks! [import]uid: 44013 topic_id: 15758 reply_id: 81089[/import]

Solved? how? :slight_smile:

I just tested few days ago… and still had the same results :frowning:

let me know should u get it worked… i will be just happy about. [import]uid: 4795 topic_id: 15758 reply_id: 81091[/import]

I have a bug into Ansca On volume, my test code sill shows problems. [import]uid: 110373 topic_id: 15758 reply_id: 81108[/import]

don’t think getTunerFrequency works either ‘fully’ - only a limited frequency range, instead of the full frequency range of the mic

[import]uid: 97524 topic_id: 15758 reply_id: 81116[/import]