VOGONS

Search

Common searches

ioctl vs. noioctl ways in Vista

Topic actions

Reply 40 of 48, by gidierre

Posted on 
User metadata
Rank Member
Rank
Member
Qbix wrote:

gidierre: Is you cdrom connected analog to your soundcard ?

No, I'd assume not

I mean, this one is a laptop
besides in Vista you know, in dev. mgr. | cdrom unit | properties there's no tab anymore with the button to check/uncheck digital vs. analog output

do you know of some other trick ?

and at any rate dosbox SDL-switched is fine under the very same circumstances.

Reply 42 of 48, by gidierre

Posted on 
User metadata
Rank Member
Rank
Member

Time for an update, as it were.
This is not 100% dosbox development charted territory maybe, but still worth a note imho.

Started enabling log messages into sapucdex.dll, a WinXP staple, but then also a ioctl related fiasco in Vista.

Here's the log :

22:23:58.602 SERVICE 1500 - GET_NUMBER_OF_DRIVES, CF = 0
22:23:58.602 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - STOP_AUDIO, STATUS = 0100, CF = 0
22:23:58.605 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - MEDIA_CHANGED, STATUS = 0100, CF = 0
22:23:58.608 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - DEVICE_STATUS, STATUS = 0100, CF = 0
22:23:58.611 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_DISK_INFO, STATUS = 0100, CF = 0
22:23:58.617 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_TRACK_INFO [TRACK=1], STATUS = 0100, CF = 0
22:23:58.621 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_TRACK_INFO [TRACK=2], STATUS = 0100, CF = 0
22:23:58.624 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_TRACK_INFO [TRACK=3], STATUS = 0100, CF = 0
22:23:58.626 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_TRACK_INFO [TRACK=4], STATUS = 0100, CF = 0
22:23:58.629 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_TRACK_INFO [TRACK=5], STATUS = 0100, CF = 0
22:23:58.632 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_TRACK_INFO [TRACK=6], STATUS = 0100, CF = 0
22:23:58.635 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_TRACK_INFO [TRACK=7], STATUS = 0100, CF = 0
22:23:58.638 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_TRACK_INFO [TRACK=8], STATUS = 0100, CF = 0
22:23:58.641 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_TRACK_INFO [TRACK=9], STATUS = 0100, CF = 0
22:23:58.643 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - IOCTL_INPUT - AUDIO_TRACK_INFO [TRACK=10], STATUS = 0100, CF = 0
22:24:13.493 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - STOP_AUDIO, STATUS = 0100, CF = 0
22:24:13.495 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - SEEK, STATUS = 0100, CF = 0
22:24:13.505 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - PLAY_AUDIO, STATUS = 0300, CF = 0
22:24:21.320 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - STOP_AUDIO, STATUS = 0100, CF = 0
22:24:23.076 SERVICE 1510 - SEND_DEVICE_REQUEST, DRIVE = F: - STOP_AUDIO, STATUS = 0100, CF = 0
22:24:23.123 UserBlockHook

(UserBlockHook is checking out)

No big deal, but I remark the similarity to the dosbox -ioctl debug log.

Here too, for instance, all CF & Status values (resp. 0, 0100 or 0300) all apparently mean green light, success.

By a quick glimpse at sapucdex.c DevPlayAudio() function :

void DevPlayAudio(DRIVE_POINTER *DrvInfo, DEVICE_REQUEST *VdmReq)
{
 DWORD dwOutByteCount, error_code, start_loc, end_loc;
 CDROM_PLAY_AUDIO_MSF play_audio_msf;
 
 if (VdmReq->play_audio.addr_mode == ADDR_MODE_HSG) {
  start_loc = VdmReq->play_audio.loc;
 } else if (VdmReq->play_audio.addr_mode == ADDR_MODE_RB) {
  start_loc = RB2INT((RB_ADDR *)&VdmReq->play_audio.loc);
 } else {
  *(WORD *)&VdmReq->header.status = STATUS_ERR(ERROR_SHARING_VIOLATION);
  return;
 }
 INT2MSF(start_loc, (MSF *)&play_audio_msf.StartingM);
 end_loc = start_loc + VdmReq->play_audio.nsec;
 INT2MSF(end_loc, (MSF *)&play_audio_msf.EndingM);
 if (!DeviceIoControl(DrvInfo->drive_handle, IOCTL_CDROM_PLAY_AUDIO_MSF, &play_audio_msf, sizeof(play_audio_msf), NULL, 0, &dwOutByteCount, NULL)) {
  error_code = ProcessError(DrvInfo, TRUE);
  *(WORD *)&VdmReq->header.status = STATUS_ERR(error_code);
  return;
 }
 DrvInfo->playing = TRUE;
 DrvInfo->paused = FALSE;
 // save start/end play locations (see AUDIO_STATUS_INFO)
 INT2RB(start_loc, (RB_ADDR *)&DrvInfo->play_start);
 INT2RB(end_loc, (RB_ADDR *)&DrvInfo->play_end);
}

