audioplayer TimerFcn behavior when busy

Hello there. Does an audioplayer object have an option to cancel calls of TimerFcn when system busy ?

(Like "BusyAction" for graphic objects or "BusyMode" for timer objects)

[Guillaume]

By default is seems to queue. My TimerFcn updates the XData of a line in axes, and (when system busy) I see it move after the playback is complete. I would like to set the busy action to cancel/drop.

[Mario Malic]

Why would system even be busy? Maybe it takes longer time to update plot (because of frequent updates) than the TimerFcn update.

Try increasing the TimerPeriod, you can also check the play and playblocking functions to ensure the proper update.

[Guillaume]

The program is displaying many mesurement channels at high sample rate, quite a lot of data in the end. It runs quite smooth within Matlab, but once compiled it's badly laggy even on recent powerful computers. I tried with twice longer TimerPeriod but it doesn't change much.

[Jan]

@Guillaume: Which behaviour do you want to achieve?

[Mario Malic]

One thing that may be possible, however I am not sure how it would affect the performance of the compiled app. When you use plot, you add line objects, instead you could alter the XData and the YData of the first plotted line object. Example is below

function PlotDataAvailable(src, event)
    [data, timestamps, ~] = read(src, src.ScansAvailableFcnCount, "OutputFormat", "Matrix");
    persistent init fig ax hPlot;
    if isempty(init)
        init = true;
        fig = figure();
        ax = axes(fig);
    end
    if isempty(hPlot)
        hPlot = plot(ax, timestamps, data);     
    else
        hold(ax, "on");
        set(hPlot, "XData", [hPlot.XData, timestamps'], "YData", [hPlot.YData, data'])
    end
end

Otherwise, you should find a way to debug the compiled application, and figure out why does it happen.

Answer 1

[Guillaume]

Thank you gentlemen for your suggestions. It helped a bit but the main problem is how the application goes slow once compiled.

Therefore I'm closing this topic which is in the end not addressing the main issue. I might open a new one to find guidelines to spot what makes a compiled app slow.

[Mario Malic]

I would suggest to print a log document that contains time when some blocks of code are executed. You can identify if the app is overall slower when compiled, or even identify which sections are slower.

[Guillaume]

Do you have some guidelines or reference document to log such data from a compiled app ?

[Mario Malic]

Use diary to save the output of the command windows to a file. Output the needed data to the command window.