mad-dev September 2007

mad-dev@lists.mars.org

3 participants
2 discussions

memory leaking in mad_layer_III?
by Niels Roosen 27 Sep '07

27 Sep '07

Hello, In the past while I have been rounding up development for a streaming server for the radio station I am part of. However, during the last stress testing phase I noticed that memory usage slowly increases as streaming clients disconnect and connect. At first I was convinced it was some leak in my own code but valgrind didn't confirm that this was happening. However, I noticed that there was quite some lost memory originating in the mad_layer_III() function in layer3.c: ==5957== 7,701 bytes in 3 blocks are definitely lost in loss record 68 of 85 ==5957== at 0x481B72C: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==5957== by 0x485F1C1: mad_layer_III (in /usr/lib/libmad.so.0.2.1) ==5957== by 0x485429A: mad_frame_decode (in /usr/lib/libmad.so.0.2.1) ==5957== by 0x7775: decode_data (server.c:318) ==5957== by 0x9387: server (server.c:980) ==5957== by 0x4874164: pthread_start_thread (in /lib/libpthread-0.10.so) ==5957== by 0x4A176E9: clone (in /lib/libc-2.3.6.so) ==5957== 13,824 bytes in 3 blocks are definitely lost in loss record 71 of 85 ==5957== at 0x481CE9E: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==5957== by 0x485F215: mad_layer_III (in /usr/lib/libmad.so.0.2.1) ==5957== by 0x485429A: mad_frame_decode (in /usr/lib/libmad.so.0.2.1) ==5957== by 0x7775: decode_data (server.c:318) ==5957== by 0x9387: server (server.c:980) ==5957== by 0x4874164: pthread_start_thread (in /lib/libpthread-0.10.so) ==5957== by 0x4A176E9: clone (in /lib/libc-2.3.6.so) One would assume this is just caused by memory not being free()'d up when the program exits, but the longer the server has run, the more memory was definitely lost, indicating that the memory loss originates here. I use the mad library in such a way that I manually line up data and decode this data per frame, which is required to ensure certain functionality of the streaming server. I made sure that when I reinitialize the decoder every time I run the mad_*_finish() operations on all the structs I use before running mad_*_init() again. However, I suspect that not all allocated memory is freed as it should. Am I missing something or could it be that using mad this way hasn't been tested excessively enough and is it true that the memory alllocated in mad_layer_III() on lines 2530 and 2538 (libmad version 0.15.1b) is not freed properly? I would be delighted to either get confirmation on this or some advice on how to solve this issue. If more information is required I will do my best to provide this. Regards, Niels Roosen -- "One of the most frightening things about your true nerd, for many people, is not that he's socially inept - because everybody's been there - but rather his complete lack of embarrassment about it." - Randy Waterhouse in Cryptonomicon n: Arnie / Arnicus | e: niels(a)okkernoot.net w: http://okkernoot.net/ | irc: irc.okkernoot.net #geek | icq: 31817478 aim: arniea a arniea | msn: arnie(a)okkernoot.net http://jungletrain.net/ - 24/7 Drum and Bass Internet Radio

2 4

Calculation error
by Tim Dylla 07 Sep '07

07 Sep '07

Hi List, I did some testing on my own implementation of mp3, and used MAD as reference. Therefore I generated a sine-sweep from 0Hz to 22kHz ( as far as this is possible ;) ) at 0dBFS, and 48kHz Samplerate. Then I encoded it with Lame for a single Channel MPEG-1 Layer III Bitstream, 48kHz Samplerate, 320kbps Bitrate. (I don't know the exact Lame-version and optionstring anymore, but I didn't use anything weird) As expected, the resulting bitstream can be decoded without any obvious error with my Decoder and also with the dist10 decoder. MAD in contrast introduces a perceivable error right on the first half wave of the sine sweep. I think, it's an overflow in the requantization or the IMDCT (when I remember right, the huffman decoder produces very high output at this moment). I used MAD 0.15.2b in conjunction with MADFrontend on a 32bit-Windoze-machine. The option string was -b24 -d I'm not a friend of posting large files on a mailing list without any agreement with the moderator, so if someone is interested in the bitstream and the resulting raw file, pleas feel free to send me a message. With regards, Tim Dylla

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

mad-dev September 2007