You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
it seems that it depends on whether JitterBuffer::destroy was set (via jitter-buffer_ctl) which I think could be translated as "If the caller has set up a special deleter for the jitter data, the JitterBuffer will take ownership of the contained data (in the sense that it calls that deleter on it once it is done with it) and otherwise it does not take ownership but instead copies the data to an internal buffer.
I think in the second scenario, it would be good for the overall semantics, if JitterBufferPacket::data would become const char * to indicate that it will not be modified. However, that probably causes issues with the first scenario and also with backwards compatibility.
So in the end, I think it should just be documented more explicitly what happens with the passed pointer and who is responsible for freeing it.
The text was updated successfully, but these errors were encountered:
The
JitterBufferPacket::data
field currently has typechar *
:speexdsp/include/speex/speex_jitter.h
Line 61 in 095fd36
However, from the documentation it is not clear, whether the JitterBuffer will take ownership of the pointer or not. From the code I found here
speexdsp/libspeexdsp/jitter.c
Lines 440 to 447 in 095fd36
it seems that it depends on whether
JitterBuffer::destroy
was set (viajitter-buffer_ctl
) which I think could be translated as "If the caller has set up a special deleter for the jitter data, the JitterBuffer will take ownership of the contained data (in the sense that it calls that deleter on it once it is done with it) and otherwise it does not take ownership but instead copies the data to an internal buffer.I think in the second scenario, it would be good for the overall semantics, if
JitterBufferPacket::data
would becomeconst char *
to indicate that it will not be modified. However, that probably causes issues with the first scenario and also with backwards compatibility.So in the end, I think it should just be documented more explicitly what happens with the passed pointer and who is responsible for freeing it.
The text was updated successfully, but these errors were encountered: