[Bug 20323] New: MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

Summary: MacOS mcicda does not play audio CD
           Product: Wine
           Version: 1.1.30
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: kernel32
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

mcicda invokes GetDriveTypeW which returns 3, the same as for C: and other HD
drives. It expects DRIVE_CDROM(5).
E: is not recognized as CD-ROM by Wine, although it is created by the mountmgr.
It points to /Volumes/Audio-CD.  Indeed /Volumes/Audio-CD/ is a directory full
of files named "N Titel NN.aiff", e.g. "2 Titel 02.aiff". e:: points to
/dev/rdisk2

GetDriveTypeW in turn calls:
trace:file:CreateFileW returning 0x68
trace:vxd:DeviceIoControl (0x68,6d4084,0x32f2ac,16,0x32f2ac,16,0x0,0x0)
trace:ntdll:NtDeviceIoControlFile (0x68,0x0,0x0,0x0,0x32f018,0x006d4084,0x3
2f2ac,0x00000010,0x32f2ac,0x00000010)
code=006d4084 (device=6d) is weird, as winioctl.h only lists FILE_DEVICE_* 01
.. 39
I have not looked further into the origin of this code.

Bypassing this test allows mcicda to open cdaudio.
mciSendString: open e: type cdaudio alias y
+ status cdaudio length
+ status cdaudio length 2
+ status cdaudio number of tracks work -- so there's hope -- whereas
- status cdaudio position
- status cdaudio current track
- status cdaudio media present
- seek and
- play fail.
fixme:ntdll:server_ioctl_file Unsupported ioctl 2402c (device=2 access=1 func=b
method=0)
fixme:mcicda:MCICDA_GetError Unknown mode 50

status length etc. show that
DeviceIoControl(wmcda->handle, IOCTL_CDROM_READ_TOC
works.

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|kernel32                    |ntdll

--- Comment #1 from Jörg Höhle   2009-10-11 13:04:21 ---
I see that dlls/ntdll/cdrom.c is lacking
#elif defined(__APPLE__)
 ... code from somebody knowledgeable
from several functions, e.g. CDROM_RawRead, CDROM_PauseAudio,
CDROM_SeekAudioMSF

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

Charles Davis  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #2 from Charles Davis   2009-11-17 19:02:17 ---
OK, I've implemented CDROM_RawRead() and CDROM_ReadQChannel() (well,
partially), and I should have fixed the issue with Wine not properly detecting
a CD-ROM as a CD-ROM (it's because of the contrived way Apple designed the
device file implementation on Mac OS X). But like I said before, I don't think
we can implement CD Audio right now.

The way I see it, there are two options:

1. Make mcicda read files off the disk.
2. Implement a driver to provide some way (ioctls, probably) of doing CD audio.

I don't care either way. If we do it the first way, we'll have to keep track of
the current position, the current track, etc. in mcicda, and we'll probably
have to refactor it into two implementations, one on top of the NT ioctls, and
the other on top of the Mac OS CDDA file system. We'll also need some way to
pass the audio data (which the cddafs driver presents as AIFF, a format that
Apple loves because they invented it) to the audio system. I don't want to
bypass winecoreaudio (that seems kinda dangerous), so I think we should try to
convert the AIFF data to wave format.

If we do it the second way, we can keep only one implementation in mcicda, and
I can implement the NT ioctls on top, but then Wine will have yet another
external dependency--on a kernel-mode component, no less.

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

--- Comment #3 from Jörg Höhle   2009-11-18 11:42:33 ---
> one on top of the NT ioctls, and
> the other on top of the Mac OS CDDA file system.

If you look at MCICDA, you already see 2 implementations: one using DirectSound
and IOCTL_RAW_READ, the other using IOCTL_PLAY_AUDIO.

It is entirely doable to write a file-based MCI cdaudio driver as a kind of
hybrid between mcicda and mciwave. As somebody pointed out in the mailing list,
Gnome-vfs and alike might also benefit from this (could somebody please expand
on this scenario?).

- The sound output I consider trivial -- forward it to wave audio.
  Perhaps write an ACM AIFF to PCM converter to integrate with the wave mapper.
