MSACM: winemp3 codec crashes on seek, reimplement with libmad?
eric.pouech at wanadoo.fr
Wed Feb 8 14:06:29 CST 2006
Alex Villacís Lasso wrote:
> Eric Pouech wrote:
>> > Are there any issues
>>> I should take into account before trying this?
>> first of all, are we sure that the issue comes from the decoder itself
>> (and not some wine wrapper around it) ?
> I performed the following test: with the sample VB application, I
> modified the winemp3 code to write the input buffer (mp3) and the
> decoded output buffer (PCM) at the end of separate files. Then I played
> the mp3 samples file. This one plays correctly (rules out mangling of
> input buffers). The output file has quirks, but plays a little better
> than the output from the VB application (no delays), which suggest that
> there are some timing issues with the winemp3 code, or that the output
> duration, as reported by winemp3, is slightly incorrect.
or simply, that the sequence of:
- getting mp3 encoded data
- pushing them to the decoder for decoding
- pushing the decoded data to the speaker
runs slower than the expected pace...
which doesn't blame only step2, or the decoder itself. for example,
putting the decoder in a separate thread would greatly improve, or using
smaller packets in step 1.
>> the second issue is that MAD is GPL... hence we cannot use it
> Too bad. I was thinking about adding a configure check for libmad and
> linking to it, but then this would still disallow mixing the code. BTW,
> when was the winemp3 code forked form mpg123? Maybe it is high time for
> somebody (me?) to do a resync with the latest version of mpglib.
it's a couple of years old. at the time I looked for it, it was the only
LGPL mp3 decoder that I found.
More information about the wine-devel