Feb. 8, 2006
2:06 p.m.
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