Date: Thu, 31 Jul 2014 19:50:23 -0400 From: Dutch Ingraham <stoa@gmx.us> To: freebsd-questions@freebsd.org Subject: Re: Audio CDs Not Playing Message-ID: <53DAD63F.4060100@gmx.us> In-Reply-To: <20140731130130.44eced30@kalimero.tijl.coosemans.org> References: <53D6E32B.7030103@gmx.us> <20140731130130.44eced30@kalimero.tijl.coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53DAD63F.4060100>