As one of the main entry points, the Muxer class provides function
void executeUntil(Cycle targetCycle);
which runs SID to the specified target cycle and produces some sound samples on its way.
Things would become easier (e.g., the screen recorder implementation) if this function took the number of expected sound samples as an argument. In the screen recorder case, SID will have to produce 882 samples per frame for a sampling frequency of 44100Hz. The current implementation produces between 881 and 883, as the number is derived from the target cycle. This makes the current code error-prone to buffer underflows.
After thinking about this approach a second time, I don't consider it beneficial anymore. For example, all register writes had to be remembered and replayed during sample synthesis (like in vAmiga).
As one of the main entry points, the Muxer class provides function
which runs SID to the specified target cycle and produces some sound samples on its way.
Things would become easier (e.g., the screen recorder implementation) if this function took the number of expected sound samples as an argument. In the screen recorder case, SID will have to produce 882 samples per frame for a sampling frequency of 44100Hz. The current implementation produces between 881 and 883, as the number is derived from the target cycle. This makes the current code error-prone to buffer underflows.