is arguably IOCTL_CDROM_PLAY_AUDIO_MSF the unknowing villain here ?

No error_code I saw fall out anyhow.

Reply 43 of 48, by wd

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

IIrc. the no-error ioctl returncode means that the function was successful,
but under vista the play is not initiated so the get-audiostatus returns pause
(or stop or whatever) along with no audio playing.

Reply 44 of 48, by Kippesoep

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

After reading this thread, I decided to give "Lost in Time" a go again to see if I could get it working with sound, but it hangs on startup when using -noioctl. It works fine (albeit without CD sound) when using -ioctl.

Windows Vista SP1, vanilla DOSBox 0.72

Reply 45 of 48, by wd

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

but it hangs on startup when using -noioctl

sdl only provides cdda interfacing, that's why it was removed as default.

It works fine (albeit without CD sound) when using -ioctl

-> use cd images for vista for the moment.

Reply 46 of 48, by gidierre

Posted on 
User metadata
Rank Member
Rank
Member

...another regress report

went about my chore and added much more logging flares to sapucdex.c code
like already done with dosbox, comparing WinXP and Vista as far as ioctl structures and calls are involved.

Logs in relevant sapu Play, Seek and Stop functions aren't especially worth reporting, since they match the elusiveness of returning success values in dosbox -ioctl,
what I find interesting is the output of some checks into ReadTOC()

BOOL ReadTOC(DRIVE_POINTER *DrvInfo) 
{ 
   DWORD   dwOutByteCount; 

   if (DrvInfo->readed_toc) 
      return TRUE; 
   if (!DeviceIoControl(DrvInfo->drive_handle, IOCTL_CDROM_READ_TOC, NULL, 0, &DrvInfo->toc, sizeof(DrvInfo->toc), &dwOutByteCount, NULL)) { 
      ProcessError(DrvInfo, TRUE); 
      return FALSE; 
   } 
   DrvInfo->readed_toc = TRUE; 
   DrvInfo->media_changed = MEDIA_NOT_CHANGED; 

   return TRUE; 
}

After what I understand about CDROM_TOC and TRACK_DATA structs in Ntddcdrm.h I added these log snippets

   // add log 
   UCHAR i,j; 
   UCHAR track_address[10][10]; 
   UCHAR track_number[10]; 
    
   for ( i = 0; i < (DrvInfo->toc.LastTrack); i++) 
      { 
         TRACK_DATA *track = &DrvInfo->toc.TrackData[i]; 
         track_number[i] = track->TrackNumber; 
         LogPrintf(" track number[%d] : %d ", i, track_number[i]);

         for ( j = 0; j < 4; j++) 
            { 
            track_address[i][j] = track->Address[j]; 
            LogPrintf(" track address[%d][%d] : %d ", i, j, track_address[i][j]); 
            } 
      } 
   // end add log

In sapucdex.log they produce, of course only the 1st round when
!(DrvInfo->readed_toc)
a specific outcome, as I devised it, which in fact is an array of track data, like the ones I'll try to extract here in a readable form

  • track number[0] : 1
    track address[0][0] : 0
    track address[0][1] : 0
    track address[0][2] : 2
    track address[0][3] : 0

    track number[1] : 2
    track address[1][0] : 0
    track address[1][1] : 19
    track address[1][2] : 25
    track address[1][3] : 58

    track number[2] : 3
    track address[2][0] : 0
    track address[2][1] : 22
    track address[2][2] : 42
    track address[2][3] : 28

and so on, to the last track #10.

The point is,

when applied under Vista (where music is missing ioctl-wise)
the result is absolutely identical.

I feel I can well spare you the repetition of all those boring track number[] & track address[][] lines : you'd see no difference at all.
ReadTOC reads right in Vista too.
If cdaudio music is missing, it's no question of TOC aberration.

Imho this could exclude any TOC issues from the Vista ioctl quagmire, including the alleged IOCTL_CDROM_READ_TOC obsoleteness
(see my post above from 2008-4-16 @ 01:29 am)
that's vs. IOCTL_CDROM_READ_TOC_EX, since only the former is in use in sapu TOC reading as per code hereto posted.

Last edited by gidierre on 2008-12-19, 01:42. Edited 1 time in total.

Reply 47 of 48, by wd

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

I've just hinted at the TOC stuff some time ago because the ioctl function
that is used is marked as deprecated, so possibly non-functional. In fact
all functions still work under vista, just the play routine doesn't initiate the
actual playing (or something like that).

Reply 48 of 48, by gidierre

Posted on 
User metadata
Rank Member
Rank
Member

finally found somehow a way to circumvent ioctl limitations dooming Sapucdex under Vista (thx wd for your help)
as this really is less dosbox development related than is a general ioctl/Vista subject, not to mention that dosbox already can get around the issue pretty well, I guess I'll be going into it in the pc section/dgVoodoo pertaining thread.

We often forgive those who bore us, but we cannot forgive those whom we bore. (La Rochefoucauld)

Go to top of page Go to top of page
Back to DOSBox Development
Close window
Close window