- Used a persistent variable called "lastExecTime" to keep track of the time when last callback was executed.
- If the elapsed time is less than the sum of "clickInterval" and "extraDelay", the function returns immediately. So, the callback is dropped.
- If enough time has passed then the "lastExecTime" is reset.
How to force audioplayer timer callbacks to use a 'drop' BusyMode rather than 'queue'
조회 수: 7 (최근 30일)
이전 댓글 표시
I am attempting to get audio and video to play together in sync in a MATLAB figure. I am using the audioplayer class to play the audio, and the audioplayer TimerFcn to trigger the video/GUI update. However, sometimes the video/GUI update code takes longer than the period between video frames. Therefore, to keep up with the audio, I need the audioplayer to drop some TimerFcn calls.
The Timer class provides a "BusyMode" property which governs how to handle cases where TimerFcn calls collide. Unfortunately, as far as I can tell, the timer functionality built into the audioplayer object does not provide access to a property like that. The result is that the video/GUI updates lag the audio under some circumstances.
Here is some minimal working example code to illustrate the problem, which generates periodic audible clicks, and for each click, writes to the console.
% Set up audio parameters
Fs = 22050;
duration = 10;
% Click interval is time in seconds between audio clicks
clickInterval = 0.5;
% Set up audio data
t = linspace(0, duration, duration*Fs);
y = double(mod(t, clickInterval) < 0.01);
plot(t, y);
% Set up audio player
ap = audioplayer(y, Fs);
ap.UserData.clickCount = 0;
ap.UserData.clickInterval = clickInterval;
ap.TimerPeriod = 0.5;
ap.TimerFcn = @TimerFcn;
% Start audio player
ap.play()
function TimerFcn(src, ~)
% Issue a notification to the console that TimerFcn has been called
src.UserData.clickCount = src.UserData.clickCount + 1;
fprintf('click: %d\n', src.UserData.clickCount);
% Pause for longer than the click interval - to keep up with the audio,
% callbacks will need to be dropped.
extraDelay = 0.3;
pause(src.UserData.clickInterval + extraDelay);
end
As you can see by running the above, unless you set the extraDelay variable to something less than or equal to zero, the TimerFcn callbacks will lag the audio clicks. Ideally I'd see skipped numbers in the TimerFcn output, indicating that the timer is dropping calls to TimerFcn to keep pace with the audio like a timer in BusyMode='drop', but instead I see consecutive numbers in the TimerFcn output which are lagging the audio, indicating it is behaving like a timer in BusyMode='queue'.
TL;DR: Is there any way to alter the audioplayer timer functionality as though it were a timer in BusyMode='drop' instead of BusyMode='queue' as appears to be the current behavior?
댓글 수: 0
답변 (1개)
Avadhoot
2024년 2월 13일
Hi Brian,
I understand that you are trying to modify the audioplayer timer so that it acts like a timer with "BusyMode" set to 'drop'. You have rightly concluded that the "audioplayer" class does not directly let you set the "BusyMode" property for the timer. However, you can modify your "TimerFcn" such that it behaves like a timer with BusyMode='drop'. The modified code for "TimerFcn" is as follows:
function TimerFcn(src, ~)
persistent lastExecTime;
if isempty(lastExecTime)
lastExecTime = tic; % Initialize the timer
end
currentTime = toc(lastExecTime);
clickIntervalWithDelay = src.UserData.clickInterval + extraDelay;
% Check if the elapsed time since the last execution is less than the
% desired interval plus the extra delay. If so, skip the current callback.
if currentTime < clickIntervalWithDelay
return;
end
% If the function is executing, reset the last execution time.
lastExecTime = tic;
% Issue a notification to the console that TimerFcn has been called
src.UserData.clickCount = src.UserData.clickCount + 1;
fprintf('click: %d\n', src.UserData.clickCount);
% Simulate the processing delay
pause(extraDelay);
end
The notable changes made in the code are as follows:
This way you can simulate the functionality of the dropped callback. You need to keep a few things in consideration before executing this piece of code. If the "TimerFcn" is called repeatedly in rapid succession, then it may cause the "lastExecTime" to not update properly.
Also, using "pause" function within the callback can make the UI unresponsive. Consider using non-blocking methods to handle GUI updates like asynchronous operation or using a dedicated thread.
I hope it helps.
참고 항목
카테고리
Help Center 및 File Exchange에서 Audio and Video Data에 대해 자세히 알아보기
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!