On Jan 5, 12:57 am, Serdel <adam.lichwierow...@gmail.com> wrote: > I have accomplished sth. by using the ByteArrayOutputStream - I divide > the recorder short sample into 2 bytes. Thats again - not as efficient > as It could be but significantly faster than ArrayList.... > > Regarding your code. > > System.arraycopy(mReceivedAudioBufferSrt, 0, > mRecordingDesc.mRecordingSrt, mRecordingEndPos, mBufferFrames); > > What are the declarations of: > a) mReceivedAudioBufferSrt > b) mRecordingDesc.mRecordingSrt
double audioRecordBuffersPerSec = (double) sampleRate / (double) (mBufferFrames / numChannels); int recordingNumAudioRecordBuffers = (int) (audioRecordBuffersPerSec * mRecordingDurationSecs); mRecordingNumFrames = mBufferFrames * recordingNumAudioRecordBuffers; mReceivedAudioBufferSrt = new short[mBufferFrames]; mRecordingDesc.mRecordingSrt = new short[mRecordingNumFrames * numChannels]; I'm not actually looking at my code too carefully, I'm just regurgitating it for you. I would have to study it a bit more to grok the deeper concepts, but that's certainly *what* it's doing...if not so much *why* it's doing it that particular way. :-D > I guest that a) is either an byte or short array (depending on your > PCM encoding). It does look that way. > But most important what is b)? Is it an Array? Yes. > If it is an Array how do you set the size of it ? "Very carefully" from the look of things above. :-) Sigh, it's certainly a bit tricky. > At > least in my app the recording is controlled by start/stop buttons so I > can't predict how long would it be... Or is it another type of > container/stream? Ah, now I see. You have a different problem than I did. My app isn't a recording app, it's a real-time audio analyzer. I allocate the largest possible buffer I can fit into RAM and use that for recording. When I fill the buffer my app offers the option of automatically stopping the recording or looping back to the beginning of the buffer for the purpose of "neverending realtime analysis" such that the final accumulated recording always represents the most recent duration of time of length limited by the RAM buffer. After recording stops, my app offers the option of dumping the buffer to a file on disk, but this is secondary to the app's primary purpose as a real- time analyzer. As such, my app cannot record for tremendously long periods of time (and has received some rude 1-star comments to that effect by morons who fail to honor the fact that it is, at heart, a real-time analyzer and not a recorder. I wish people like that would just disappear off the face of the Earth and leave the rest of us alone.......but that's a discussion for another day. > I still am not able to run ENCODING_PCM_8BIT - the getMinBufferSize > functions returns -2 when I use ENCODING_PCM_8BIT as an argument. I > tried setting up a fixed value of ie 200000 but still no progress - > it's seems stupid that 16 bits is working and 8 bits is not working. > Every phone uses 8bits encoding for transferring human voice... My app has as a little utility in it that performs a full scan of all possible recording settings. It tries every sampling rate between 1 and 44100 with both 1 and 2 byte sample sizes (I fixed the number of channels at 1, no point in trying 2 on a mono-mic I figure). After the scan the app then knows the full capability of the phone and can limit the options is presents to the user to those which are supported by the hardware. I forget off the top of my head whether my G1 supports 8-bit samples. It would seem logical for the reason you just stated, but I don't recall for sure. -- 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
