Audio CDs Not Playing
stoa at gmx.us
Thu Jul 31 23:48:50 UTC 2014
On 07/31/2014 07:01 AM, Tijl Coosemans wrote:
> On Mon, 28 Jul 2014 19:56:27 -0400 Dutch Ingraham wrote:
>> I'm having trouble with playing audio CDs; specifically, they won't
>> play at all. Secondarily, it appears as though, if they would play, I
>> would need to be root to do so.
>> My system stats are as follows: <uname -a>:
>> FreeBSD dutch.freebsd.net 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0:
>> Tue Jul 8 06:37:44 UTC 2014
>> root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>> I am issuing the <cdcontrol -f /dev/cd0 play 1> command and the CD
>> simply will not play, or move in any way. However, if I issue
>> <cdcontrol /dev/cd0 eject>, the CD will eject; if I issue
>> <cdcontrol /dev/cd0 info>, I will receive the tracks information, etc.
>> So it appears as though communication is happening, but the CD will not
>> play. If I issue these commands as a regular user, I receive a
>> "permission denied" message; if run as root, simply nothing happens -
>> no error, nothing. In fact issuing <echo $?> returns 0.
>> I have read the handbook sections on multimedia and setting up the
>> sound card, and believe I've done everything by the book. For example,
>> <pciconf -lv> returns:
>> hdac0 at pci0:0:27:0: class=0x040300 card=0x04201028
>> chip=0x3a6e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation'
>> device = '82801JD/DO (ICH10 Family) HD Audio Controller'
>> class = multimedia
>> subclass = HDA
>> and I have loaded, individually, both the snd_hda and snd_ich drivers
>> with the same result (the hardware notes are ambiguous on this note).
>> The only somewhat useful information is returned by <cdcontrol -v
>> -f /dev/cd0 debug on> which returns:
>> "cdcontrol: Inappropriate ioctl for device" However, a google search
>> has not informed me as to what this means or how to correct.
>> If someone could point me in the correct direction, I'd be appreciative.
>> PS - This issue is not limited to CLI commands; VLC will issue the
>> error "VLC is unable to open the MRL 'cdda:///dev/cd0'. Check the
>> log for details." There is no log info that I can find. In addition, I
>> can burn a cd with xfburn, but only as root.
> cdcontrol sends a special command to let the drive itself play an audio
> cd. This requires that the firmware supports those commands and that
> the drive is connected to your sound card. Modern media players like
> VLC don't play an audio cd like that. Instead they basically read the
> raw data of the cd, apply effects to it like bass, treble and volume
> changes and then send that to your sound card. This is much more
> flexible and is probably the reason why more and more cdrom drives no
> longer support the cdcontrol commands.
> To let users play an audio cd they must have access to /dev/cd0. On
> desktop systems I create a separate group for that called plugdev
> (pluggable devices) and then set permission on /dev/cd0 like this:
> crw-rw---- 1 root plugdev 0x4e 31 jul 08:56 /dev/cd0
> Now users in the plugdev group can access the cdrom. To set these
> permissions you can use chgrp(1) and chmod(1) but this will be reset
> when you reboot. To make these permissions permanent you have to
> create (or modify) /etc/devfs.rules. Mine looks like this:
> #allow plugdev to access the cdrom
> add path cd0 user root group plugdev mode 0660
> #allow plugdev to access usb mass storage
> add path 'da*' user root group plugdev mode 0660
> To activate these rules you must also add the following line to
> These rules also give access to /dev/da* which are usb storage devices,
> but also fixed SCSI disks and you shouldn't allow access to those.
> It's unlikely that you have these in a desktop system, but in case you
> do you can add additional rules to restrict permissions again. For
> instance if /dev/da0 is a fixed SCSI disk add the following:
> add path 'da0' user root group operator mode 0640
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
Thanks everyone for the excellent explanations. To update: I
originally installed vlc, and when that didn't work, I dropped back to
the cli <cdcontrol ...> for its (apparent) ease of use and debugging. I
figured if the cli commands worked, my problem was with vlc, so I could
focus on that; if nether worked, there was likely some lower-lever issue
causing both vlc and the cli commands to fail.
I was wrong. I failed to consider that there could actually be one
failure-type for vlc and one for <cdcontrol>, which is what it looks
like is happening.
I did get vlc working. I can't be positive of what the problem was, but
the vlc failure occurred at about the same time I was having an issue
with gnutls. Specifically, I had installed vlc, which drags gnutls with
it, when I was using ports updated with portsnap. I then changed to svn,
and was having problems with versioning of gnutls. (The problem was a
change from gnutls3-3.1.25_3 to gnutls-3.2.16_3) So, I uninstalled
gnutls, which took vlc with it. Upon reinstalling both, vlc works. I
don't think it was gnutls, but I can't determine with certainty what it
was at this point.
As to Tijl's fantastic explanation above, I've taken your advice and
made those changes, which will undoubtedly save me countless headaches.
I would vote to include that information in the Handbook and the
<cdcontrol> man page (which doesn't appear to have been updated with
this information and which likely affects many users; last updated in
Thanks again for all your help.
More information about the freebsd-questions