Recordings Overlapping #39
Comments
|
Hmm, that's a really weird issue. To make sure I'm understanding, you're saying that the files are always 20 seconds, but sometimes it's:
Is that correct? After work today, I'll make a debug build for you to try out that will not do any encoding/compression and just output a raw |
Yes, I'm always recording for 20 seconds, so originally file should be of 20 seconds long.
So, This is the issue. |
|
Could you give these 2 debug builds a try?
Hopefully the overlapping doesn't occur in the wav files. If it still happens, there's nothing BCR can do to fix it--the raw audio from Android is already broken. |
Both the r2 and r3 files are working fine!
|
|
|
That's good news! So it seems like call recording words, but encoding/compression is broken on your device. Can you try running this apk? CodecDump.zip (It's a regular apk that can be directly installed--not a magisk module.) It should print out something like this: Screenshot_20220528-161832 Can you copy and paste (or upload) that full text here? On my device, there are:
I wonder if the ROM you're running has additional/different encoders that might be broken. |
|
Yeah sure, here you go CodecDump.txt |
|
Hmm, so it uses the same encoders as on my Google Pixel. I wonder why it might be broken. |
Does it(The CodecDump file) changes according to the ROM you're using? |
|
I haven't tried anything besides the stock ROM and pure AOSP. Same codecs in those two.
Do you know if the overlapping issue happens in that stock ROM also? So far, I'm not having any luck troubleshooting what the problem might be. I can't reproduce it on my Pixel and don't have any other devices to test on. I'm adding WAV as a supported output type in version 1.6 so at least you can have something working while we try to fix this. |
On stock ROM, There was Xiaomi's Default call recorder which was using mp3 codec and saving the files in format like "contact name/number(number)_YYYYMMDDTTMMSS.mp3", example: Complaint Helpline(198)_20220409180752.mp3
Yeah, No issues!👍🏻 |
Have this issue. M4A/AAC glitches at like 5-10 seconds in to recording after few seconds it becomes clear and continue to record. When glitches the seek bar on player moves backwards. OGG/Opus has the same issue. |
Oops! I'll find a way to fix that (probably allow the buttons to be on multiple rows).
👍
Oh, that's interesting. Can you link to a download of the stock ROM? Maybe I can figure out what the stock recorder does differently. |
Here is the link for Official Stock ROM.
Hope this helps :) |
|
It looks like that MIUI ROM has different recording methods depending on the output format:
So, it seems like MIUI doesn't use the By the way, a random thought I had: does MIUI have a battery power save mode? If it has a power save mode, does it make any difference for when the overlapping occurs? |
Oh! Then it seems might be using Android's
Yes, I agree MIUI Power Save mode is aggressive. But when I was on MIUI Stock ROM then atleast call recording was working irrespective of Battery Power Save On/Off. There I wasn't using any external call recorder as it was internally supported. But now I'm permanently moved to Pixel ROM (Android:12L) and here Google Dialer's default call recording is also working without any issues which is also recording in wav form! Just incase, This is the link of the Pixel ROM that I'm using. |
This was previously disabled due to incorrect troubleshooting of an
issue where the `c2.android.flac.encoder` component would crash during
recording. It turns out the crash was caused by incorrect math:
inputTimestamp += frames * 1000000 / audioRecord.sampleRate
`frames` and `1000000` are both 32-bit integers, so the multiplication
result overflowed and caused `inputTimestamp` (a 64-bit integer) to
accumulate negative values, which would crash the encoder. This bug was
inadvertently fixed during refactorying in commit
3d3eb82.
This commit reenables the submission of timestamps to MediaCodec. To
avoid accumulated error due to integer division when the microseconds
per sample count is not perfectly divisible, the recording loop will
keep track of the total frame count and only calculate the timestamp
during buffer submission.
This should fix issues where the encoded output files had overlapping
audio or other weird audible artifacts. These were caused by
MediaCodec's multithreaded encoding, where the lack of timestamps would
cause encoded samples to be produced out of order.
Fixes: #39 #54
Signed-off-by: Andrew Gunnerson <[email protected]>
This was previously disabled due to incorrect troubleshooting of an
issue where the `c2.android.flac.encoder` component would crash during
recording. It turns out the crash was caused by incorrect math:
inputTimestamp += frames * 1000000 / audioRecord.sampleRate
`frames` and `1000000` are both 32-bit integers, so the multiplication
result overflowed and caused `inputTimestamp` (a 64-bit integer) to
accumulate negative values, which would crash the encoder. This bug was
inadvertently fixed during refactoring in commit
3d3eb82.
This commit reenables the submission of timestamps to MediaCodec. To
avoid accumulated error due to integer division when the microseconds
per sample count is not perfectly divisible, the recording loop will
keep track of the total frame count and only calculate the timestamp
during buffer submission.
This should fix issues where the encoded output files had overlapping
audio or other weird audible artifacts. These were caused by
MediaCodec's multithreaded encoding, where the lack of timestamps would
cause encoded samples to be produced out of order.
Fixes: #39 #54
Signed-off-by: Andrew Gunnerson <[email protected]>
|
Can you give the test build in #59 a try? I think I may have found the issue 🙂 |
Whoa mate!! It's working perfectly. Debugged All formats with native sample bitrate and flac with 8 level of compression and as of now it's seems working without any issues!!🎉 |
|
Awesome, thanks for testing and being patient with me while troubleshooting this issue! It turns out it was a BCR bug and pretty easy to fix :D I'll release version 1.8 with this fix in a little bit. |
This was previously disabled due to incorrect troubleshooting of an
issue where the `c2.android.flac.encoder` component would crash during
recording. It turns out the crash was caused by incorrect math:
inputTimestamp += frames * 1000000 / audioRecord.sampleRate
`frames` and `1000000` are both 32-bit integers, so the multiplication
result overflowed and caused `inputTimestamp` (a 64-bit integer) to
accumulate negative values, which would crash the encoder. This bug was
inadvertently fixed during refactoring in commit
3d3eb82.
This commit reenables the submission of timestamps to MediaCodec. To
avoid accumulated error due to integer division when the microseconds
per sample count is not perfectly divisible, the recording loop will
keep track of the total frame count and only calculate the timestamp
during buffer submission.
This should fix issues where the encoded output files had overlapping
audio or other weird audible artifacts. These were caused by
MediaCodec's multithreaded encoding, where the lack of timestamps would
cause encoded samples to be produced out of order.
Fixes: #39 #54
Signed-off-by: Andrew Gunnerson <[email protected]>
|
Version 1.8 has been released! |
No issues, Any time :)
Cheers!🎉 |
|
I split out BCR's encoding step into a separate test app to make it a bit easier to test. Can you give this apk a try? MediaCodecAudioEncodeTest.zip It should look something like this: Screenshot_20220601-131928 Can you try selecting a good EDIT: Please also try this BCR debug build with flac + native sample rate. Nothing was changed with the encoding code, I just added a bunch of things for debugging. BCR-1.8.r2.g6eda631-debug.zip It should hopefully produce 3 files in the output directory:
Can you upload those? |
Hi!
Hope this helps:) |
|
Hi Andrew, Problem seems resolved in BCR-1.8.r2.g6eda631! I also install BCR-1.8.r2.g6eda631-debug.zip on my Poco F2 Pro (K30 Pro) and debug files are here: But the main message, i have no error in OGG file (default settings)! what did you change since official 1.8 ? Best Regards, |
|
37 minutes long call with OGG 48kbps, 8000Hz has no error at all! |
|
Thank you both for testing! So from previous tests, we know that recording part was not the problem because the Then, what I suspected was Android's
The top is the So, by itself, there's no problem in the recording and no problem in the encoding. BCR's recording process is essentially:
From @YASHKRAJ's log file, we have: Looking at the log, the buffer is In the logs above, the chunk at
#61 improved the situation by using Android's API to determine what the best buffer/chunk size is. With a smaller buffer size, there's less data to encode each loop, so there's less of a chance of this issue happening. The real fix is to move the encoding process to a different thread. That way, even if encoding is slow, it will not block the recording and won't cause dropped samples. Right now, I'm planning:
The dropped frames from @YASHKRAJ's logs:
|
|
Hi Andrew, I don't fully understand the explanation you provided because I'm not a programmer, but very rarely seen so detailed, so clear precise explanation. Question 1: I don't understand if my log shows 151 drops, why I don't hear any problem in ogg file? |
|
Thanks and no problem!
It might be because of how short the drops are. Yours only exceed the limit a lot more, but only by around 30-35ms and they're pretty consistent (no big jumps). Android can probably tolerate this. YASHKRAJ's had some that were >200ms over and one that was ~800ms over.
The debug build recorded both The CPU load caused by the encoding was slowing down the recording part too much that it affected both the raw audio and the encoded audio.
Yeah, post processing is not a bad idea either.
Definitely! I don't think hardware is the issue. Real-time audio is just hard to get right :) By the way, does your ROM have built-in screen recording with the "device audio and microphone" mode? Screenshot_20220603-004049 I'm curious if the audio is smooth in those recordings. It records almost exactly the same way as BCR's M4A/AAC mode, except it records from the microphone instead of a phone call. |
|
Hi Andrew, |
Issue: #39 #54 Signed-off-by: Andrew Gunnerson <[email protected]>
|
It turns out MediaCodec is already multithreaded so no changes are needed there. In version 1.10, I made one final change to give the recording thread a very high CPU priority. Not sure if it helps, but maybe :) It seems like default OGG/Opus recording is already working well on your devices. I don't think there's anything else I can do to make it better for the slower codecs (eg. FLAC). |
|
Isn't it strange? N.B.: your BCR is very reliable regarding recording calls on A12. (While axet call rec mostly skip recoding calls on A12 devices, idk why) And, no audio source issue in ur app (like some crappy apps uses mic to rec calls). So, your app is robust. I only compared with other apps regarding the overlapping issue (not regarding reliability) |
First of all thanks for continuosly working on this issue to resolve it! What I'd found that v1.9 was very unstable, it had more audio drops in comparison to previous versions. I always try to keep recordings in ogg format but on 1.10 version, When I recorded a 4min 2sec long call then the total duration was only of 2min 42sec and the audio issue started from 2min 24th sec whereas the Google's default recorder which records in wav format had recorded total of 4min 2sec call and it hasn't any audio drop issue. |
No problem! I don't like giving up 🙂
Thank you! I'm trying a slightly different approach this time. Does this debug build help at all? BCR-1.10.r9.g7c88a96-debug.zip (Please upload the audio and I significantly increased the buffer size for recording so that if encoding slows down, it can "absorb" the impact. It should hopefully be able to handle up to an 800ms slowdown spike without causing the overlapping audio (maybe!). There should be no downside to doing this (the latency increases, but doesn't matter for recording purposes). Please let me know if this debug build is somehow worse than previous versions. |
|
1.log.txt |
Exactly! That's why we're still here on the path of resolving this issue :)
Here are the some recordings which have issue and some haven't. Probability of the issue of recordings at 8000Hz sample rate has less comparatively.
|
|
Thanks for the logs! That is interesting. That buffer size is 1/3 of what it is on my Pixel. (I believe this is controlled by the vendor firmware, not by the ROM.) Also, this is is interesting/weird from There should be no reason it takes that long to write < 1KB to the output file. Out of curiosity, do you have BCR configured to record to the internal storage or an SD card?
Ah yep, I forgot to mention this. That option had to be removed to be able to change the buffer size. Otherwise, it has to start recording once to detect the sample rate and then stop and restart again to set the buffer size (might cause a couple seconds at the beginning of the call to be lost).
This part is normal. WAV doesn't support compression, so there's nothing to configure. |
Recording in the SD Card. |
|
I'd tried changing Recording Location previously in the initial builds of BCR but that time the issue was still there and so after that I haven't tried it. But when now changed the location to default I'll test further if I found any issues or it just fixed the issue. |
|
Hi, Still has jumps with BCR 1.10 and also with the BCR-1.10.r9.g7c88a96-debug.
I save the record files here: but this only a virtual "external" -it is on the internal flash, -because my phone doesent have external SD at all. |
|
Hey!! Good news! But this is very strange in my case because i have only built in memory -no SD- so the filesystem speed should not change when i change the location, however the partitions format can be different. Andrew: @chenxiaolong Do you need me to change back to debug and make some debug file? |
|
Awesome! It seems like I created a new debug build: BCR-1.10.r21.gbeb47e0-debug.zip This build always records to the default |
|
Hi, Great job! many thanks! :) |
|
Hi Andrew! All previous changes to BCR as well as this debug build which tricked Android's SAF and which helped to store the recordings in the SD Card flawlessly. BCR going to be the only winner in call recordings for latest Android Builds! Cheers! |
|
🎉 Fantastic, thanks for testing! I'll release version 1.11 after work today with these changes. |
|
It was finally solved, with lots of investigation and work. Many many thanks for this piece of diamond. it is one of the most valuable software on my phone. :) |
Hi @chenxiaolong
I tried latest v1.4 too but the audio recording overlapping is still there!
Say If I record for a 20 seconds long call then sometimes it's the recorded duration only getting 7 seconds, sometimes it's 11 seconds and sometimes whole 20 seconds!
When the duration reducing say for 7 seconds long recording then the remaining recording of 13 seconds seems getting overlapped between 6th to 7th second of the recorded audio!
I've also allowed BCR to run in the background, So there's no issue with getting it killed in background.
The text was updated successfully, but these errors were encountered: