Re: Edirol FA-101 and CoreAudio (Jeff Moore)
Re: Edirol FA-101 and CoreAudio (Jeff Moore)
- Subject: Re: Edirol FA-101 and CoreAudio (Jeff Moore)
- From: "Roni Music" <email@hidden>
- Date: Thu, 15 Sep 2005 15:11:07 +0200
Bill,
What you write below about "passing in pointers to memory you don't own!"
is 100% correct and is most probably the problem. I have corrected that
and hope to get feedback from the person with FA-101 interface.
I'm pretty confident this bug is fixed.
I think it would be good if you add the changes to the "afrecord" example.
That example have the same bug.
One thing is not clear to me:
Why must the mDataByteSize be num frames * sizeof(float)
when the mData pointer is NULL?
It would make more sense if it was 0 (which btw works when I test here)
It's then updated after the AudioUnitRender() call
Or maybe you mean, make sure mDataByteSize has the correct value after the AudioUnitRender call,
so the AudioBuffer list is correct?
Anyway, thanks a lot for helping out!
Rolf / Roni Music
> > Subject: Re: Edirol FA-101 and CoreAudio (Jeff Moore)
> > No, I'm doing the same as in the "afrecord" example,
> > using the CABufferList::New() when seting up,
> > destroying it as the last thing.
> > As I see it, that should always be valid, or?
>
> Not necessarily. If the buffer list is an allocated list, then the
> list's pointers should remain fine. If the list's a non-allocated
> list (the mData pointers are NULL), then the first time you return
> from this call your list is now going to contain mData pointers. If
> you then call it again without resetting these to NULL, then you are
> now passing in pointers to memory you don't own!
>
> I've seen cases where this was done - then some kind of format change
> deallocated those pointers, and bang!
>
> > Is there anything else I should do?
> >
> >
> >
> >> You could have a problem where you start off with a
> >> NULL buffer list, you get back a buffer list with pointers, something
> >> about the device changes
> >>
> >
> > Do you mean that something about the device could change at the
> > same time
> > as it's closing down and that I need to have a property listener
> > checking that?
>
> I'm speculating - but if the above were happening, once you closed
> down the AU, then your buffer pointers would now be disposed (because
> they were pointers you didn't own, but were owned by the AU). So, any
> attempt to use the data they pointed too would of course be bad.
>
> I think this is what is happening - the call to New just allocates
> the buffer list, but doesn't allocate pointers (so the FIRST time you
> call AudioUnitRender with this list, these buffer pointers should be
> NULL) - then when you come back from AURender they will have been
> reset to pointers to buffers owned by the AU. So, before you call
> AURender again, those pointers should be set to NULL. You should also
> check that the mDataByteSize has been set up properly (num frames *
> sizeof(float) in this case) - it doesn't look like it has been to me.
>
> Can you check this?
>
> Doug would also be best to check this - but from what I can see
> there's no action to re-establish the integrity of the buffer
> pointers at this time.
>
> Bill
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden