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
A+
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.
A+
--
Eric Pouech
