Please report mcicda (CDROM audio) test results

[Saulius Krasuckas]

* On Fri, 3 Sep 2010, Joerg-Cyril.Hoehle at t-systems.com wrote:
> 
> Saulius Krasuckas wrote:
> >Then we would know for sure :)
> As far as MCICDA is concerned, it doesn't look like it knows about
> multi-sessions.  All it offers is to play music.  Therefore the mcicda
> tests is not the right place to look for a disc utility that'll show
> you information about your drive and disc.

OK, I understand the reason in a case of disc, but couldn't differences 
between drives influence the operation result?

To add more to my question I'm quoting your yesterday letter:

* On Thu, 2 Sep 2010, Joerg-Cyril.Hoehle at t-systems.com wrote:
>
> >Your paranoid android.
> >mci.c:714: Test failed: Expect message 0001 from play to 250 wait notify
> >mci.c:721: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close
> >mci.c:782: Test failed: not enough time elapsed 58ms
> >mci.c:838: Test failed: mci status position: 58
> Sadly, that's the well-known transient flakyness that I blame on
> vmware's timers (or perhaps native bugs?).
>
> Did anybody with a real machine ever get any similar failures?
> That would be more revealing to analyse.

And didn't investigate, but what is your (and anyone other's) opinion 
about testing CD emulators (like Daemon-Tools or WinCDEmu) on real 
machines?  Could they be reliable tool for testing MCICDA, etc. ?

> >me_s2-clean-updated/winmm:mcicda.html
> Ah, that's you, good to know.
> You can help me debug the ME-only errors in winmm:midi
>   midioutXyz returns rc=MMSYSERR_INVALPARAM

OK, switching to private mode :)


S.