Hi Robert,
Robert Reif wrote:
Makes the PCM conversion routines of msacm produce identical results to the native dll. Allow any PCM to PCM conversion, not just advertised ones.
The algorithms used by Microsoft in this dll are very crude and produce an output of much poorer quality than what is currently in wine. This is unfortunate but unavoidable if we are to be compatible.
I don't see how improving the quality of the conversion could cause problems. Is there an app out there that refuses to run or crashes because of that? The algorithms may have slightly changed across all versions of this dll. And if we can do better job than Microsoft, I think we should do it.
I have a test program that was used to verify compatibility and can make it available by request. I hope to integrate some of it into the regression tests someday.
Bye, Christian
Christian Costa a écrit :
Hi Robert,
Robert Reif wrote:
Makes the PCM conversion routines of msacm produce identical results to the native dll. Allow any PCM to PCM conversion, not just advertised ones.
The algorithms used by Microsoft in this dll are very crude and produce an output of much poorer quality than what is currently in wine. This is unfortunate but unavoidable if we are to be compatible.
I don't see how improving the quality of the conversion could cause problems. Is there an app out there that refuses to run or crashes because of that? The algorithms may have slightly changed across all versions of this dll. And if we can do better job than Microsoft, I think we should do it.
I'd agree that what we don't need byte compatibility for the audio conversions. We should be compatible OTOH on the size of the buffers sent out (not sure it's always the case), which may cause some problems in some cases. A+
Eric Pouech wrote:
I'd agree that what we don't need byte compatibility for the audio conversions. We should be compatible OTOH on the size of the buffers sent out (not sure it's always the case), which may cause some problems in some cases. A+
The number of bytes read and written was the original issue that I was investigating. The original code actually wrote past the end of the buffer at one point before I corrected that a long time ago. The Microsoft code will not read and/or write the entire contents of the buffers under some circumstances. Duplicating this behavior lead to the code I have presented.
Any audio programmer concerned about the quality of conversions will stay as far away from Microsoft code as possible.
On Sat, 11 Dec 2004 09:29:21 -0500, Robert Reif wrote:
The Microsoft code will not read and/or write the entire contents of the buffers under some circumstances. Duplicating this behavior lead to the code I have presented.
What bugs did this behaviour cause? If it's purely a matter of correctness with no known negative side-effects I'm not sure it should go in ...
Eric Pouech wrote:
Christian Costa a écrit :
Hi Robert,
Robert Reif wrote:
Makes the PCM conversion routines of msacm produce identical results to the native dll. Allow any PCM to PCM conversion, not just advertised ones.
The algorithms used by Microsoft in this dll are very crude and produce an output of much poorer quality than what is currently in wine. This is unfortunate but unavoidable if we are to be compatible.
I don't see how improving the quality of the conversion could cause problems. Is there an app out there that refuses to run or crashes because of that? The algorithms may have slightly changed across all versions of this dll. And if we can do better job than Microsoft, I think we should do it.
I'd agree that what we don't need byte compatibility for the audio conversions. We should be compatible OTOH on the size of the buffers sent out (not sure it's always the case), which may cause some problems in some cases.
Agreed. :-)
Bye, Christian
-
Christian Costa -
Eric Pouech -
Mike Hearn -
Robert Reif