1

Sorry for the many posts here regarding this issue but i am having a progress here.

I have a callback function, which is in C , and been called when a new buffer is arrived.

I was told here to not do ANYTHING in that callback ,not malloc , or anything .

Now i want to send my new buffer to another class( which will create a circle buffer and save many buffers).

BUT, the basic thing that i dont get, is that if i call another function from the callback - its the same as doing it in there- becuase in that function i do the DSP and it takes time, so its the same as doing it in that callback- because its in serial.

froof : i am sending the data to another function in another class, and its ok, but if i try to NSLOG it in there, i AGAIN have this memory leaks.

here is the other class that i call from the callback :

    - (id)init 
    {
        self = [super init];
        if (self)

        {
            data = malloc (sizeof(SInt16) * 4000);


        }
        return self;
    }

 -(void)sendNewBuffer:(SInt16*)buffer
    {

        data=buffer;

        NSLog(@"data arrived size is : %lu",sizeof(data));
        for(int i=0; i<sizeof(data);i++)
        {
            NSLog(@"%d",data[i]);
        }

    }

ONLY when comment the log, it works without memory leaks. that means the callback is waiting for that !

How would i process that data somwhere else in parallel ? i am spending a week for that now.

thanks.

user1280535
  • 347
  • 3
  • 13
  • 1
    You need to clarify. Who told you not to do anything? And if they really said "anything" they were being obnoxiously imprecise because the callback wouldn't exist if you couldn't do anything. What you need to know is the details of what you are and are not allowed to do from the callback context. – R.. GitHub STOP HELPING ICE Apr 30 '12 at 16:12
  • Also, on a side note, that's not how you should loop over the buffer data. `sizeof` just returns the size of the parameter data type. You're asking it for the size of a pointer to a signed, 16-bit integer. You're _not_ asking it for the size of the buffer that the pointer points to. You should pass the length of the buffer as a separate argument. – Matt Wilding Apr 30 '12 at 16:19
  • by do stuff i mean DSP and other stuff. probably not empty . – user1280535 Apr 30 '12 at 16:31
  • 2
    @R. idk, the OP may be posting from multiple accounts, referring to the conversation here: http://stackoverflow.com/questions/10378629/how-to-send-a-message-to-self-in-a-c-function-in-obj-c/10378680#10378680 -- or maybe it's just coincidence. if that's the source -- i was quite precise in my wording regarding what should be avoided in realtime audio callbacks. either way, a reference from the OP would help. – justin Apr 30 '12 at 16:32
  • @user1280535 OP = Original Poster or Original Post. – justin Apr 30 '12 at 18:09
  • thanks, this was my fifth post in this issue still dont have this small answer, despite many responses, how EXACTLY and where to DSP my buffer . i am lost – user1280535 Apr 30 '12 at 18:13
  • 2
    If you're not getting good answers I'd suggest that you try to improve your question. The answers below are pretty good guesses at your problem given the information you've provided. – Stephen Darlington Apr 30 '12 at 18:33

3 Answers3

1

One possibility for the memory leak when using Objective-C objects such as the NSString in the NSLog is that those objects may be autoreleased (or may internally used autoreleased objects).

Your callback may be called from a different thread. You can confirm this by putting a breakpoint in the callback and looking in the debugger if this is the main thread or a secondary thread.

Any secondary thread must have its own AutoRelease pool. The system creates one automatically for the main thread, but you must create one explicitly if you are to create a secondary thread.

Also, one reason for not allocating stuff in a callback is usually for performances. Often the callback needs to be kept at minimum to avoid blocking the thread that called it.

J_D
  • 3,526
  • 20
  • 31
  • 1
    thanks but this has no relation to that. even if i did : NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; the same thing happening. – user1280535 Apr 30 '12 at 16:30
1

I would suggest you read a C tutorial. There are at least two problems with your code which we can't really help you with:

  • data=buffer;: this leaks the previous value of data. You need to copy it to data (memcpy) or release the memory first (free) and then keep the pointer... unless the buffer goes out of scope after the callback, in which case your only option is to copy
  • sizeof(data): this can't work. data is a pointer; it doesn't know the amount of data that it being pointed at

The second means that you can't correctly implement the call back, at least not without further information. (Either the buffer has some indication of the volume of data or it's a constant size.)

Stephen Darlington
  • 51,577
  • 12
  • 107
  • 152
  • leave it , forget it. even if i just NSLog a simple word in there, i get this leaks. this is what really is the issue here. – user1280535 Apr 30 '12 at 16:45
0

If I had to guess (and I suppose I do) the callback is probably called in an interrupt context, hence malloc etc. would possibly be fatal. What I would do is copy (ie. memcpy) the data to a buffer, and schedule/signal handling code to run later (eg. using condition variables, a runloop source, etc.)

Hasturkun
  • 35,395
  • 6
  • 71
  • 104