[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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)
Re: [android-developers] Re: Audio Flickering - my code, my computer or android emulator?
I On Mar 14, 2010 5:01 PM, Gabriel Simões gsim...@gmail.com wrote: Ops, sorry for the title. Should be audio chopping from AudioRecord to AudioTrack. On 14 mar, 19:00, Gabriel Simões gsim...@gmail.com wrote: Hello, Since my day 1 I´ve been f... -- 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.
Re: [android-developers] Re: Audio Flickering - my code, my computer or android emulator?
On Mar 14, 2010 5:01 PM, Gabriel Simões gsim...@gmail.com wrote: Ops, sorry for the title. Should be audio chopping from AudioRecord to AudioTrack. On 14 mar, 19:00, Gabriel Simões gsim...@gmail.com wrote: Hello, Since my day 1 I´ve been f... -- 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.
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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 the mean time, any other ideas? Gabriel On 15 mar, 01:31, HeHe cnm...@gmail.com wrote: no chopping, likely because my computer (Core2 E8400) is lightening fast. my AudioRecord.read() returns a value equal to my buffer size, too. however, it returns recorded samples in a speed faster than 8khz, which makes later playback sound like my voice is slowed. again, the same code works correctly on 1.5 emulator. so, seems your problem is not the same as mine :( On Mar 14, 6:53 pm, Gabriel Simões gsim...@gmail.com wrote: Audio chopping also? Could you please test the code above? I´ve checked and AudioRecord.read() returns a value equal to my buffer size. Based on that I understand that AudioRecord.read() blocks the execution, waits for the buffer to get a number of samples at least equal to the buffer size and then it returns the audio stream (older buffer size number of samples in the AudioRecord internal buffer). On 14 mar, 22:34, HeHe cnm...@gmail.com wrote: seems i am experiencing similar issue as you r.http://groups.google.com/group/android-developers/browse_thread/threa... without any single line of code modification to my app, the count of frames recorded by app running on sdk 1.6 emulator is significantly more than that recorded by the same app running on sdk 1.5 emulator. however, the same app runs equally well on both 1.5/1.6 emulators. it is weird. On Mar 14, 3:00 pm, Gabriel Simões gsim...@gmail.com wrote: Hello, Since my day 1 I´ve been facing problems with Android AudioRecord API. After a lot of research and a lot more trial and error I´ve found my way into the code and was able
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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 the mean time, any other ideas? Gabriel On 15 mar, 01:31, HeHe cnm...@gmail.com wrote: no chopping, likely because my computer (Core2 E8400) is lightening fast. my AudioRecord.read() returns a value equal to my buffer size, too. however, it returns recorded samples in a speed faster than 8khz, which makes later playback sound like my voice is slowed. again, the same code works correctly on 1.5 emulator. so, seems your problem is not the same as mine :( On Mar 14, 6:53 pm, Gabriel Simões gsim...@gmail.com wrote: Audio chopping also? Could you please test the code above? I´ve checked and AudioRecord.read() returns a value equal to my buffer size. Based on that I understand that AudioRecord.read() blocks the execution, waits for the buffer to get a number of samples at least equal to the buffer size and then it returns the audio stream (older buffer size number of samples in the AudioRecord internal buffer). On 14 mar, 22:34, HeHe cnm...@gmail.com wrote: seems i am experiencing similar issue as you r.http://groups.google.com/group/android-developers/browse_thread/threa... without any single line of code modification to my app, the count of frames recorded by app running on sdk 1.6 emulator is significantly more than that recorded by the same app running on sdk 1.5 emulator. however, the same app runs equally well on both 1.5/1.6 emulators. it is weird. On Mar 14, 3:00 pm,
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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 the mean time, any other ideas? Gabriel On 15 mar, 01:31, HeHe cnm...@gmail.com wrote: no chopping, likely because my computer (Core2 E8400) is lightening fast. my AudioRecord.read() returns a value equal to my buffer size, too. however, it returns recorded samples in a speed faster than 8khz, which makes later playback sound like my voice is slowed. again, the same code works correctly on 1.5 emulator. so, seems your problem is not the same as mine :( On Mar 14, 6:53 pm, Gabriel Simões gsim...@gmail.com wrote: Audio chopping also? Could you please test the code above? I´ve checked and AudioRecord.read() returns a value equal to my buffer size. Based on that I understand that AudioRecord.read() blocks the execution, waits for the buffer to get a number of samples at least equal to the buffer size and then it returns the audio stream (older buffer size number of samples in the AudioRecord internal buffer). On 14 mar, 22:34, HeHe cnm...@gmail.com wrote:
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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 the mean time, any other ideas? Gabriel On 15 mar, 01:31, HeHe cnm...@gmail.com wrote: no chopping, likely because my computer (Core2 E8400) is lightening fast. my AudioRecord.read() returns a value equal to my buffer size, too. however, it returns recorded samples in a speed faster than 8khz, which makes later playback sound like my voice is slowed. again, the same code works correctly on 1.5 emulator. so, seems your problem is not the same as mine :( On Mar 14, 6:53 pm, Gabriel Simões
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
Thanks Mario Yes, I wrote it wrong ... should have been AudioTrack.write(). That idea came to my mind a couple of hours ago. Since AudioTrack set as stream will only start playing as the buffer gets full, write() could block if the buffer is still full. To test it, I have created AudioTrack with an internal buffer a lot bigger than the one I used to read and write. 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. The result I got was the same, but based on that I will try it again. One other thing that comes to my mind is, once a buffer overflow happens, AudioRecord handles the problem and reorganize the buffer or should I flush it and start from 0? 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
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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, I can´t see how this class could be useful for 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 the mean time, any other ideas? Gabriel On 15 mar, 01:31, HeHe cnm...@gmail.com wrote: no chopping, likely because my computer (Core2 E8400) is lightening fast. my AudioRecord.read() returns a value equal to my buffer size, too. however, it returns recorded samples in a speed faster than 8khz, which makes later playback sound like my voice is slowed. again, the same code works correctly on 1.5 emulator. so, seems your problem is not the same as mine :( On Mar 14, 6:53 pm, Gabriel Simões gsim...@gmail.com wrote: Audio chopping also? Could you please test the code above? I´ve checked and AudioRecord.read() returns a value equal to my buffer size. Based on that I understand that AudioRecord.read() blocks the execution, waits for the buffer to get a number of samples at least equal to the buffer size and then it returns the audio stream (older buffer size number of samples in the AudioRecord internal buffer). On 14 mar, 22:34, HeHe cnm...@gmail.com wrote: seems i am experiencing similar issue as you r.http://groups.google.com/group/android-developers/browse_thread/threa... without any single line of code modification to my app, the count of frames recorded by app running on sdk 1.6 emulator is significantly more than that recorded by the same app running on sdk 1.5 emulator. however, the same app runs equally well on both 1.5/1.6 emulators. it is weird. On Mar 14, 3:00 pm, Gabriel Simões gsim...@gmail.com wrote: Hello, Since my day 1 I´ve been facing problems with Android AudioRecord API. After a lot of research and a lot more trial and error I´ve found my way into the code and was able to write an asynctask for audio streams recording which encapsules most of the audiorecord and asynctask features as a lib, so the developers doesn´t need to worry about finding the best audio parameters, work on stop and release, etc. So far, everything was right. Yesterday I started trying to process the audio I got from the microfone input and my code was reacting bad. I revisited it many times and decided then to check the audio I was getting from the mic. Created in instance of AudioTrack and tried to play it back. The sound was horrible, with lots of chopping, lots of distortion and giving me even the sensation of low samplerate playback (a single word spoken sometimes lasted for seconds on the earphone). To check if it was actually my code I went for the internet and found the code above. Tried it and got the same results. The only thing that comes to my mind actually is that, it doesn´t matter what I do and the configuration I try, I always get the buffer overflow message. Even if I don´t actually do
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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 the mean time, any other ideas? Gabriel On 15 mar, 01:31, HeHe cnm...@gmail.com wrote: no chopping, likely because my computer (Core2 E8400) is lightening fast. my AudioRecord.read() returns a value equal to my buffer size, too. however, it returns recorded samples in a speed faster than 8khz, which makes later playback sound like my voice is slowed. again, the same code works correctly on 1.5 emulator. so, seems your problem is not the same as mine :( On Mar 14, 6:53 pm, Gabriel Simões gsim...@gmail.com wrote: Audio chopping also? Could you please test the code above? I´ve checked and AudioRecord.read() returns a value equal to my buffer size. Based on that I understand that AudioRecord.read() blocks the execution, waits for the buffer to get a number of samples at least equal to the buffer size and then it returns the audio stream (older buffer size number of samples in the AudioRecord internal buffer). On 14 mar, 22:34, HeHe cnm...@gmail.com wrote: seems i am experiencing similar issue as you r.http://groups.google.com/group/android-developers/browse_thread/threa... without any single line of code modification to my app, the count of frames recorded by app running on sdk 1.6 emulator is significantly more than that recorded by the same app running on sdk 1.5 emulator. however, the same app runs equally well on both 1.5/1.6 emulators. it is weird. On Mar 14, 3:00 pm, Gabriel Simões gsim...@gmail.com wrote: Hello, Since my day 1 I´ve been facing problems with Android AudioRecord API. After a lot of research and a lot more trial and error I´ve found my way into the code and was able to write an asynctask for audio streams recording which encapsules most of the audiorecord and asynctask features as a lib, so the developers doesn´t need to worry about finding the best audio parameters, work on stop and release, etc. So far, everything was right. Yesterday I started trying to process the audio I got from the microfone input and my code was reacting bad. I revisited it many times and decided then to check the audio I was getting from the mic. Created in instance of AudioTrack and tried to play it back. The sound was horrible, with lots of chopping, lots of distortion and giving me even the sensation of low samplerate playback (a single word spoken sometimes lasted for seconds on the earphone). To check if it was actually my code I went for the internet and found the code above. Tried it and got the same results. The only thing that comes to my mind actually is that, it doesn´t matter what I do and the configuration I try, I always get the buffer
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
*** 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 the mean time, any other ideas? Gabriel On 15 mar, 01:31, HeHe cnm...@gmail.com wrote: no chopping, likely because my computer (Core2 E8400) is lightening fast. my AudioRecord.read() returns a value equal to my buffer size, too. however, it returns recorded samples in a speed faster than 8khz, which makes later playback sound like my voice is slowed. again, the same code works correctly on 1.5 emulator. so, seems your problem is not the same as mine :( On Mar 14, 6:53 pm, Gabriel Simões gsim...@gmail.com wrote: Audio chopping also? Could you please test the code above? I´ve checked and AudioRecord.read() returns a value equal to my buffer size. Based on that I understand that AudioRecord.read() blocks the execution, waits for the buffer to get a number of samples at least equal to the buffer size and then it returns the audio stream (older buffer size number of samples in the AudioRecord internal buffer). On 14 mar, 22:34, HeHe cnm...@gmail.com wrote: seems i am experiencing similar issue as you r.http://groups.google.com/group/android-developers/browse_thread/threa... without any single line of code modification to my app, the count of frames recorded by app running on sdk 1.6 emulator is significantly more than that recorded by the same app running on sdk 1.5 emulator. however, the same app runs equally well on both 1.5/1.6 emulators. it is weird. On Mar 14, 3:00 pm, Gabriel Simões gsim...@gmail.com wrote: Hello, Since my day 1 I´ve been facing problems with Android AudioRecord API. After a lot of research and a lot more trial and error I´ve found my way into the code and was able to write an asynctask for audio streams recording which encapsules most of the audiorecord and asynctask features as a lib, so the developers doesn´t need to worry about finding the best audio parameters, work on stop and release, etc. So far, everything was right. Yesterday I started trying to process the audio I got from the microfone input and my code was reacting bad. I revisited it many times and decided then to check the audio I was getting from the mic. Created in instance of AudioTrack and tried to play it back. The sound was horrible, with lots of chopping, lots of distortion and giving me even the sensation of low samplerate playback (a single word spoken sometimes lasted for seconds on the earphone). To check if it was
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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 the mean time, any other ideas? Gabriel On 15 mar, 01:31, HeHe cnm...@gmail.com wrote: no chopping, likely because my computer (Core2 E8400) is lightening fast. my AudioRecord.read() returns a value equal to my buffer size, too. however, it returns recorded samples in a speed faster than 8khz, which makes later playback sound like my voice is slowed. again, the same code works correctly on 1.5 emulator. so, seems your problem is not the same as mine :( On Mar 14, 6:53 pm, Gabriel Simões gsim...@gmail.com wrote: Audio chopping also? Could you please test the code above? I´ve checked and AudioRecord.read() returns a value equal to my buffer size. Based on that I understand that AudioRecord.read() blocks the execution, waits for the buffer to get a number of samples at least equal to the buffer size and then it returns the audio stream (older buffer size number of samples in the AudioRecord internal buffer). On 14 mar, 22:34, HeHe cnm...@gmail.com wrote: seems i am experiencing similar issue as you r.http://groups.google.com/group/android-developers/browse_thread/threa... without any single line of code modification to my app, the count of frames recorded by app running on sdk 1.6 emulator is significantly more than that recorded by the same app running on sdk 1.5 emulator. however, the same app runs equally well on both 1.5/1.6 emulators. it is weird. On Mar 14, 3:00 pm, Gabriel Simões gsim...@gmail.com wrote: Hello, Since my day 1 I´ve been facing problems with Android AudioRecord API. After a lot of research and a lot more trial and error I´ve found my way into the code and was able to write an asynctask for audio streams recording which encapsules most of the audiorecord and asynctask features as a lib, so the developers doesn´t need to worry about finding the best audio parameters, work on stop and release, etc. So far, everything was right. Yesterday I started trying to process the audio I got from the microfone input and my code was reacting bad. I revisited it many times and decided then to check the audio I was
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
It is the problem with your driver which creates this chopping effect.It is not able to read the data properly and if you check your kernel messages there would be a buffer overrun message.This happens because Linux is not RTOS and audio is running in real time. What you are recording is noise also along with voice data.So you need noise cancellation algorithm also if you want proper sound. There is one more problem with respect to sampling rate.If your driver supports x sampling rate and you want to sample at y sampling rate then there is resampling that takes place which causes some loss in data.So your re-sampler also should be good enough to do re-sampling. Generally audio re-samplers provided by android is not of good quality and if you do playback and recording simultaneously then you can make out that playback is not proper(there would be some audio distortion in your playback audio). -- 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
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
Thanks for your answers ... Well, since the same source code works on your computer and not on mine, I think the chopping problem is on my emulator. My computer is not as good as yours but it´s a Turion X2 notebook with 2gb ram, so if on a computer like this the emulator is not able to record and playback audio at the same time, even not fast enought to handle the audio stream before AudioRecord warns a buffer overflow, then I really don´t know what to try next. I hope I can find a phone to try the app in a real device. Also, I will try the sdk 1.6. About ani´s post, I do understand it, but I´m using Windows XP SP3. Also, I believe that if the emulator accepts 8k as record and playback sample rate (it doesn´t accept any othet value) then it should work properly for recording and playing the same audio stream in this SR. It ´s not the best option but if there´s a need for manual ressampling, it can be done. What can´t is the action of properly recording audio. Anyone else facing this same problem on SDK 2.1, AMD processor, windows xp sp3? On 15 mar, 11:17, ani anish198519851...@gmail.com wrote: It is the problem with your driver which creates this chopping effect.It is not able to read the data properly and if you check your kernel messages there would be a buffer overrun message.This happens because Linux is not RTOS and audio is running in real time. What you are recording is noise also along with voice data.So you need noise cancellation algorithm also if you want proper sound. There is one more problem with respect to sampling rate.If your driver supports x sampling rate and you want to sample at y sampling rate then there is resampling that takes place which causes some loss in data.So your re-sampler also should be good enough to do re-sampling. Generally audio re-samplers provided by android is not of good quality and if you do playback and recording simultaneously then you can make out that playback is not proper(there would be some audio distortion in your playback audio). -- 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
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
Thanks for your answers ... Well, since the same source code works on your computer and not on mine, I think the chopping problem is on my emulator. My computer is not as good as yours but it´s a Turion X2 notebook with 2gb ram, so if on a computer like this the emulator is not able to record and playback audio at the same time, even not fast enought to handle the audio stream before AudioRecord warns a buffer overflow, then I really don´t know what to try next. I hope I can find a phone to try the app in a real device. Also, I will try the sdk 1.6. About ani´s post, I do understand it, but I´m using Windows XP SP3 and Android runs as linux but the API works for other people so this shouldn´t be an OS flaw. Also, I believe that if the emulator accepts 8k as record and playback sample rate (it doesn´t accept any othet value) then it should work properly for recording and playing the same audio stream in this SR. It ´s not the best option but if there´s a need for manual ressampling, it can be done. What can´t is the action of properly recording audio. Anyone else facing this same problem on SDK 2.1, AMD processor, windows xp sp3? On 15 mar, 11:17, ani anish198519851...@gmail.com wrote: It is the problem with your driver which creates this chopping effect.It is not able to read the data properly and if you check your kernel messages there would be a buffer overrun message.This happens because Linux is not RTOS and audio is running in real time. What you are recording is noise also along with voice data.So you need noise cancellation algorithm also if you want proper sound. There is one more problem with respect to sampling rate.If your driver supports x sampling rate and you want to sample at y sampling rate then there is resampling that takes place which causes some loss in data.So your re-sampler also should be good enough to do re-sampling. Generally audio re-samplers provided by android is not of good quality and if you do playback and recording simultaneously then you can make out that playback is not proper(there would be some audio distortion in your playback audio). -- 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
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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 result 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 read from AudioRecord and play with AudioTrack. Tomorrow I will try to test my code using another computer and even on a real device. In the mean time, any other ideas? Gabriel On 15 mar, 12:15, Gabriel Simões gsim...@gmail.com wrote: Thanks for your answers ... Well, since the same source code works on your computer and not on mine, I think the chopping problem is on my emulator. My computer is not as good as yours but it´s a Turion X2 notebook with 2gb ram, so if on a computer like this the emulator is not able to record and playback audio at the same time, even not fast enought to handle the audio stream before AudioRecord warns a buffer overflow, then I really don´t know what to try next. I hope I can find a phone to try the app in a real device. Also, I will try the sdk 1.6. About ani´s post, I do understand it, but I´m using Windows XP SP3 and Android runs as linux but the API works for other people so this shouldn´t be an OS flaw. Also, I believe that if the emulator accepts 8k as record and playback sample rate (it doesn´t accept any othet value) then it should work properly for recording and playing the same audio stream in this SR. It ´s not the best option but if there´s a need for manual ressampling, it can be done. What can´t is the action of properly recording audio. Anyone else facing this same problem on SDK 2.1, AMD processor, windows xp sp3? On 15 mar, 11:17, ani anish198519851...@gmail.com wrote: It is the problem with your driver which creates this chopping effect.It is not able to read the data properly and if you check your kernel messages there would be a buffer overrun message.This happens because Linux is not RTOS and audio is running in real time. What you are recording is noise also along with voice data.So you need noise cancellation algorithm also if you want proper sound. There is one more problem with respect to sampling rate.If your driver supports x sampling rate and you want to sample at y sampling rate then there is resampling that takes place which causes some loss in data.So your re-sampler also should be good enough to do re-sampling. Generally audio re-samplers provided by android is not of good quality and if you do playback and recording simultaneously then you can make out that playback is not proper(there would be some audio distortion in your playback audio).- Ocultar texto das mensagens anteriores - - Mostrar texto das mensagens anteriores - -- 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
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
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 the mean time, any other ideas?
Gabriel
On 15 mar, 01:31, HeHe cnm...@gmail.com wrote:
no chopping, likely because my computer (Core2 E8400) is lightening
fast.
my AudioRecord.read() returns a value equal to my buffer size, too.
however, it returns recorded samples in a speed faster than 8khz,
which makes later playback sound like my voice is slowed.
again, the same code works correctly on 1.5 emulator.
so, seems your problem is not the same as mine :(
On Mar 14, 6:53 pm, Gabriel Simões gsim...@gmail.com wrote:
Audio chopping also?
Could you please test the code above?
I´ve checked and AudioRecord.read() returns a value equal to my buffer
size. Based on that I understand that AudioRecord.read() blocks the
execution, waits for the buffer to get a number of samples at least
equal to the buffer size and then it returns the audio stream (older
buffer size number of samples in the AudioRecord internal buffer).
On 14 mar, 22:34, HeHe cnm...@gmail.com wrote:
seems i am experiencing similar issue as you
r.http://groups.google.com/group/android-developers/browse_thread/threa...
without any single line of code modification to my app, the count of
frames recorded by app running on sdk 1.6 emulator is significantly
more than that recorded by the same app running on sdk 1.5 emulator.
however, the same app runs equally well on both 1.5/1.6 emulators.
it is weird.
On Mar 14, 3:00 pm, Gabriel Simões gsim...@gmail.com wrote:
Hello,
Since my day 1 I´ve been facing problems with Android AudioRecord API.
After a lot of research and a lot more trial and error I´ve found my
way into the code and was able to write an asynctask for audio streams
recording which encapsules most of the audiorecord and asynctask
features as a lib, so the developers doesn´t need to worry about
finding the best audio parameters, work on stop and release, etc.
So far, everything was right.
Yesterday I started trying to process the audio I got from the
microfone input and my code was reacting bad. I revisited it many
times and decided then to check the audio I was getting from the mic.
Created in instance of AudioTrack and tried to play it back. The sound
was horrible, with lots of chopping, lots of distortion and giving me
even the sensation of low samplerate playback (a single word spoken
sometimes lasted for seconds on the earphone).
To check if it was actually my code I went for the internet and found
the code above. Tried it and got the same results. The only thing that
comes to my mind actually is that, it doesn´t matter what I do and the
configuration I try, I always get the buffer overflow message. Even if
I don´t actually do anything but read from AudioRecord and write to
AudioTrack (example above, and not in debug mode). If the emulator can
´t do it fast enought then I´m completly lost here.
Based on the output of my algorithm I think the audio streams I´m
reading are not right.
Have anyone faced this? does anyone know how to solve it? Could anyone
try the code (copy and paste) and check if it´s actually my computer
or my emulator?
package com.example.test;
import android.app.Activity;
import android.content.Context;
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 {
boolean isRecording; //currently not used
AudioManager am;
/** Called when the activity is first created. */
�...@override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
am = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
Record record = new Record();
record.run();
}
public class Record extends Thread
{
// SoundPower sndPower = new SoundPower();
static final int bufferSize = 20;
final short[] buffer = new short[bufferSize];
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
Ops, sorry for the title. Should be audio chopping from AudioRecord to
AudioTrack.
On 14 mar, 19:00, Gabriel Simões gsim...@gmail.com wrote:
Hello,
Since my day 1 I´ve been facing problems with Android AudioRecord API.
After a lot of research and a lot more trial and error I´ve found my
way into the code and was able to write an asynctask for audio streams
recording which encapsules most of the audiorecord and asynctask
features as a lib, so the developers doesn´t need to worry about
finding the best audio parameters, work on stop and release, etc.
So far, everything was right.
Yesterday I started trying to process the audio I got from the
microfone input and my code was reacting bad. I revisited it many
times and decided then to check the audio I was getting from the mic.
Created in instance of AudioTrack and tried to play it back. The sound
was horrible, with lots of chopping, lots of distortion and giving me
even the sensation of low samplerate playback (a single word spoken
sometimes lasted for seconds on the earphone).
To check if it was actually my code I went for the internet and found
the code above. Tried it and got the same results. The only thing that
comes to my mind actually is that, it doesn´t matter what I do and the
configuration I try, I always get the buffer overflow message. Even if
I don´t actually do anything but read from AudioRecord and write to
AudioTrack (example above, and not in debug mode). If the emulator can
´t do it fast enought then I´m completly lost here.
Based on the output of my algorithm I think the audio streams I´m
reading are not right.
Have anyone faced this? does anyone know how to solve it? Could anyone
try the code (copy and paste) and check if it´s actually my computer
or my emulator?
package com.example.test;
import android.app.Activity;
import android.content.Context;
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 {
boolean isRecording; //currently not used
AudioManager am;
/** Called when the activity is first created. */
�...@override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
am = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
Record record = new Record();
record.run();
}
public class Record extends Thread
{
// SoundPower sndPower = new SoundPower();
static final int bufferSize = 20;
final short[] buffer = new short[bufferSize];
short[] readBuffer = new short[bufferSize];
public void run() {
isRecording = true;
android.os.Process.setThreadPriority
(android.os.Process.THREAD_PRIORITY_URGENT_AUDIO);
int buffersize = AudioRecord.getMinBufferSize(8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT);
buffersize = 2048;
AudioRecord arec = new
AudioRecord(MediaRecorder.AudioSource.MIC,
8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT,
buffersize);
AudioTrack atrack = new
AudioTrack(AudioManager.STREAM_VOICE_CALL,
8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT,
buffersize,
AudioTrack.MODE_STREAM);
atrack.setPlaybackRate(8000);
byte[] buffer = new byte[buffersize];
arec.startRecording();
atrack.play();
while(isRecording) {
arec.read(buffer, 0,
buffersize);
atrack.write(buffer, 0,
buffer.length);
}
arec.stop();
atrack.stop();
isRecording = false;
}
}
}
This code is not mine. I´ve just cut and replaced some values (as the
SampleRate) so it would work.
My specs:
AndroidOS 2.1, last emulator and package (downloaded one week ago).
Dell Vostro 1000 (onboard soundcard), windows XP SP3.
Thank you very much,
Gabriel Simões
--
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
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
seems i am experiencing similar issue as you r.
http://groups.google.com/group/android-developers/browse_thread/thread/ad81d19418c8db1d/561f66e6b0cf2c79?show_docid=561f66e6b0cf2c79
without any single line of code modification to my app, the count of
frames recorded by app running on sdk 1.6 emulator is significantly
more than that recorded by the same app running on sdk 1.5 emulator.
however, the same app runs equally well on both 1.5/1.6 emulators.
it is weird.
On Mar 14, 3:00 pm, Gabriel Simões gsim...@gmail.com wrote:
Hello,
Since my day 1 I´ve been facing problems with Android AudioRecord API.
After a lot of research and a lot more trial and error I´ve found my
way into the code and was able to write an asynctask for audio streams
recording which encapsules most of the audiorecord and asynctask
features as a lib, so the developers doesn´t need to worry about
finding the best audio parameters, work on stop and release, etc.
So far, everything was right.
Yesterday I started trying to process the audio I got from the
microfone input and my code was reacting bad. I revisited it many
times and decided then to check the audio I was getting from the mic.
Created in instance of AudioTrack and tried to play it back. The sound
was horrible, with lots of chopping, lots of distortion and giving me
even the sensation of low samplerate playback (a single word spoken
sometimes lasted for seconds on the earphone).
To check if it was actually my code I went for the internet and found
the code above. Tried it and got the same results. The only thing that
comes to my mind actually is that, it doesn´t matter what I do and the
configuration I try, I always get the buffer overflow message. Even if
I don´t actually do anything but read from AudioRecord and write to
AudioTrack (example above, and not in debug mode). If the emulator can
´t do it fast enought then I´m completly lost here.
Based on the output of my algorithm I think the audio streams I´m
reading are not right.
Have anyone faced this? does anyone know how to solve it? Could anyone
try the code (copy and paste) and check if it´s actually my computer
or my emulator?
package com.example.test;
import android.app.Activity;
import android.content.Context;
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 {
boolean isRecording; //currently not used
AudioManager am;
/** Called when the activity is first created. */
�...@override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
am = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
Record record = new Record();
record.run();
}
public class Record extends Thread
{
// SoundPower sndPower = new SoundPower();
static final int bufferSize = 20;
final short[] buffer = new short[bufferSize];
short[] readBuffer = new short[bufferSize];
public void run() {
isRecording = true;
android.os.Process.setThreadPriority
(android.os.Process.THREAD_PRIORITY_URGENT_AUDIO);
int buffersize = AudioRecord.getMinBufferSize(8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT);
buffersize = 2048;
AudioRecord arec = new
AudioRecord(MediaRecorder.AudioSource.MIC,
8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT,
buffersize);
AudioTrack atrack = new
AudioTrack(AudioManager.STREAM_VOICE_CALL,
8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT,
buffersize,
AudioTrack.MODE_STREAM);
atrack.setPlaybackRate(8000);
byte[] buffer = new byte[buffersize];
arec.startRecording();
atrack.play();
while(isRecording) {
arec.read(buffer, 0,
buffersize);
atrack.write(buffer, 0,
buffer.length);
}
arec.stop();
atrack.stop();
isRecording = false;
}
}
}
This code is not mine. I´ve just cut and replaced some values (as the
SampleRate) so it would work.
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
Audio chopping also?
Could you please test the code above?
I´ve checked and AudioRecord.read() returns a value equal to my buffer
size. Based on that I understand that AudioRecord.read() blocks the
execution, waits for the buffer to get a number of samples at least
equal to the buffer size and then it returns the audio stream (older
buffer size number of samples in the AudioRecord internal buffer).
On 14 mar, 22:34, HeHe cnm...@gmail.com wrote:
seems i am experiencing similar issue as you
r.http://groups.google.com/group/android-developers/browse_thread/threa...
without any single line of code modification to my app, the count of
frames recorded by app running on sdk 1.6 emulator is significantly
more than that recorded by the same app running on sdk 1.5 emulator.
however, the same app runs equally well on both 1.5/1.6 emulators.
it is weird.
On Mar 14, 3:00 pm, Gabriel Simões gsim...@gmail.com wrote:
Hello,
Since my day 1 I´ve been facing problems with Android AudioRecord API.
After a lot of research and a lot more trial and error I´ve found my
way into the code and was able to write an asynctask for audio streams
recording which encapsules most of the audiorecord and asynctask
features as a lib, so the developers doesn´t need to worry about
finding the best audio parameters, work on stop and release, etc.
So far, everything was right.
Yesterday I started trying to process the audio I got from the
microfone input and my code was reacting bad. I revisited it many
times and decided then to check the audio I was getting from the mic.
Created in instance of AudioTrack and tried to play it back. The sound
was horrible, with lots of chopping, lots of distortion and giving me
even the sensation of low samplerate playback (a single word spoken
sometimes lasted for seconds on the earphone).
To check if it was actually my code I went for the internet and found
the code above. Tried it and got the same results. The only thing that
comes to my mind actually is that, it doesn´t matter what I do and the
configuration I try, I always get the buffer overflow message. Even if
I don´t actually do anything but read from AudioRecord and write to
AudioTrack (example above, and not in debug mode). If the emulator can
´t do it fast enought then I´m completly lost here.
Based on the output of my algorithm I think the audio streams I´m
reading are not right.
Have anyone faced this? does anyone know how to solve it? Could anyone
try the code (copy and paste) and check if it´s actually my computer
or my emulator?
package com.example.test;
import android.app.Activity;
import android.content.Context;
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 {
boolean isRecording; //currently not used
AudioManager am;
/** Called when the activity is first created. */
�...@override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
am = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
Record record = new Record();
record.run();
}
public class Record extends Thread
{
// SoundPower sndPower = new SoundPower();
static final int bufferSize = 20;
final short[] buffer = new short[bufferSize];
short[] readBuffer = new short[bufferSize];
public void run() {
isRecording = true;
android.os.Process.setThreadPriority
(android.os.Process.THREAD_PRIORITY_URGENT_AUDIO);
int buffersize = AudioRecord.getMinBufferSize(8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT);
buffersize = 2048;
AudioRecord arec = new
AudioRecord(MediaRecorder.AudioSource.MIC,
8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT,
buffersize);
AudioTrack atrack = new
AudioTrack(AudioManager.STREAM_VOICE_CALL,
8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT,
buffersize,
AudioTrack.MODE_STREAM);
atrack.setPlaybackRate(8000);
byte[] buffer = new byte[buffersize];
arec.startRecording();
atrack.play();
[android-developers] Re: Audio Flickering - my code, my computer or android emulator?
no chopping, likely because my computer (Core2 E8400) is lightening
fast.
my AudioRecord.read() returns a value equal to my buffer size, too.
however, it returns recorded samples in a speed faster than 8khz,
which makes later playback sound like my voice is slowed.
again, the same code works correctly on 1.5 emulator.
so, seems your problem is not the same as mine :(
On Mar 14, 6:53 pm, Gabriel Simões gsim...@gmail.com wrote:
Audio chopping also?
Could you please test the code above?
I´ve checked and AudioRecord.read() returns a value equal to my buffer
size. Based on that I understand that AudioRecord.read() blocks the
execution, waits for the buffer to get a number of samples at least
equal to the buffer size and then it returns the audio stream (older
buffer size number of samples in the AudioRecord internal buffer).
On 14 mar, 22:34, HeHe cnm...@gmail.com wrote:
seems i am experiencing similar issue as you
r.http://groups.google.com/group/android-developers/browse_thread/threa...
without any single line of code modification to my app, the count of
frames recorded by app running on sdk 1.6 emulator is significantly
more than that recorded by the same app running on sdk 1.5 emulator.
however, the same app runs equally well on both 1.5/1.6 emulators.
it is weird.
On Mar 14, 3:00 pm, Gabriel Simões gsim...@gmail.com wrote:
Hello,
Since my day 1 I´ve been facing problems with Android AudioRecord API.
After a lot of research and a lot more trial and error I´ve found my
way into the code and was able to write an asynctask for audio streams
recording which encapsules most of the audiorecord and asynctask
features as a lib, so the developers doesn´t need to worry about
finding the best audio parameters, work on stop and release, etc.
So far, everything was right.
Yesterday I started trying to process the audio I got from the
microfone input and my code was reacting bad. I revisited it many
times and decided then to check the audio I was getting from the mic.
Created in instance of AudioTrack and tried to play it back. The sound
was horrible, with lots of chopping, lots of distortion and giving me
even the sensation of low samplerate playback (a single word spoken
sometimes lasted for seconds on the earphone).
To check if it was actually my code I went for the internet and found
the code above. Tried it and got the same results. The only thing that
comes to my mind actually is that, it doesn´t matter what I do and the
configuration I try, I always get the buffer overflow message. Even if
I don´t actually do anything but read from AudioRecord and write to
AudioTrack (example above, and not in debug mode). If the emulator can
´t do it fast enought then I´m completly lost here.
Based on the output of my algorithm I think the audio streams I´m
reading are not right.
Have anyone faced this? does anyone know how to solve it? Could anyone
try the code (copy and paste) and check if it´s actually my computer
or my emulator?
package com.example.test;
import android.app.Activity;
import android.content.Context;
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 {
boolean isRecording; //currently not used
AudioManager am;
/** Called when the activity is first created. */
�...@override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
am = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
Record record = new Record();
record.run();
}
public class Record extends Thread
{
// SoundPower sndPower = new SoundPower();
static final int bufferSize = 20;
final short[] buffer = new short[bufferSize];
short[] readBuffer = new short[bufferSize];
public void run() {
isRecording = true;
android.os.Process.setThreadPriority
(android.os.Process.THREAD_PRIORITY_URGENT_AUDIO);
int buffersize = AudioRecord.getMinBufferSize(8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT);
buffersize = 2048;
AudioRecord arec = new
AudioRecord(MediaRecorder.AudioSource.MIC,
8000,
AudioFormat.CHANNEL_CONFIGURATION_MONO,
AudioFormat.ENCODING_PCM_16BIT,
buffersize);
AudioTrack atrack = new
