Hi,
Anton Zagorskiy wrote:
Hello.
Inspecting AmMultiPartyMixer.cpp I’ve found a potential bug.
One instance of the AmMultiPartyMixer maintains a number instances of
the AmConferenceChannel class. So, _/every/_ AmConferenceChannel’s
method ‘put’ and ‘get’ calls _/one pair/_ AmMultiPartyMixer
GetChannelPacket and PutChannelPacket. I think this
(Get/PutChannelPacket) is a critical section and a locking mechanism is
needed.
all participants of the same conference have to be in the same
callgroup (setCallgroup()/changeCallgroup()). All streams that are in
the same call group are processed by the same AmMediaProcessor thread
instance (in case you have more than one), thus don't worry, there is
no locking needed. The same holds if you connect the audio of two
sessions by connecting somehow their audio IO. It is also necessary to
process the streams by the same media processor so that the timestamp
(wallclock ts) is the correct one.
Also, could you explain me how conference reads from a common buffer?
There is the one buffer for multiply AmConferenceChannel. That buffer
has a pointer which locate current buffer position (Yes?). After a ‘get’
event that pointer moves, so next ‘get’ event will read next buffer’s
frame. (Yes?) Since we have N ‘get’ calls (one for each participant)
each participant should hear different sound.
Have a look at AmMultiPartyMixer. For PutChannelPacket() its
mixed_channel = mixed_channel + my_channel and for GetChannelPacket()
it's mixed_channel - my_channel (modulo some scaling). The mixed
channel contains audio of all channels mixed. It's always the ts
(wallclock ts) that is used there as offset in the buffer.
Stefan
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
