I played a bit with you library, and had a look into its Android implementation, and I believe it does not handle the recorded audio stream correctly.
You don't sync with the AudioRecord's buffer position. You configure that recording buffer to be three times larger than bufferSize given in your library config, and then you just copy as frequent as you can the first third of "recording buffer" to send to the host code. Thus, you definitely loose 2/3 rds of the actual recording stream; and further more because you don't sync with the actual recording position, that position can be inside the data you emit to the listener, thus it may happen that the first part of data you send is actually latest samples, but the last part of the data are samples shifted by ~3 bufferSize into past.
I believe, the correct approach would be to use AudioRecorder's setRecordPositionUpdateListener()/setPositionNotificationPeriod()/setNotificationMarkerPosition() to actually watch the recording position, and then copy consequtive blocks of data just behind that position.
It is a must to have a way to pause the stream. Right now, if the data chunks handling happens slower than you send them in (and you are sending them in as fast as possible, very fast, because it is just a while loop, which only copies / encodes / emits data) your emitted data accumulate in the memory, eventually leading to out of memory crash. Right now .stop() and .run() can be used to pause the stream, but then because you drop two chunks of data on .run() initiation, it leads to loosing some data.
It is really necessary to send timestamps along the data. If the chunk handler is slower than chunks arrival, some chunks should be skipped, and then the timestamps will be helpful to follow the actual position of each chunk inside the stream, and to be aware of lost chunks.
Hi @xiqi,
I played a bit with you library, and had a look into its Android implementation, and I believe it does not handle the recorded audio stream correctly.
You don't sync with the AudioRecord's buffer position. You configure that recording buffer to be three times larger than
bufferSizegiven in your library config, and then you just copy as frequent as you can the first third of "recording buffer" to send to the host code. Thus, you definitely loose 2/3 rds of the actual recording stream; and further more because you don't sync with the actual recording position, that position can be inside the data you emit to the listener, thus it may happen that the first part of data you send is actually latest samples, but the last part of the data are samples shifted by ~3bufferSizeinto past.I believe, the correct approach would be to use AudioRecorder's
setRecordPositionUpdateListener()/setPositionNotificationPeriod()/setNotificationMarkerPosition()to actually watch the recording position, and then copy consequtive blocks of data just behind that position.It is a must to have a way to pause the stream. Right now, if the data chunks handling happens slower than you send them in (and you are sending them in as fast as possible, very fast, because it is just a while loop, which only copies / encodes / emits data) your emitted data accumulate in the memory, eventually leading to out of memory crash. Right now
.stop()and.run()can be used to pause the stream, but then because you drop two chunks of data on.run()initiation, it leads to loosing some data.It is really necessary to send timestamps along the data. If the chunk handler is slower than chunks arrival, some chunks should be skipped, and then the timestamps will be helpful to follow the actual position of each chunk inside the stream, and to be aware of lost chunks.