Since the decoding went so much faster, I actually listened to the song I encoded all the way to the end, at which point the thing segv'd. Through a little easter egging, I managed to trace the problem down to a call to vorbis_dsp_clear(). I've just commented it out in the current source. As to why it's segving I am uncertain, but, save possible memory leaks, everything seems to be back in order... Thanks go out to Peter and Monty. Tony Arcieri --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
> Since the decoding went so much faster, I actually listened to the song I > encoded all the way to the end, at which point the thing segv'd. Through > a little easter egging, I managed to trace the problem down to a call to > vorbis_dsp_clear(). I've just commented it out in the current source. > As to why it's segving I am uncertain, but, save possible memory leaks, > everything seems to be back in order...I'll have a look at this now. Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
> As to why it's segving I am uncertain, but, save possible memory leaks, > everything seems to be back in order...I found a likely source of the SEGV; libvorbis was being built with -malign-double, but the XMMS module (and likely XMMS itself) were not. So, libvorbis thinks its structs are bigger than the module is allowing. (I've made the build system consistent, no -malign-double, and I'll check it in in a bit. Too bad; the double alignment is a nice, free optimization). BTW, I did find a memory leak; vorbis_info_clear() has to be called after vorbis_dsp_clear() or some pointers never get freed. the example code had the ordering wrong. This is fixed in the examples and the XMMS plugin now. Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
Monty <xiphmont@xiph.org> writes:> (I've made the build system consistent, no -malign-double, and I'll check it in > in a bit. Too bad; the double alignment is a nice, free optimization).I think you want to use __attribute__ to do this, that way it's in the header file and anything that read that header file gets the same alignment regardless of the compiler options. Making this work with different compilers is still a question though. an example from the gcc(Variable Attributes) info file node: struct foo { int x[2] __attribute__ ((aligned (8))); }; -- greg --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/