[asterisk-dev] [Code Review] 2727: Improve disk writes for wav49

[edantie]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2727/#review9373
-----------------------------------------------------------


This change means that now you can't listen a recording call: because you're not updating header until the end of the file. So when you try to reproduce the active call, the header says that there is no chunk in the file.

Maybe we can add an option in mixmonitor, to permit updating header like it was, in case you known you might need to reproduce the file before it close. This facility is important in some call centers.


- edantie


On Aug. 8, 2013, 6:42 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2727/
> -----------------------------------------------------------
> 
> (Updated Aug. 8, 2013, 6:42 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-19595
>     https://issues.asterisk.org/jira/browse/ASTERISK-19595
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> {quote}
> Writing to a wav49 looks a lot like this:
>  * Write GSM frame to end of file
>  * Seek to end of file
>  * Seek to header
>  * Update file size
>  * Seek to end of file
>  * Repeat
> 
> This pattern negates any attempt to use the stdio buffering setup in ast_writefile(). It also results in many small writes that require a seek going to the disk each second which translates to terrible disk performance when there are multiple wav49 files being written at the same time.
> {quote}
> 
> 
> Diffs
> -----
> 
>   /trunk/formats/format_wav_gsm.c 395904 
> 
> Diff: https://reviewboard.asterisk.org/r/2727/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130809/cb8c9ed8/attachment.htm>