|
|
Post by FlexRadioEric on Jan 18, 2005 22:26:14 GMT
I am having trouble getting the Creative Labs MP3+ to work with v2.2 of ASIO4ALL. It has always worked well with v1.8, but since then, we have not been able to get it to work.
I have an MP3+ here now and would be willing to do debugging to help get this issue resolved. Thanks for your work on this awesome piece of software.
|
|
|
|
Post by Michael Tippach on Jan 18, 2005 23:55:26 GMT
I too have an MP3+ for testing and I can confirm that it does not work properly for as long as you use the driver supplied by Creative.
Some weeks ago I posted the necessary (reversible) procedure for switching the MP3+ to use the Windows standard usbaudio.sys driver instead, which works just fine with v2.2.
I have spent hours debugging the issue with the Creative driver and there seems to be no easy fix (unless you disable the input in which case it will work regardless)
On more technical terms, the reason why v1.8 "works" and v2.2 does not lies in the different handling of the kernel streaming interface.
KS input basically works by submitting n buffers to be filled in sequence, each associated with an event that is due to be signalled as soon as the WDM driver has filled the buffer.
v1.8. had four buffers in the queue and would wait for any of them to become signalled whilst maintaining a priority list. E.g. for record we would do the following:
Submit buffer 1, then 2, 3, and 4 and wait on all four associated events, whilst prioritizing buffer 1 over buffer 2 etc.
The behavior of the Creative driver is that it would signal buffer 1 within a reasonable amount of time, then buffer 3, 4... but _never_ buffer 2. ASIO4ALL 1.8 would - in this case -just have lost buffer 2 forever and would continue to run with only 3 input buffers (still enough), which is sort of o.k., but messes up the round trip latency and other advanced stuff.
Since ASIO4ALL v2 is now offering features otherwise only found in the drivers of pro or semi pro grade equipment, an input buffer lost is an error that would mess up input-output syncronisation and which should never occur to begin with - this is clearly a bug in the CT driver.
Technically, v2 would submit up to eight input buffers and then only wait on buffer 1, _then_ buffer 2, 3, 4...
If buffer 2 never gets signalled, we will wait forever.
Of course, it would be possible to implement a workaround for this specific case, but it would be difficult to implement this in a way that would not degrade the performance of everything else!
Since there _is_ a workaround (switching drivers), including a special extra version of the whole audio engine for just the mp3+ with CT drivers may be an option but, to be honest, not an extremely high priority item.
Since I am an MP3+ owner myself, after a couple beers I may decide to invade their support forum, give them a detailed description of the bug and ask (Japanese style) if they can confirm that a fix will be available by the end of February. For some reason I doubt that this would work... whatever... just give me more beer!
;D
|
|
|
|
Post by FlexRadioEric on Jan 19, 2005 20:04:36 GMT
Michael,
I appreciate the detailed reply. I'll do a search for the spot where you describe how to change the driver and provide that for our customers. Thanks very much.
|
|
|
|
Post by FlexRadioEric on Jan 19, 2005 21:55:24 GMT
I have searched through all 5 forums and have not seen a single reference to the MP3+ besides my own. Can you post a link?
|
|
|
|
Post by Michael Tippach on Jan 24, 2005 0:56:58 GMT
|
|
|
|
Post by Michael Tippach on Mar 19, 2005 19:37:38 GMT
V2.5 now also works with the CT supplied WDM driver.
|
|
