sound quality of video recordings
Sound quality is a lot worse than what I expected. Examples on Youtube:
- 2013-Dec-10 on 1.0.0.5 or 1.0.1.10 ( http://www.youtube.com/watch?v=Ux9xRt6I4I0
- 2014-Jan-31 on 1.0.2.5 http://www.youtube.com/watch?v=7rT12keLUyg
- 2014-Feb-2 on 1.0.3.8 http://www.youtube.com/watch?v=m9lmplh0kpM
- 2015-May-30 on 1.0.7.16 https://youtu.be/EWo1DQwy-44
Copy of comment by @Direc: This is just a guess, but I think that the poor audio quality on recorded video is due to active noise cancellation... At least it sounds to me like it. One could test it by completely blocking the secondary microphone...
Update:
I had some time to hunt this down and came up with an early conclusion. The situation has gotten even worse during system updates and currently I can only record 2-5 sec video until the sound quality drops dramatically during the recording. It seems that the issue relates to btrfs file system used on Jolla. It's rather new Linux implementation not used on too many products yet, and it's still under heavy development. Jolla's camera might be affected by the bugs in it, but there are also other possinbilities. My early conclusion of the workflow on Jolla:
- Video recording starts. Audio and video raw data is buffered into RAM
- Video data is handled by the camera, audio data with pulseaudio. Both are decoded in the CPU
- Writing command are sent to an mp4 file. CPU is in full use according to top
- While writing into the file, RAM buffer gets full of new data. Btrfs file system stalls for a while due do multiple write commands with too short time period in between
- RAM buffer overflows because of delayed writing and parts of the raw audio data are dropped
- Move to step 4... After few seconds and several write commands mp4 file is written with dramatically dropped audio quality
Possible causes and their solutions (in my suspected order):
- Btrfs file system bugs (stalling with too severe write commands)
- Kernel update needed. Jolla uses 3.4. branch (currently on 3.4.91, latest available 3.4.98)
- Too slow writing speed of the internal memory
- Video and audio quality must be downgraded to the level of the hardware performance
- Underperforming CPU
- Can the video raw data be decoded in the Adruino graphic chip instead of CPU leaving pulseaudio more resources?
- Underperforming pulseaudio. Decoding code of pulseaudio (Open Source) is not resource wise.
- Changing the decoded outcome doesn't help, tweaking the decoding method might.
- Lack of RAM
- This is unlikely as if the decoding is working and file writing is fast enough, any amount of free RAM should be enough. I'm just listing this option along as when the RAM buffer gets full, swap file is taken in to use on top of it being much slower in data handling.
Sound quality is indeed terrible, 1 vote up.
Jörg ( 2014-01-20 16:35:28 +0200 )editDoes anyone know a terminal command to stop the secondary microphone (I'd like to test the guess commented by @Direc)?
simo ( 2014-01-20 17:45:29 +0200 )editChangelog 1.0.3.8. mentioned improvements on this, but I didn't notice any (in just a short test) - could this be hardware related anyway? (I sure hope not). Any other experiences?
simo ( 2014-01-31 21:48:50 +0200 )editI could say there is a slight improvement compared to earlier after 1.0.3.8 Naamankajärvi update, but it could be also better too.
TimTTK ( 2014-02-03 16:08:33 +0200 )editthe quality has to be improved, i agree
sauron ( 2014-02-03 21:27:32 +0200 )edit