Stefan Sayer wrote:
o Raphael Coeffic [03/09/09 12:47]:
Stefan Sayer wrote:
Raphael Coeffic wrote:
Stefan Sayer wrote:
Raphael, in the crash the following happened:
packet_len=40, TEMPLATE_SEG=80, SEARCH_REGION=110,factor=2
srch_beg=p_buf
srch_end=tmpl-TEMPLATE_SEG-SEARCH_REGION/2+SEARCH_REGION=
tmpl-25=p_buf+15
< 40 > < 40 >
+------------+--------------+--
^ ^ ^
p_buf tmpl p_buf_end
p_buf_begin
< 13>
^
srch
srch was found at position 13, so p_buf_end - srch - TEMPLATE_SEG
becomes negative. I am wondering what that should in this case be.
Or should TEMPLATE_SEG adapted for short frame length? is it still
possible to find good correlation?
Not really... it only works if at least one or two prediods are in
the packet. For one period, it gives us a cut-off frequency of
200Hz (high pass), which is very close to the typical frequency off
the man's voice. The good thing would be to operate on more than
one packet.
what would be needed to do that? more than adding a fixed delay in
the playout buffer for small frame length by operating on time stamp
5ms in the past?
Sounds good. Additionaly, I would process only each second packet,
the other beeing always written right next to the previous one. This
should ensure that you are not adding to much artifacts by
double-processing some packets.
ah, yes, of course. Still, time_scale needs to operate on a past
timestamp I suppose?
Yep! for small packets at least. For the bigger ones, it would be a pity
to introduce more delay...
-Raphael.
Stefan
Cheers
Raphael.
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
