Hi,
Wine's testbt job #4280 http://testbot.winehq.org/JobDetails.pl?Key=4280 contains both a patch and a binary for new MCICDA=MCI CD-audio tests.
It already contains most of what I want in the initial release but would benefit from testing on a broad range of native MS systems. Please invoke it as: mcicda_test.exe mcicda (it generates many failures on Wine but I already wrote several patches to fix them.)
Some failures are still possible as there are a few rough edges, e.g. mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:322: Test failed: PLAY data to 00291d10: MCIERR_OUTOFRANGE mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped.
It skips tests if - there's no disk in drive; - there are no audio tracks; Untested: blank RW disk
Questions: - Is this patch right in mcicda/tests/ or should it be part of winmm/tests/? - Which kind of tests should I restrict to WINETEST_INTERACTIVE mode only? People may start to complain in the near future that running the Wine testsuite starts spinning their CD-ROM and even play music. (like somebody observed that the MIDI testsuite plays a few notes).
Thank you for your contributions, Jörg Höhle
On Wed, Aug 4, 2010 at 10:36 PM, Joerg-Cyril.Hoehle@t-systems.com wrote:
Hi,
Wine's testbt job #4280 http://testbot.winehq.org/JobDetails.pl?Key=4280 contains both a patch and a binary for new MCICDA=MCI CD-audio tests.
It already contains most of what I want in the initial release but would benefit from testing on a broad range of native MS systems. Please invoke it as: mcicda_test.exe mcicda (it generates many failures on Wine but I already wrote several patches to fix them.)
Some failures are still possible as there are a few rough edges, e.g. mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:322: Test failed: PLAY data to 00291d10: MCIERR_OUTOFRANGE mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped.
It skips tests if
- there's no disk in drive;
- there are no audio tracks;
Untested: blank RW disk
Questions: - Is this patch right in mcicda/tests/ or should it be part of winmm/tests/? - Which kind of tests should I restrict to WINETEST_INTERACTIVE mode only? People may start to complain in the near future that running the Wine testsuite starts spinning their CD-ROM and even play music. (like somebody observed that the MIDI testsuite plays a few notes).
I noticed the midi notes playing, didn't think much of it.
Vista 32bit SP2: With a dual mode cd which has a data and audio tracks:
C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:288: track #1 length 76134ms mcicda.c:355: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:361: Test failed: status mode during play is stopped mcicda.c:367: Waiting for delayed notification from pause should abort notification mcicda.c:367: Test failed: Expect message 0004 from pause should abort notification mcicda.c:381: Test failed: PLAY without parms: MCIERR_HARDWARE mcicda.c:390: Test failed: status mode after play is stopped mcicda.c:400: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:406: Test failed: SEEK to 1 notify: MCIERR_HARDWARE mcicda.c:413: Waiting for delayed notification from SEEK aborts mcicda.c:413: Test failed: Expect message 0004 from SEEK aborts mcicda.c:419: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:434: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0002 from command dangling from PLAY mcicda.c:435: Waiting for delayed notification from status mode mcicda.c:435: Test failed: Expect message 0001 from status mode mcicda.c:447: last track length: 04m37s029f mcicda.c:455: Test failed: PLAY (TMSF) from 0000000c to 0925040c: MCIERR_HARDWARE mcicda.c:461: Test failed: status current track gave 1, expected 12 mcicda.c:466: Waiting for delayed notification from STOP notify mcicda.c:466: Test failed: Expect message 0004 from STOP notify mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped.
(Ran it twice, 14 failures each time).
Tried a different cd with audio tracks only:
C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:288: track #1 length 252067ms mcicda.c:355: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:361: Test failed: status mode during play is stopped mcicda.c:367: Waiting for delayed notification from pause should abort notification mcicda.c:367: Test failed: Expect message 0004 from pause should abort notification mcicda.c:381: Test failed: PLAY without parms: MCIERR_HARDWARE mcicda.c:390: Test failed: status mode after play is stopped mcicda.c:400: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:406: Test failed: SEEK to 1 notify: MCIERR_HARDWARE mcicda.c:413: Waiting for delayed notification from SEEK aborts mcicda.c:413: Test failed: Expect message 0004 from SEEK aborts mcicda.c:419: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:434: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0002 from command dangling from PLAY mcicda.c:435: Waiting for delayed notification from status mode mcicda.c:435: Test failed: Expect message 0001 from status mode mcicda.c:447: last track length: 04m54s0252f mcicda.c:455: Test failed: PLAY (TMSF) from 00000005 to 34360405: MCIERR_HARDWARE mcicda.c:461: Test failed: status current track gave 1, expected 5 mcicda.c:466: Waiting for delayed notification from STOP notify mcicda.c:466: Test failed: Expect message 0004 from STOP notify mcicda: 90 tests executed (0 marked as todo, 15 failures), 0 skipped.
(again, 15 failures with a repeated run).
On Wed, Aug 4, 2010 at 4:27 PM, Jeff Zaroyko jeffzaroyko@gmail.com wrote:
I noticed the midi notes playing, didn't think much of it.
That's nothing, some tests record whatever comes via the microphone then play it back. Might be scary if you forget about the tests :)
Octavian
Hi,
Jeff Zaroyko wrote:
mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped.
With a dual mode cd which has a data and audio tracks: mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped. Tried a different cd with audio tracks only: mcicda: 90 tests executed (0 marked as todo, 15 failures), 0 skipped.
Strange, a mixed CD should have executed more tests, like my sample result. I'll add a skip when only audio tracks are found. The only way to have 0 skips flagged would then to use a mixed data + audio CD like you initially did. However those are rare.
Thank you for your feedback. That gives me food to digest later. At a first glance, it looks like nothing was ever played.
Octavian Voicu wrote:
I noticed the midi notes playing, didn't think much of it.
That's nothing, some tests record whatever comes via the microphone then play it back. Might be scary if you forget about the tests :)
That comment really had me ROTFL. It's also me who wrote those tests - recording, midi, mcicda :-) I don't have a microphone.
Regards, Jörg Höhle
Hello,
* On Wed, 4 Aug 2010, Joerg-Cyril.Hoehle@t-systems.com wrote:
Jeff Zaroyko wrote:
mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped.
With a dual mode cd which has a data and audio tracks: mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped. Tried a different cd with audio tracks only: mcicda: 90 tests executed (0 marked as todo, 15 failures), 0 skipped.
Strange, a mixed CD should have executed more tests, like my sample result. I'll add a skip when only audio tracks are found. The only way to have 0 skips flagged would then to use a mixed data + audio CD like you initially did. However those are rare.
would CD Extra disk (with different types of tracks on the same disk) also be interesting to test? In this case single data track goes last.
(I found one such CD today and realised it isn't a Mixed Mode CD which the test needs for the sake of completeness)
S.
Hi,
Saulius Krasuckas wrote:
(I found one such CD today and realised it isn't a Mixed Mode CD which the test needs for the sake of completeness)
Thanks for caring about avoiding skipping tests.
would CD Extra disk (with different types of tracks on the same disk) also be interesting to test? In this case single data track goes last.
Please go ahead -- you could also use test.winehq.org.
According to http://de.wikipedia.org/wiki/Compact_Disc "CD-Extra" is a multi-session disc. So it would be like Jeff Zaroyko's disc. He wrote: http://www.winehq.org/pipermail/wine-devel/2010-August/085823.html
I had a look at the CD I claimed was data+audio with a CDBurnerXP. It's composed of two "sessions" one with audio tracks and the second session is composed of only a data track.
I don't know whether he retried that one with the mcicda tests now in git.
Wikipedia says that the Mixed Mode CDs have been largely replaced with multi-session ones. Given Jeff's output it looks like mcicda only sees the audio section of multi session discs. Care to confirm?
Regards, Jörg Höhle
* On Thu, 2 Sep 2010, Joerg-Cyril.Hoehle@t-systems.com wrote:
According to http://de.wikipedia.org/wiki/Compact_Disc "CD-Extra" is a multi-session disc. So it would be like Jeff Zaroyko's disc.
Yes, both K3B and "Nero Info Tool v2" reports two sessions on my disk.
I don't know whether he retried that one with the mcicda tests now in git.
It would be nice to indicate disks containing tracks of different types (sessions) in the log and to extract some info from the data track. Then we would know for sure :)
Drive info would be also interesting to see in the log.
Wikipedia says that the Mixed Mode CDs have been largely replaced with multi-session ones. Given Jeff's output it looks like mcicda only sees the audio section of multi session discs. Care to confirm?
Already done, it says: "no mixed data+audio CD": http://test.winehq.org/data/cc945706a4933cda0d204ba07a13e93fccb66d18/me_s2-c...
I haven't looked at the code and don't know MCI. Is there nothing more to be done with CD-Extra?
S.
Hi,
Jeff Zaroyko wrote:
mcicda.c:355: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped.
All failures are explained by your drive's inability to play any piece of music from the CD in your system. PLAY fails, causing other tests to fail. Why you'll have to investigate. Did that machine ever play music from an audio CD?
An updated patch with one new bug is at https://testbot.winehq.org/JobDetails.pl?Key=4314 mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION I've added a skip when PLAY returns an error. Native MCICDA does not perform a lot of error checking, e.g. "status c current track" returns 1 when there's no disk in drive.
Things you can try out using the interactive MCI shell: open cdaudio alias c status c type track 1 set c time format tmsf seek c to start play c from 1 to 2 wait play c from 10 to 11 wait seek c to 3 play c close c That's not unlike how apps use mcicda.
Regards, Jörg.
On Thu, Aug 5, 2010 at 6:39 PM, Joerg-Cyril.Hoehle@t-systems.com > Hi,
Jeff Zaroyko wrote:
mcicda.c:355: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped.
All failures are explained by your drive's inability to play any piece of music from the CD in your system. PLAY fails, causing other tests to fail. Why you'll have to investigate. Did that machine ever play music from an audio CD?
Yes, VLC plays from an audio CD without issue, in addition it also works with Jedi Knight: Dark Forces II demo, which plays cd music (despite there being no audio cd for the demo).
An updated patch with one new bug is at https://testbot.winehq.org/JobDetails.pl?Key=4314 mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION I've added a skip when PLAY returns an error. Native MCICDA does not perform a lot of error checking, e.g. "status c current track" returns 1 when there's no disk in drive.
The data+audio cd as previously used:
mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION mcicda.c:243: Test failed: info 2flags: 0=NOERROR mcicda.c:307: track #1 length 76134ms mcicda.c:372: Tests skipped: Got no mixed data+audio CD. mcicda.c:389: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:392: Tests skipped: Cannot manage to play track 1. mcicda: 57 tests executed (0 marked as todo, 3 failures), 2 skipped.
The same audio cd as used previously which has audio only:
mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION mcicda.c:243: Test failed: info 2flags: 0=NOERROR mcicda.c:307: track #1 length 252067ms mcicda.c:372: Tests skipped: Got no mixed data+audio CD. mcicda.c:389: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:392: Tests skipped: Cannot manage to play track 1. mcicda: 57 tests executed (0 marked as todo, 3 failures), 2 skipped.
Indeed, the tests don't produce any audio.
Things you can try out using the interactive MCI shell: open cdaudio alias c status c type track 1 set c time format tmsf seek c to start play c from 1 to 2 wait
This works - I hear music. After playing the first track to completion and waiting a minute, it hasn't returned to accepting input here, so I've ^C.
play c from 10 to 11 wait seek c to 3 play c close c That's not unlike how apps use mcicda.
Regards, Jörg.
Hi,
Things you can try out using the interactive MCI shell: open cdaudio alias c status c type track 1 set c time format tmsf seek c to start play c from 1 to 2 wait This works - I hear music.
What the test does is not fundamentally different. I'd appreciate if you could isolate the part that causes havoc.
status c position resume c # yields MCIERR_HARDWARE seek c to start notify status c type track 1 set c time format tmsf play from <1_or_last_track> notify
waiting a minute, it hasn't returned to accepting input here, so I've ^C.
Really? Wait never failed on me. Did you perhaps get confused because no prompt ever appears? Just hit return to get MCIERR_MISSING_COMMAND_STRING.
The data+audio cd as previously used: mcicda.c:372: Tests skipped: Got no mixed data+audio CD.
The source code led me to believe that data tracks always come first. Perhaps that's a broken assumption. What's the response to: status c type track 1 status c type track 2 status c type track ... until the last one? I'd expect Other [typically 1 single data track] Audio [for track 2..n]
Thank you, Jörg.
On Thu, Aug 5, 2010 at 11:51 PM, Joerg-Cyril.Hoehle@t-systems.com wrote:
Hi,
Things you can try out using the interactive MCI shell: open cdaudio alias c status c type track 1 set c time format tmsf seek c to start play c from 1 to 2 wait This works - I hear music.
What the test does is not fundamentally different. I'd appreciate if you could isolate the part that causes havoc.
if I: open cdaudio alias c status c type track 1 # Response: audio (the same for tracks 1-12, 13 is out of range - only 12 tracks on cd) seek c to start
status c position
mci.c:188: command: status c position mci.c:193: Response: 00:02:00
resume c # yields MCIERR_HARDWARE
nothing printed
seek c to start notify
mci.c:188: command: seek c to start notify mci.c:167: Notification type 0001
status c type track 1
mci.c:188: command: status c type track 1 mci.c:193: Response: audio
set c time format tmsf
no response
play from <1_or_last_track> notify
play from 1 notify mci.c:188: command: play from 1 notify mci.c:191: Test failed: mci play from 1 notify error: 300(44 MCIERR_NOTIFY_ON_AUTO_OPEN)
waiting a minute, it hasn't returned to accepting input here, so I've ^C.
Really? Wait never failed on me. Did you perhaps get confused because no prompt ever appears? Just hit return to get MCIERR_MISSING_COMMAND_STRING.
It stopped accepting input, any letters, return were all blocked - nothing except ^C. I tested it again, same thing happened.
The data+audio cd as previously used: mcicda.c:372: Tests skipped: Got no mixed data+audio CD.
The source code led me to believe that data tracks always come first. Perhaps that's a broken assumption. What's the response to: status c type track 1 status c type track 2 status c type track ... until the last one? I'd expect Other [typically 1 single data track] Audio [for track 2..n]
Every track is listed as audio, meanwhile I see the drive with included programs etc is mapped in explorer.
Thank you, Jörg.
Jeff,
if I:
resume c # yields MCIERR_HARDWARE
nothing printed
This is not compatible with the test that does not report failure on your system: + err = mciSendString("resume c", buf, sizeof(buf), hwnd); + ok(err == MCIERR_HARDWARE, "resume without play: %s\n", dbg_mcierr(err)); /* not NONAPPLICABLE_FUNCTION */ Does any of the previous commands provoke this difference?
play from <1_or_last_track> notify
Oops play c from 1 notify play c from 1 to 2 play c to 12 play c from 12
It stopped accepting input, any letters, return were all blocked - nothing except ^C.
Works for me.
Every track is listed as audio, meanwhile I see the drive with included programs etc is mapped in explorer.
This is behaviour unseen on the w95, w2k and wxp machines that I had access to, with my mixed data+audio CD.
Your machine's behaviour is mystery to me. Is mcicdda that unreliable???
Regards, Jörg Höhle
Guys... I just started looking into developing for the ipad... am i going to have the same issues? I know, i know.. i'm a newbie with objective c. lemme know...
On Thu, Aug 5, 2010 at 8:14 AM, Joerg-Cyril.Hoehle@t-systems.com wrote:
Jeff,
if I:
resume c # yields MCIERR_HARDWARE
nothing printed
This is not compatible with the test that does not report failure on your system:
- err = mciSendString("resume c", buf, sizeof(buf), hwnd);
- ok(err == MCIERR_HARDWARE, "resume without play: %s\n", dbg_mcierr(err)); /* not NONAPPLICABLE_FUNCTION */
Does any of the previous commands provoke this difference?
play from <1_or_last_track> notify
Oops play c from 1 notify play c from 1 to 2 play c to 12 play c from 12
It stopped accepting input, any letters, return were all blocked - nothing except ^C.
Works for me.
Every track is listed as audio, meanwhile I see the drive with included programs etc is mapped in explorer.
This is behaviour unseen on the w95, w2k and wxp machines that I had access to, with my mixed data+audio CD.
Your machine's behaviour is mystery to me. Is mcicdda that unreliable???
Regards, Jörg Höhle
-
Jeff Zaroyko -
Joerg-Cyril.Hoehle＠t-systems.com -
Octavian Voicu -
Robert Kim Wireless Internet Advisor -
Saulius Krasuckas