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:
>
> > > > > > > > > > > Well, just to try I´ve downloaded the SDK 1.6 (v. 4),
> > > > > > > > > > > created a new
> > > > > > > > > > > AVD based on that and then tried the source code from the
> > > > > > > > > > > first post
> > > > > > > > > > > in two different situations:
>
> > > > > > > > > > > - App compiled using SDK 1.6 on an AVD running 1.6
> > > > > > > > > > > - App compiled using SDK 1.6 on an AVD running 2.1
>
> > > > > > > > > > > Had exactly the same results as "compiling" and running
> > > > > > > > > > > on 2.1: audio
> > > > > > > > > > > chopping, distortion and artfacts even if I solo the
> > > > > > > > > > > microfone input
> > > > > > > > > > > level (using a 1 second buffer, sometimes the audio
> > > > > > > > > > > decays in a lot
> > > > > > > > > > > longer) and AudioRecord buffer overflow messages even if
> > > > > > > > > > > all I do in
> > > > > > > > > > > the thread is to read from AudioRecord and to play using
> > > > > > > > > > > AudioTrack.
>
> > > > > > > > > > > Tomorrow I will try to test my code using another
> > > > > > > > > > > computer and even
> > > > > > > > > > > on
> > > > > > > > > > > a real device. In- Ocultar texto das mensagens anteriores
> > > > > > > > > > > -
>
> - Mostrar texto das mensagens anteriores -...
>
> mais »
--
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.
