Audio CDs Not Playing

[Dutch Ingraham]

On 07/31/2014 07:01 AM, Tijl Coosemans wrote:
> On Mon, 28 Jul 2014 19:56:27 -0400 Dutch Ingraham wrote:
>> Greetings:
>>
>> 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:
>
> --------------------
> [local_ruleset=10]
>
> #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
> /etc/rc.conf:
>
> devfs_system_ruleset="local_ruleset"
>
> 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
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> 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 
2008.))

Thanks again for all your help.