On Wednesday 09 July 2008 11:44:17 am Maarten Lankhorst wrote:
This reverts commit 8f46a5119249562aceabff6d120948cbfacb6423. The data isn't unused, mp3's can set up 'bit buckets', so while the bit rate is constant, some data is needed anyway for later playback.
I don't believe reverting this is correct. Some apps needed this change to keep from stopping the stream prematurely (indeed, acmwrapper does not make sure all data is flushed out after using all input data). See bug 11659 http://bugs.winehq.org/show_bug.cgi?id=11659.
Hi Chris,
2008/7/9 Chris Robinson chris.kcat@gmail.com:
On Wednesday 09 July 2008 11:44:17 am Maarten Lankhorst wrote:
This reverts commit 8f46a5119249562aceabff6d120948cbfacb6423. The data isn't unused, mp3's can set up 'bit buckets', so while the bit rate is constant, some data is needed anyway for later playback.
I don't believe reverting this is correct. Some apps needed this change to keep from stopping the stream prematurely (indeed, acmwrapper does not make sure all data is flushed out after using all input data). See bug 11659
Try any mp3 in windows media player 10 with and without your patch, it makes mp3 playback there completely broken.
Cheers, Maarten.
On Wednesday 09 July 2008 04:18:50 pm Maarten Lankhorst wrote:
Try any mp3 in windows media player 10 with and without your patch, it makes mp3 playback there completely broken.
As mentioned in the bug http://bugs.winehq.org/show_bug.cgi?id=11805
The problem is either the lack of error propogating from winemp3.acm (all errors by it are swallowed up and acmStreamConvert returns no error), or very small data sources (such that not enough is provided to decode at least one full frame) do need to be buffered. Some testing needs to be done, although http://bugs.winehq.org/show_bug.cgi?id=11659 clearly shows that "extra" data is not held when given enough to produce some output.
-
Chris Robinson -
Maarten Lankhorst