yeah.
emulator 1.5 is ok but 1.6 is not.
ironic, real phone 1.6 is ok but 1.5 is not.
that is what i told u before.
On Mar 21, 2:57 pm, Gabriel Simões <gsim...@gmail.com> wrote:
> Another conclusion:
>
> I´ve coded another app which only uses AudioTrack and it works
> perfectly!
> So, the only thing left to blame is the emulator.
>
> On 20 mar, 16:30, Gabriel Simões <gsim...@gmail.com> wrote:
>
>
>
> > In this case no news = bad news ...
>
> > Based on Mario´s post and the possibilities I could think about in the
> > last days I have modified the code trying to isolate the issues like
> > calling blocking methods and as a consequence loosing part of the
> > audio stream, having buffer overflows, etc, as this could be the
> > reason for the bad audio playback.
>
> > Here is the code:
>
> > package com.example.test;
>
> > import android.app.Activity;
> > import android.media.AudioFormat;
> > import android.media.AudioManager;
> > import android.media.AudioRecord;
> > import android.media.AudioTrack;
> > import android.media.MediaRecorder;
> > import android.os.Bundle;
>
> > public class test extends Activity {
>
> > /** Called when the activity is first created. */
> > �...@override
> > public void onCreate(Bundle savedInstanceState) {
> > super.onCreate(savedInstanceState);
> > setContentView(R.layout.main);
> > Record record = new Record();
> > record.run();
> > }
>
> > public class Record extends Thread
> > {
> > public void run() {
> > android.os.Process.setThreadPriority
> > (android.os.Process.THREAD_PRIORITY_URGENT_AUDIO);
>
> > AudioRecord arec = new
> > AudioRecord(MediaRecorder.AudioSource.MIC,
> > 8000,
>
> > AudioFormat.CHANNEL_CONFIGURATION_MONO,
>
> > AudioFormat.ENCODING_PCM_16BIT,
> > 32000);
>
> > AudioTrack atrack = new
> > AudioTrack(AudioManager.STREAM_MUSIC,
> > 8000,
>
> > AudioFormat.CHANNEL_CONFIGURATION_MONO,
>
> > AudioFormat.ENCODING_PCM_16BIT,
> > 56000,
>
> > AudioTrack.MODE_STREAM);
>
> > short[] buffer = new short[64000];
>
> > int t = 0;
> > arec.startRecording();
> > while(t < 64000)
> > t += arec.read(buffer, t, 8000);
> > arec.stop();
>
> > arec.release();
> > t = 0;
> > atrack.play();
> > while(t < 64000)
> > t += atrack.write(buffer, t, 8000);
> > atrack.stop();
> > atrack.release();
> > }
> > }
>
> > }
>
> > As you can see, first I record the audio and just after stop recording
> > I start playing it. As expected there was no AudioRecord buffer
> > overflow messages and I´ve indexed the buffers by the return values
> > received by calling read() and write().
> > The sonic result was the same: chopped audio with a sensation of a
> > slow playback, and distorted. The impression I have also is that it´s
> > not recording for the whole 6 seconds, or at least the playback doesn
> > ´t last it all.
>
> > Could anyone try this simple code on a real device and check if it
> > works ok?
>
> > Thanks,
> > Gabriel Simões
>
> > On 17 mar, 22:58, Gabriel Simões <gsim...@gmail.com> wrote:
>
> > > Thanks for your answer Mario!
>
> > > Yes, I wrote it wrong ... should have been AudioTrack.write() instead
> > > of AudioTrack.play().
> > > The same idea came to my mind a couple of hours ago. Since AudioTrack
> > > when set
> > > as stream will only start playing at the time it´s internal buffer
> > > gets full, write()
> > > could block if the buffer is full to prevent an overflow.
>
> > > To quick test it, I have instantiated AudioTrack with an internal
> > > buffer a lot
> > > bigger than the one I used to read and write the audio streams. This
> > > way my app should
> > > take longer to start playing and get a pretty big delay, but the
> > > audio
> > > should not chop nor present any artfacts at least for the first
> > > seconds.
>
> > > The results I got presented the same problems, but based on that I
> > > will try it again.
>
> > > One other thing that came to my mind is, once a buffer overflow
> > > happens, does AudioRecord handle the problem and reorganize the buffer
> > > or
> > > should I flush it and start from 0 (the buffer gets messed and this
> > > ends giving a bad audio signal with chops, delay, etc...)?
>
> > > Gabriel
>
> > > On 17 mar, 21:07, Mario Zechner <badlogicga...@gmail.com> wrote:
>
> > > > Hi there,
>
> > > > not sure whether i can help but you stated that you couldn't find
> > > > anywhere that "AudioTrack.play()" (which should probably read
> > > > AudioTrack.write()) does not block. Well, it does. And if you do the
> > > > following in your thread:
>
> > > > AudioRecord.read(sampels)
> > > > AudioTrack.write(samples)
>
> > > > i can imagine that the write will block long enough for the
> > > > AudioRecord to overflow as you don't read in the next buffer of
> > > > samples early enough. You could try decreasing the number of samples
> > > > you read and write so the write will not block as long. No idea
> > > > whether that will solve the problem.
>
> > > > hth,
> > > > Mario
>
> > > > On 18 Mrz., 00:33, HeHe <cnm...@gmail.com> wrote:
>
> > > > > no, i havent, because my app runs ok on g1 with 1.6 firmware. it just
> > > > > runs weird on 1.6 emulator. so i am 90% happy already.
>
> > > > > btw, my app does not record and play audio at the same time, but it
> > > > > encodes audio with speex, which should take overhead no less than
> > > > > playback, i guess.
>
> > > > > anyway, i wish you lucks and hope goodle folks will help you solve the
> > > > > issue.
>
> > > > > On Mar 17, 8:55 am, Gabriel Simões <gsim...@gmail.com> wrote:
>
> > > > > > Installing ubuntu 9.1 on my machine.
> > > > > > I will try using linux to develop as I think it will be less
> > > > > > confusing
> > > > > > to develop using NDK.
>
> > > > > > Hehe: I was thinking about trying to get an answer from someone from
> > > > > > Google tomorrow at irc. Have you ever tried it?
>
> > > > > > Won´t anyone who is actually using AudioRecord with success show up
> > > > > > and tell us what we are doing wrong? :(
>
> > > > > > On 17 mar, 12:53, HeHe <cnm...@gmail.com> wrote:
>
> > > > > > > i heard that too. but some google folk seemed discouraging use of
> > > > > > > the
> > > > > > > stuff.
>
> > > > > > > On Mar 17, 6:27 am, Gabriel Simões <gsim...@gmail.com> wrote:
>
> > > > > > > > Nope,
>
> > > > > > > > I´ve paid attention to see if GC was being called, but nothing
> > > > > > > > shows
> > > > > > > > up on LogCat.
> > > > > > > > Well, I´ve found some posts on the internet about using
> > > > > > > > AudioRecord´s
> > > > > > > > native implementation. Isn´t it supported anymore?
>
> > > > > > > > I still can´t believe we are spending so much time on something
> > > > > > > > that
> > > > > > > > should be "plug and play". It´s almost becoming "plug and pray"!
>
> > > > > > > > On 17 mar, 02:41, HeHe <cnm...@gmail.com> wrote:
>
> > > > > > > > > if you find any native audio interfaces in NDK, please share
> > > > > > > > > it with
> > > > > > > > > me first :)
>
> > > > > > > > > for your issue, did you check GC? that is, around the time
> > > > > > > > > when you
> > > > > > > > > see buffer overflow msgs, does GC happen too?
>
> > > > > > > > > On Mar 16, 7:33 pm, Gabriel Simões <gsim...@gmail.com> wrote:
>
> > > > > > > > > > *** Idea ...
> > > > > > > > > > Using the NDK native audio interfaces should solve this
> > > > > > > > > > problem?
>
> > > > > > > > > > On 16 mar, 22:26, Gabriel Simões <gsim...@gmail.com> wrote:
>
> > > > > > > > > > > News, but no good news...
>
> > > > > > > > > > > I´ve tried the source code above on another machine
> > > > > > > > > > > running the sdk
> > > > > > > > > > > 2.1, an AVD with default parameters plus audio record and
> > > > > > > > > > > audio
> > > > > > > > > > > playback capabilities, another operational system
> > > > > > > > > > > (linux), etc.
> > > > > > > > > > > The results? the same we had before .... audio delay
> > > > > > > > > > > (long delay),
> > > > > > > > > > > chopping, distortion and a metalic voice.
>
> > > > > > > > > > > I can not believe nobody here in this forum hasn´t been
> > > > > > > > > > > able to
> > > > > > > > > > > develop any app that can record from the microfone using
> > > > > > > > > > > AudioRecord.
> > > > > > > > > > > Also, anyone here hasn´t even made a loop back from
> > > > > > > > > > > microfone to line
> > > > > > > > > > > out to check the audio being recorded?
>
> > > > > > > > > > > Please, c´mon guys ... this is not a commercial secret,
> > > > > > > > > > > this won´t
> > > > > > > > > > > increase competition, and I really can´t see any other
> > > > > > > > > > > reasons not to
> > > > > > > > > > > see some posts from developers who work with audio or
> > > > > > > > > > > other signal
> > > > > > > > > > > processing using Android.
>
> > > > > > > > > > > Please, show us a way to go because I´ve tried almost all
> > > > > > > > > > > the
> > > > > > > > > > > possibilities here (the only one left is to try using a
> > > > > > > > > > > real device)
> > > > > > > > > > > and revising the code I can´t find what else it could be.
>
> > > > > > > > > > > *Obs: once again, a program with a thread only to read
> > > > > > > > > > > from
> > > > > > > > > > > AudioRecord and play with AudioTrack is giving warnings
> > > > > > > > > > > about buffer
> > > > > > > > > > > overflows (Audio Record). There´s no processing going on
> > > > > > > > > > > and since I
> > > > > > > > > > > haven´t found anything related to "AudioTrack.play()
> > > > > > > > > > > blocks until the
> > > > > > > > > > > audio stream is played", based on it´s actuall behavior
> > > > > > > > > > > in my app I can
> > > > > > > > > > > ´t see how this class could be useful
> > > > > > > > > > > for online audio processing applications.
>
> > > > > > > > > > > Thank you,
> > > > > > > > > > > Gabriel
>
> > > > > > > > > > > On 15 mar, 20:53, Gabriel Simões <gsim...@gmail.com>
> > > > > > > > > > > wrote:...
>
> read more »
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words "REMOVE ME" as the subject.