Actually, I consider it a sort of a limitation of the mciwave driver that it is
hard-wired to RIFF formats. Perhaps it could be trivially changed to eat AIFF
as well as MS' RIFF.  Plenty of implementation choices.  Not a single ioctl
would be required (although preferable: don't scan all 20 .aiff files to sum up
the total playing time for status cdaudio length).  It makes for interesting
test cases as I'm not convinced the Wine MCI currently properly supports 2
devices of same type mcicda or mciwave (I'm almost sure it does not (yet)).

- The hard part (because I don't know this area) is the interaction with the
kernel. What must be done on the UNIX side of Wine to make the MS-API layer
believe there's a CD-ROM with a) audio-only data or b) mixed audio and file
data? How does this work with winecfg's virtual drives?  Esp. in case b), the
API must associate both file system access as well as track information with a
unique driver letter like D: (On MacOS, at the user level, you see 2 distinct
mount points in /Volumes/).

Apps typically call nothing more than (that's a real trace, not made up):
open cdaudio [sometimes with shareable]
set cdaudio time format tmsf
status cdaudio mode
status cdaudio number of tracks
play cdaudio from 1 to 2 notify
Or the same with MCI_OPEN etc.

-- So it's preferable that the first CD-ROM in Wine be the real one. (I wonder
how systems behave with 2 real drives, which seems quite common among PC
users).

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

--- Comment #4 from Jörg Höhle   2010-08-07 14:32:17 ---
Created an attachment (id=30045)
 --> (http://bugs.winehq.org/attachment.cgi?id=30045)
Log snippet around failing RAW_READ ioctl

As of 1.3.0, the situation improve quite a bit. Most of comment #3 is obsolete.
I see a possibility to implement mcicda solely with READ_TOC and RAW_READ.
However Wine is not quite there yet:

A. "open cdaudio alias c" fails in the MCI, see comment #0
 I worked around this by explicitly setting the CD-ROM type in winecfg -- and
leaving it open, because restarting Wine seems to reinitialise the type to
"Automatic".

B. TOC missing a 2 seconds offset?
On native and Linux,
"status c position start" typically yields "00:02:00"
On MacOS, it's 00:00:00. It appears that all 
status c position track <N>
are 2 seconds less than on native and Linux (for the same disk).
I can't find where I once read that a CD-ROM has to start with a 2 seconds
offset.

C. RAW_READ fails here with an audio CD
set c time format tmsf
play c from 2 to 3 yields:
cdrom:CDROM_DeviceIoControl 0x40 IOCTL_CDROM_RAW_READ 0x33e310 16 0x187658
91728 0x33de58
cdrom:CDROM_DeviceIoControl opening parent /dev/rdisk1
cdrom:CDROM_RawRead RAW_READ_INFO: DiskOffset=0,151994368 SectorCount=39
TrackMode=2 buffer=0x187658 len=91728 sz=0x33dd4c
ntdll:FILE_GetNtStatus errno = 22 -- EINVAL
RawRead is the topic of the present bug report.

For now, avoid command like
seek c to start/end/xyz
status c position
status c current track
as they use ioctl not supported on the Mac.
I claim that those ioctl are not needed on the Mac (nor Linux) for mcicda
because I could implement it as follows:
- position initially returns position start from the TOC, then what's being
played.
- current track initially returns 1, then what's played.
- seek does no IOCTL_SEEK and simply (performs a range check based on the TOC
and) remembers the position for playing and the status command.

If RAW_READ would work, then all that would be left to do is a proper
separation of the two CD playing modes that mcicda currently implements (which
I'll write about in a new bug report): RAW_READ with dsound vs.
IOCTL_CDROM_PLAY/PAUSE/STOP/RESUME/SEEK_AUDIO.
Currently, the lack of separation causes the MCI commands to report
inconsistent results (e.g. IOCTL SEEK and CURRENT_POSITION are independent from
RAW_READ).

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

--- Comment #5 from Jörg Höhle   2010-08-10 14:46:36 ---
My previous claim is wrong. There's still a need for a little bit of
READ_Q_CHANNEL to implement
status c mode -> be able to return "open"
status c media present
status c ready
Actually, any means to determine whether a disk is present would be fine.

BTW, there's not yet fully correct handling in this sequence:
open cdaudio alias c
status c mode -> ERROR_NOT_SUPPORTED (50)
set c door open (yet disk is not ejected, why? wine eject works)
trace:cdrom:CDROM_DeviceIoControl 0x40 IOCTL_STORAGE_EJECT_MEDIA 0x0 0 0x0 0
0x...
status c mode -> ERROR_INVALID_HANDLE (6)
Somehow, the handle got lost.

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

--- Comment #6 from Jörg Höhle  2011-02-18 07:08:34 CST ---
Charles Davis sent me privately a patch that makes RAW_READ work on MacOS. 
We'll hopefully see in git soon.  I summarise the new state.

+ MCI_PLAY FROM TO works with his patch!

- MCI_PLAY fails because READ_Q_CHANNEL is used to get the current position.
  It should not, see bug #26160, comment #2.

- MCI_SEEK fails because of an IOCTL_CDROM_SEEK_AUDIO_MSF which it should not
invoke at all when using RAW_READ, not PLAY_AUDIO.
  See again bug #26160, comment #2.  mcicda should maintain its own position
variable.

- SET c DOOR OPEN messes up with the internal state (see bug #26160, comment
#1).

- READ_Q_CHANNEL?
status c mode -> be able to return "open"
status c media present
status c ready
Actually, any means to determine whether a disk is present would be fine IMHO.
I believe Loïc Maury's recent patch to CDROM_Verify should not give the idea
that these commands should always return open/present/ready (because a device
node is only present for as long as a disk is present on Mac OS), but that
should be discussed and solved in bug #26158.  On Mac OS currently, MCICDA can
only be opened when an audio CD-ROM is inserted (and correctly configured in
winecfg), unlike native or Linux.

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

--- Comment #7 from Charles Davis  2011-02-18 11:55:56 CST ---
(In reply to comment #6)
> Charles Davis sent me privately a patch that makes RAW_READ work on MacOS. 
> We'll hopefully see in git soon.  I summarise the new state.
> - MCI_PLAY FROM TO works with his patch!
> -
>
> MCI_PLAY fails because READ_Q_CHANNEL is used to get the current position.
> It should not, see bug #26160, comment #2.
> -
>
> MCI_SEEK fails because of an IOCTL_CDROM_SEEK_AUDIO_MSF which it should not
>
> invoke at all when using RAW_READ, not PLAY_AUDIO.
>   See again bug #26160, comment #2.  mcicda should maintain its own position
> variable.

I agree that it doesn't make sense to use the other audio CD IOCTLs when we're
not even using the most important one of all (PLAY_AUDIO). I believe I've said
earlier that I won't ever be able to implement the rest of READ_Q_CHANNEL or
the other audio CD IOCTLs because Apple ripped that support out of Tiger.
> - SET c DOOR OPEN messes up with the internal state (see bug #26160, comment
>
> #1).

Huh. It must be because we have to close all the FDs to the device before
ejecting the disk. ntdll even NtClose()s the Wine handle to the device.

Let's face it. This whole coupling of handles and FDs is stupid--at least on
Mac. Most devices on Mac OS don't even have device files behind them. We need
some way to represent devices in wineserver that doesn't depend on the device
file. But that's a whole other story.
> - READ_Q_CHANNEL?
>
> status c mode -> be able to return "open"
> status c media present
> status c ready
> Actually, any means to determine whether a disk is present would be fine IMHO.
> I believe Loïc Maury's recent patch to CDROM_Verify should not give the idea
> that these commands should always return open/present/ready (because a device
> node is only present for as long as a disk is present on Mac OS), but that
> should be discussed and solved in bug #26158.  On Mac OS currently, MCICDA can
> only be opened when an audio CD-ROM is inserted (and correctly configured in
> winecfg), unlike native or Linux.

As you said, the device node only exists on Mac when there's actually a CD (or
DVD, or whatever) in the drive. To be able to access the drive without a device
node, we'll (well, I'll) have to go beyond the device file into the strange
(for UNIX, anyway) world of I/O Kit--or maybe Disk Arbitration. Which takes us
right back to what I was talking about earlier about coupling device handles to
FDs.

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |26160

--- Comment #8 from Jörg Höhle  2011-02-18 23:02:52 CST ---
Well, I've separate the disk ejection issue into bug #26164 and can confirm
that Charles' patch "ntdll: Fix IOCTL_CDROM_RAW_READ on Mac OS" works fine,
although it is different from what he sent to me initially.

Hence I'm adding bug #26160 - the control path issue - as dependency. Mcicda
will eventually work on MacOS given a clear separation of control paths
(IOCTL_*_AUDIO vs. RAW_READ) and a presumably acceptable work around
READ_Q_CHANNEL:

READ_Q_CHANNEL if (ret = STATUS_NOT_SUPPORTED /* as from _APPLE_ */) then
status media present or ready -> invariably true
status position -> initially as from READ_TOC (typically 00:02 but see comment
#4, point B).

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|Mac OS X 10.5               |Mac OS X

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

--- Comment #9 from Austin English  2013-11-13 16:52:25 CST ---
This is your friendly reminder that there has been no bug activity for 2 years.
Is this still an issue in current (1.7.6 or newer) wine? If so, please attach
the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

WineBuG  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #10 from WineBuG  ---
In Carmageddon 2 on Mac OS X 10.9.2 and with Wine 1.7.17 there's no music (it
is in the audio CD format). However, on Ubuntu it works fine.

Could the problem be related to this bug?

There's a demo:
https://archive.org/download/Carmageddon2CarpocalypseNowDemo/Carmageddon2Dem...

[Bug 20323] MacOS mcicda does not play audio CD

http://bugs.winehq.org/show_bug.cgi?id=20323

--- Comment #11 from WineBuG  ---
The debug trace +mcicda from Carmageddon 2 looks like this:

0027:trace:mcicda:MCICDA_Open (0001, 00003000, 0x2ee224c);
0027:trace:mcicda:MCICDA_Open (0001, 00003100, 0x2ee224c);

[Bug 20323] MacOS mcicda does not play audio CD

https://bugs.winehq.org/show_bug.cgi?id=20323
Bug 20323 depends on bug 26160, which changed state.

Bug 26160 Summary: Broken control path in mcicda
https://bugs.winehq.org/show_bug.cgi?id=26160

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |ABANDONED

[Bug 20323] MacOS mcicda does not play audio CD

https://bugs.winehq.org/show_bug.cgi?id=20323

--- Comment #12 from Austin English  ---
This is your friendly reminder that there has been no bug activity for over a
year. Is this still an issue in current (1.7.51 or newer) wine?

[Bug 20323] MacOS mcicda does not play audio CD

https://bugs.winehq.org/show_bug.cgi?id=20323

--- Comment #13 from WineBuG  ---
Well, the CD music is still not being played in Carmageddon 2 on OS X with Wine
1.7.51.

[Bug 20323] MacOS mcicda does not play audio CD

https://bugs.winehq.org/show_bug.cgi?id=20323
Bug 20323 depends on bug 26160, which changed state.

Bug 26160 Summary: Broken control path in mcicda
https://bugs.winehq.org/show_bug.cgi?id=26160

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |REOPENED
         Resolution|ABANDONED                   |---

[Bug 20323] MacOS mcicda does not play audio CD

https://bugs.winehq.org/show_bug.cgi?id=20323

WineBuG  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 20323] MacOS mcicda does not play audio CD

https://bugs.winehq.org/show_bug.cgi?id=20323

WineBuG  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 20323] MacOS mcicda does not play audio CD

https://bugs.winehq.org/show_bug.cgi?id=20323

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|[e-mail]        |

[Bug 20323] MacOS mcicda does not play audio CD

https://bugs.winehq.org/show_bug.cgi?id=20323

Ken Thomases  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|[e-mail]         |

[Bug 20323] MacOS mcicda does not play audio CD

https://bugs.winehq.org/show_bug.cgi?id=20323

--- Comment #14 from WineBuG  ---
*** Bug 34599 has been marked as a duplicate of this bug. ***

[Bug 20323] MacOS mcicda does not play audio CD

https://bugs.winehq.org/show_bug.cgi?id=20323

Zevans  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]