Prev: sampling and lag
Next: Unable to get "datetick('x','HHPM')" to work..
From: Roman Kosobrodov on 17 Jun 2010 22:19
G'day,

We are developing some multichannel audio software here in the Sydney Uni using C++. Our code interacts with Matlab through a MEX file that is just a wrapper function calling our dll's. The MEX file receives a Matlab matrix with audio data, passes a pointer to an appropriate function from the dll and returns control to Matlab, while audio is being played or recorded. With 32 input/output channels and floating point data at 48kHz sampling frequency our matrices could be really large so we try to avoid copying them as much as possible.

I have the problem of 'locking' the matrix that is being played so that it could not be cleared by the user while it is still being used by the function from the dll. A similar problem arises when the call to my MEX function contains Matlab expressions resulting in memory being local to the MEX function and released on exit.

Here is an example:
x=rand(1024,1); %random noise
my_audio_function(x); % works fine unless the user does
clear x; % while x is still being used. Also
my_audio_function(rand(1021,1)); % will potentially crash Matlab,
% since the memory is local to my_audio_function

I was unable to find any nice solution to this problem which would not include copying the data to either Matlab workspace or a memory buffer within the dll function. Also, I would like to avoid locking the MEX function in memory if possible.

Is there at least a way to tell if the matrix passed to my_audio_function sits in Matlab workspace (as matrix x in the example above) or is local and needs to be copied?

Any ideas?

Cheers,
Roman
From: James Tursa on 18 Jun 2010 03:52
"Roman Kosobrodov" <roman(a)carlab.ee.usyd.edu.au> wrote in message <hvel2r$4i$1(a)fred.mathworks.com>...
> G'day,
>
> We are developing some multichannel audio software here in the Sydney Uni using C++. Our code interacts with Matlab through a MEX file that is just a wrapper function calling our dll's. The MEX file receives a Matlab matrix with audio data, passes a pointer to an appropriate function from the dll and returns control to Matlab, while audio is being played or recorded. With 32 input/output channels and floating point data at 48kHz sampling frequency our matrices could be really large so we try to avoid copying them as much as possible.
>
> I have the problem of 'locking' the matrix that is being played so that it could not be cleared by the user while it is still being used by the function from the dll. A similar problem arises when the call to my MEX function contains Matlab expressions resulting in memory being local to the MEX function and released on exit.
>
> Here is an example:
> x=rand(1024,1); %random noise
> my_audio_function(x); % works fine unless the user does
> clear x; % while x is still being used. Also
> my_audio_function(rand(1021,1)); % will potentially crash Matlab,
> % since the memory is local to my_audio_function
>
> I was unable to find any nice solution to this problem which would not include copying the data to either Matlab workspace or a memory buffer within the dll function. Also, I would like to avoid locking the MEX function in memory if possible.
>
> Is there at least a way to tell if the matrix passed to my_audio_function sits in Matlab workspace (as matrix x in the example above) or is local and needs to be copied?
>
> Any ideas?

Inside the mex routine you could use the undocumented function mxCreateSharedDataCopy to create a shared data copy of the input. Keep that shared data copy at the top level of your routine (i.e., global), make it persistent, and lock your mex function (why are you opposed to this?). Then if the user clears the original variable in the workspace it will not clear the data memory. When you are done with it then you can destroy the shared data copy using mxDestroyArray and then unlock your mex file.

The reason the following call crashes

> my_audio_function(rand(1021,1)); % will potentially crash Matlab,

is because the rand(1021,1) variable is temporary and created on the fly as an argument. As soon as the function returns this temporary variable is cleared and you have the same situation as your first example when the user manually clears x. Both of these problems can be avoided by using the shared data copy approach since that will prevent MATLAB from freeing the shared data block even if all of the workspace variables that reference it are cleared. By locking your mex routine the one shared data copy that is left is locked up inside it and can't be cleared until the mex routine itself clears it.

James Tursa
From: Roman Kosobrodov on 18 Jun 2010 08:27
Hi James,

Thanks for the quick reply. It seems to be a good solution. I'll try it and post the results.

Cheers,
Roman
 | 
Pages: 1
Prev: sampling and lag
Next: Unable to get "datetick('x','HHPM')" to work..