One more way of framing the Issue. Is there a way to access things
with AID_SYSTEM,AID_AUDIO (aka /dev/msm_pcm_out) from an app?
This capability...to record direct from the system. was available on
iphone years ago. so, I see this as a pretty darn pressing issue. Not
to mention that people have be
I have found another way to record audio without using MediaRecorder,
but I'd like to hear feedback from an Android OS/audio expert.
I use the AudioRecord class, which records audio and allows you to
read the data into your own buffer. You can also do something like:
int SAMPLE_RATE_IN_HERTZ = 8
Hi,
Thanks for your mails.
I pressume you did in Java.
Ofcourse, we can do the same thing in C++ also.
But the problem is...
"Buffer Overflow ".
By simply increasing the buffer size won't solve the whole issue.
It may apparently solve buffer overflow, but it will add delay in
playing
If you are worried about delay, you could probably use a small data
chunk size and a large buffer size.
(In my examples, I always used zero for the offset, but you could have
a large buffer and process the data in small chunks. You would
process the chunk at offset=0 first, then process the chunk
I've worked with the audio a lot (especially AudioTrack) and I believe
you have everything correct PJ.
Yesterday I had put together a test app to try playback/record at the
same time and it worked just fine.
You shouldn't get buffer overflow errors if you make a large buffer
and then read from it
In fact what I meant to say as well is in Audiotrack's case, you want
a seperate thread that keeps pushing out new data. The write() method
will block until new data is needed, which is fine. So as long as your
thread can write the data fast enough to keep the buffer full you are
golden.
Now as fa
Ok one last post.
In AudioRecord, the offset and size are the offset in YOUR buffer.
So this isnt that hard. You can use the same values hardcoded if you
want. All you have to do is make sure you are done enough with your
buffer before reading again. So you set AudioRecord's buffer to bigger
than
PJ & Niko,
Thanks for your response.
Yes , whatever you are telling is correct. Using a large buffer will
solve the buffer overflow problem.
http://groups.google.com/group/android-developers/browse_thread/thread/dda83b16eda1f848/beb397cbd5ab073d?lnk=raot
According to above thread (ofcourse, he
Bytes,
To answer your question, I'm using Java.
Two questions for you:
1. Are you testing this on both an emulator and on a real device? You
might have problems on one but not the other. In my case,
simultaneous record+playback is very choppy on the emulator (I have an
Intel Core 2 Duo 1.87GHz
Hi PJ,
Thanks for your response.
Now my requirements got changed, even little bit inconsistency in
voice seems to be OK.
But I've few questions:
1. Lot of my code is developed in C, and I'm porting it on Android
using NDK. So I wanna to avaid JNI for every read/write (to process
the data). For
I'm not familiar with NDK development, so I'm not sure if I can help
you much. However...
It doesn't seem like the "right" solution to pull libraries from an
actual G1 device. I would think that you should get whatever C
libraries you need from some developer repository/SDK instead. Even
if you
Dear Bytes and all experts,
I port one voip app(C code) on android platform and using beagle
board. Now, i also have audio problem in play and record
at the same time using AudioTrack.cpp and AudioRecord.cpp.
I create two threads for audio track and audio record separately.
But record path go
I am pushing for better audio support in the NDK in Bug 3434.
http://code.google.com/p/android/issues/detail?id=3434
Kevin
--
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.
I am pushing for better audio support in the NDK in Bug 3434.
http://code.google.com/p/android/issues/detail?id=3434
Kevin
--
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.
Your app WILL break, guaranteed, on different platform versions and on
different manufacturer's devices. What you are doing is deliberately going
around the supporting APIs of the NDK, to use private APIs. Private APIs are
private usually because they change, and these particular APIs most
certain
15 matches
Mail list logo
