summaryrefslogtreecommitdiff
path: root/src/rmd_initialize_data.c
AgeCommit message (Collapse)Author
2020-11-12timer: remove unnecessary timer threadVito Caputo
This removes the timer thread entirely in favor of a coordinated delay loop directly within rmdGetFrame. When there's an audio stream to synchronize with, avd is maintained by the pcm buffer updates, and the fps-derived frametimes synchronize with the audio that way. When there's no audio stream (--no-sound), avd is now maintained synthetically via clock_gettime(CLOCK_MONOTONIC) coordinating with the clock instead. There's been some reworking of frame sampling/reusing and cloning logic, which may need some refinement. But for now the tests seem to show promise. The old timer approach just increased the non-determinism by adding more scheduler latency and influence unnecessarily.
2020-11-11*: add _us suffixes to {frame,period}time namesVito Caputo
Make the names reflect their units of microseconds
2020-11-09cache: introduce "syncer" thread for cache writersVito Caputo
This adds a new flag: --periodic-datasync-ms with a default of 100ms. When a new CacheFile is created for writing, and the datasync period is non-zero, a thread is created for the sole purpose of calling fdatasync() on the underlying fd in a loop separated by sleeps of the specified duration. The purpose of this is to prevent a large backlog of dirty buffers from accumulating until the operating system's normal background dirty sync kicks in. Depending on how the underlying filesystem and storage stack is configured, these bulk writebacks can result in very long stalls on a subsequent write operation. This is easily observed on ext4+lvm+dmcrypt setups, even using a simple test like `dd if=/dev/urandom of=testfile bs=8M`. Despite having plenty of available buffers, once ext4's internal journal fills while a bulk writeback is underway, dd's progress will completely stall until the entire writeback is completed, usually it's in the jbd2 wchan of do_get_write_access(). When this occurs during a recording by recordMyDesktop, the result is dropping frames for the entire duration of the stall. One thing recordMyDesktop could do to insulate from this is perform its own buffering of sampled frames at the YUV stage, with the cache writer consuming from this pool of buffered frames. Then when the cache writer gets stalled on jbd2/dmcrypt holdups, the buffer pool just grows instead of frames being dropped. I may explore this option in the future, but for now simply syncing regularly has been sufficient in my usage, as it keeps the storage subsystem more continuously utilized and spreads out the writebacks so they don't completely back up the journal.
2020-10-08*: more cosmetic formatting cleanupsVito Caputo
Making things a bit more consistent
2020-07-14*: get rid of unused frames_{total,lost}Vito Caputo
these concepts may return but not in this form
2020-07-14types: add avd_mutex to ProgDataVito Caputo
avd accesses aren't serialized currently despite occurring from concurrent threads. I'm reworking avd but this just introduces and initializes a mutex for the existing variable.
2020-07-11*: drop {gtk,qt}-recordmydesktop subdirsVito Caputo
This restores the recordmydesktop/ subdir as root from the mirror I cloned by fork from. I have no particular interest in the gtk/qt frontends and it doesn't appear they were part of a single tree in the past. But I will probably preserve backwards compatibility of the cli so they can continue to work with this fork installed.
© All Rights Reserved