2

I've got a USB 2.0 CD/DVD drive, which is (amongst other use cases) used to play music CDs. But: The drive seems to ignore CDROMPLAYMSF commands.

The host is a Raspberry Pi 3B with the current version of Raspbian. I'm using libcdaudio for audio CD playback, which in turn issues the necessary ioctl commands, including CDROMPLAYMSF.

UPDATE: Upon request, may I hereby give you the specs of my drive, as spit out by the cd-drive utility of cdio:

CD-ROM drive supports MMC 3

                       Drive: /dev/cdrom
Vendor                      : MATSHITA
Model                       : CD-RW  CW-8124  
Revision                    : DA0D

Hardware                                  : CD-ROM or DVD
Can eject                                 : Yes
Can close tray                            : Yes
Can disable manual eject                  : Yes
Can select juke-box disc                  : No

Can set drive speed                       : No
Can read multiple sessions (e.g. PhotoCD) : Yes
Can hard reset device                     : Yes

Reading....
  Can read Mode 2 Form 1                  : Yes
  Can read Mode 2 Form 2                  : Yes
  Can read (S)VCD (i.e. Mode 2 Form 1/2)  : Yes
  Can read C2 Errors                      : Yes
  Can read IRSC                           : Yes
  Can read Media Channel Number (or UPC)  : Yes
  Can play audio                          : Yes
  Can read CD-DA                          : Yes
  Can read CD-R                           : Yes
  Can read CD-RW                          : Yes
  Can read DVD-ROM                        : Yes

Writing....
  Can write CD-RW                         : Yes
  Can write DVD-R                         : No
  Can write DVD-RAM                       : No
  Can write DVD-RW                        : No
  Can write DVD+RW                        : No
3

Originally CD ROM drives (in the IDE era) had an analog audio connection to the motherboard. The SCSI commands PLAY, STOP, SCAN and their variants would then play audio CDs to this analog output just like a standalone CD player.

The CDROMPLAYMSF ioctl issues one of those SCSI commands, namely PLAY AUDIO MSF. MSF defines a position on the CD (in Minutes, Seconds, Frames).

Internal CD ROMs have long lost this feature, as do external USB CD ROMs (there's no analog audio connection to the motherboard). So your CD player rightfully ignores this command.

IIRC the libcdaudio library also has functions to read the digital data from the CD. You need to use those, and then pass on the data to Pulseaudio etc. to playback the CD.

You can also use ready-made command-line tools like mplayer cdda:// for that.

  • OK, then it's unfornunately what I've been afraid of all the time. libcdaudio issues CDROMPLAYMSF, by the way. – Neppomuk Jun 12 at 20:43
0

From Linux kernel source:

CDROMPLAYMSF            Play Audio MSF (struct cdrom_msf)

    usage:

      struct cdrom_msf msf;
      ioctl(fd, CDROMPLAYMSF, &msf);

    inputs:
      cdrom_msf structure, describing a segment of music to play

    outputs:    none

    error return:
      ENOSYS    cd drive not audio-capable.

    notes:
      MSF stands for minutes-seconds-frames
      LBA stands for logical block address

      Segment is described as start and end times, where each time
      is described as minutes:seconds:frames.  A frame is 1/75 of
      a second.

Also, this my answer can be useful for you: Get all ioctl definitions from the kernel source.

I have found the answer to your question by the same way, just changed the grep command a little:

grep -r 'CDROMPLAYMSF' * | vim -

EDIT

from Compact_Disc_Digital_Audio#Data_structure:

The audio data stream in an audio CD is continuous, but has three parts. The main portion, which is further divided into playable audio tracks, is the program area. This section is preceded by a lead-in track and followed by a lead-out track. The lead-in and lead-out tracks encode only silent audio, but all three sections contain subcode data streams.

The lead-in's subcode contains repeated copies of the disc's Table Of Contents (TOC), which provides an index of the start positions of the tracks in the program area and lead-out. The track positions are referenced by absolute timecode, relative to the start of the program area, in MSF format: minutes, seconds, and fractional seconds called frames. Each timecode frame is one seventy-fifth of a second, and corresponds to a block of 98 channel-data frames—ultimately, a block of 588 pairs of left and right audio samples. Timecode contained in the subchannel data allows the reading device to locate the region of the disc that corresponds to the timecode in the TOC. The TOC on discs is analogous to the partition table on hard drives.

Also, from Compact_Disc_Digital_Audio#Frames_and_timecode_frames:

On a Red Book audio CD, data is addressed using the MSF scheme, with timecodes expressed in minutes, seconds and another type of frames (mm:ss:ff), where one frame corresponds to 1/75th of a second of audio: 588 pairs of left and right samples. This timecode frame is distinct from the 33-byte channel-data frame described above, and is used for time display and positioning the reading laser. When editing and extracting CD audio, this timecode frame is the smallest addressable time interval for an audio CD; thus, track boundaries only occur on these frame boundaries. Each of these structures contains 98 channel-data frames, totaling 98 × 24 = 2,352 bytes of music. The CD is played at a speed of 75 frames (or sectors) per second, thus 44,100 samples or 176,400 bytes per second.

In the 1990s, CD-ROM and related Digital Audio Extraction (DAE) technology introduced the term sector to refer to each timecode frame, with each sector being identified by a sequential integer number starting at zero, and with tracks aligned on sector boundaries. An audio CD sector corresponds to 2,352 bytes of decoded data. The Red Book does not refer to sectors, nor does it distinguish the corresponding sections of the disc's data stream except as "frames" in the MSF addressing scheme.

  • 1
    Well…I already know the description in the kernel sources. What I was originally asking for, is: Does the drive just read the audio data from the disc and forward it to the computer as an audio stream (I see no outputs anythere), or does it decode the sound data and spit it out over the sound output (most drives don't even have any more)? – Neppomuk Jun 9 at 20:31
  • @Neppomuk "does it decode the sound data and spit it out over the sound output" - do you mean such type of CD drive and sound card interconnection? Sound Blaster Pro 2.0. And your question is: does the modern SATA optical drive works in the same way or the audio stream goes through operating system only? – MiniMax Jun 9 at 23:35
  • OK, the sound card you are presenting is already quite old, but yes, there used to be CD drives interconnected with the sound card, and yes, this is what I mean: [Connecting external devices: installing CD-ROM drive.] (youtu.be/g15J44xB2zU?t=398) But: My question is still about what the drive does (or is, at least, expected to do) when it gets the abovementioned command, and decoding the sound data and handing it over to the sound card via direct connection, is not the same as handing over the sounds to the host via SATA / SCSI / USB / whatever interface. – Neppomuk Jun 11 at 18:50
  • 2
    @Neppomuk the drive was supposed to decode the audio data itself and send it directly to the sound card -- though a separate cable, not through the ide/ata whatever connection (or directly to the speakers/headphones -- cd drives used to have their own 3.5mm socket) – mosvy Jun 11 at 19:15
  • @Neppomuk I found some information about MSF in wikipedia. See EDIT section in the answer. – MiniMax Jun 11 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.