[xiph-commits] r12320 - trunk/oss2pulse
xiphmont at svn.xiph.org
xiphmont at svn.xiph.org
Sat Jan 13 02:54:54 PST 2007
Author: xiphmont
Date: 2007-01-13 02:54:53 -0800 (Sat, 13 Jan 2007)
New Revision: 12320
Modified:
trunk/oss2pulse/INSTALL
trunk/oss2pulse/README
Log:
README and INSTALL updates.
Modified: trunk/oss2pulse/INSTALL
===================================================================
--- trunk/oss2pulse/INSTALL 2007-01-13 10:35:18 UTC (rev 12319)
+++ trunk/oss2pulse/INSTALL 2007-01-13 10:54:53 UTC (rev 12320)
@@ -0,0 +1,148 @@
+This is a quick writeup to get the oss2pulse daemon running as things
+stand at 2007-01-11. Things are as yet unfinished, and this applies
+to both fusd and oss2pulse.
+
+Naturally, these steps are intended to be shipped in package form in
+the future.
+
+1) Prereq: PulseAudio is already installed and working.
+ Hopefully, this is as simple as installing a package for your
+ distro.
+
+2) Prereq: The necessary kernel headers/whatever are installed to
+ build new kernel modules. FUSD requires this, as it is a kernel
+ module.
+
+2) fetch the fusd and oss2pulse source. Both live in xiph.org's SVN:
+
+ http://svn.xiph.org/trunk/fusd
+ http://svn.xiph.org/trunk/oss2pulse
+
+ SVN always holds the most up to date copies. Tarballs of the
+ source versions exactly matching the description/instructions
+ in this document are available from:
+
+ http://web.mit.edu/xiphmont/Public/oss2pulse/fusd-monty-20070111.tgz
+ http://web.mit.edu/xiphmont/Public/oss2pulse/oss2pulse-20070111.tgz
+
+ IMPORTANT: You need to use the version of fusd from xiph.org
+ (fusd-monty); it fixes a few bugs and otherwise differs slightly
+ and from the fusd maintained by Kor Nielsen or the much older
+ version originally by Jeremy Elson. Kor and I have been in contact
+ and we'll probably reconcile the differences soon.
+
+3) unpack the fusd source and cd into the source's toplevel
+ directory. 'make' and then as root, 'make install'.
+
+4) For fusd to work properly, you'll need to add the following new
+ udev rule to your udev config (eg, /etc/udev/rules.d/udev.rules
+ under Debian, /etc/udev/rules.d/50-udev.rules on Fedora/RHEL):
+
+ # fusd device
+ SUBSYSTEM=="fusd", NAME="fusd/%k"
+
+5) On systems configured to chown various devices to the console user
+ via pam_concole (RedHat-ish systems), /dev/sndstat should be added
+ to the <sound>= line in /etc/security/console.perms[whatever],
+ something like changing:
+
+ <sound>=/dev/dsp* /dev/audio* /dev/midi* \
+ /dev/mixer* /dev/sequencer \
+ /dev/sound/* /dev/beep \
+ /dev/snd/*
+
+ to
+
+ <sound>=/dev/dsp* /dev/audio* /dev/midi* \
+ /dev/mixer* /dev/sequencer \
+ /dev/sound/* /dev/beep \
+ /dev/snd/* /dev/sndstat
+
+
+ (/dev/sndstat doesn't exist in ALSA emulations and so isn't usually
+ configured in standard distro udev packages. However, there are
+ still many OSS apps that parse the file for device configuration.)
+
+6) Restart udevd to effect the new config (as root, skill udevd;
+ /sbin/udevd -d)
+
+7) modprobe kfusd
+ (The make install ran depmod -a already)
+
+ At this point, the fusd devices /dev/fusd/status and
+ /dev/fusd/control should exist. If the modprobe succeeded but no
+ fusd devices appeared, doublecheck the udev rule config change and
+ make sure udevd restarted successfully. The kfusd kernel module
+ must be inserted after udev has been correctly configured and
+ restarted.
+
+8) unpack the oss2pulse source and cd into the oss2pulse source's
+ toplevel directory. './configure;make' and then as root 'make
+ install'. The oss2pulse daemon is installed setuid root; this is
+ necessary for now, both to talk to the fusd devices (which are root
+ accessible) as well as to set up realtime scheduling.
+
+9) rmmod ALSA's OSS emulation modules, at least for the time being.
+ They'll conflict with the emulation daemon (and are unneccessary
+ once oss2pulse is running):
+
+ /sbin/rmmod snd_pcm_oss snd_mixer_oss
+
+10) Start the pulseaudio daemon (or make sure it is already running).
+ It does not matter if it is run with the console user uid or as
+ root.
+
+11) Start the oss2pulse daemon ('oss2pulse'). It should disply nothing
+ (unless the default debugging output level has been modified in the
+ source file oss2pulse.c). Once you've verified the oss2pulse
+ daemon can start / run properly, you may start it with the -d
+ oprion, which runs it as a detached daemon.
+
+ Verify that /dev/dsp /dev/mixer and /dev/sndstat exist and are
+ accessible by the console user.
+
+Your OSS apps can now talk to PulseAudio.
+
+Troubleshooting:
+
+[I'll fill this in as people send in troubles they've hit in the wild]
+
+1) (Seen on a system I don;t currently have access to, thus the lack
+of a verbose error message): SELinux on Fedora boxes appears to
+partially refuse shared memory access to PulseAudio. Symptoms:
+playback hangs and PulseAudio reports '/dev/shm: access denied' and
+'unable to import memory block'.
+
+I've gotten around this by running pulseaudio as root, anyone know the
+real SELinux fix?
+
+2) "libfusd: /dev/fusd/control does not exist; ensure FUSD's kernel module
+ is installed / Unable to register device: Package not installed"
+
+Libfusd returns this error when /dev/fusd/control doesn't exist. As
+the message says, this could be because kfusd hasn't been loaded. A
+second likely reason is that kfusd is loaded (/sbin/lsmod|grep kfusd)
+but udevd hasn't been configured to create the /dev/fusd entries.
+
+Doublecheck that the udev configuration includes the rule:
+
+ SUBSYSTEM=="fusd", NAME="fusd/%k"
+
+udevd must be restarted for any configuration changes to take effect,
+and kfusd must be loaded after udevd has been reconfigured/reloaded.
+
+3) "libfusd: trying to open FUSD control channel: Permission denied
+ Unable to register device: Illegal seek"
+
+This error means exactly what it says. By default, the /dev/fusd
+devices are accessible only to root. oss2pulse is installed setuid
+root by default, so this issue shouldn't come up using oss2pulse, but
+it will likely affect trying out the various fusd example programs.
+
+3) Libraries not found
+
+By default, all libs instal into /usr/local/lib; make sure that your
+ld.so.conf is configured to search /usr/local/lib for libraries.
+
+Monty
+20070111
\ No newline at end of file
Modified: trunk/oss2pulse/README
===================================================================
--- trunk/oss2pulse/README 2007-01-13 10:35:18 UTC (rev 12319)
+++ trunk/oss2pulse/README 2007-01-13 10:54:53 UTC (rev 12320)
@@ -1,24 +1,82 @@
-[Modified from the oss2jack README written by Kor]
+This is a quick writeup to get the oss2pulse daemon running as things
+stand at 2007-01-11. Things are as yet unfinished, and this applies
+to both fusd and oss2pulse.
-This is an initial release and thus there is currently no
-configuration. This creates a single OSS device that connects to the
-default Pulse source/sink. For now, just make sure pulseaudio is
-running, ALSA OSS emulation is *not* installed, and then run oss2pulse.
+WHAT IT DOES:
-oss2pulse creates the dynamic device node /dev/dsp, the mixer device
-/dev/mixer and /de/sndstat. Make sure, ALSA OSS emulation (or a real
-OSS install) has not already created these devices. Or, use the -n
-command line argument to create an OSS device on an usused number (ie,
-/dev/dspN)
+oss2pulse is an OSS emulation daemon for PulseAudio, much like
+oss2jack for the Jack daemon(1). Using fusd(2), it creates real
+/dev/dsp, /dev/mixer and /dev/sndstat entries that are intended to be
+functionally indistinguishable from real OSS devices, but are
+serviced by the PulseAudio daemon. In this way, legacy OSS
+applications work properly and cooperatively with PulseAudio,
+eliminating the historical problem of 'sound stops working after the
+desktop makes a noise'(3). Thus we can move to Pulse on the
+desktop without affecting legacy OSS apps(4).
-Requirements:
+(1): oss2pulse and oss2jack share some amount of code; I originally
+started porting from oss2jack but found it was easier to start with
+padsp and just use oss2jack as a fusd interaction example.
- - Pulse Audio server
- - a 2.6 kernel with udev
- - kfusd (updated version from xiph.org)
- - udevd rule for fusd:
- SUBSYSTEM=="fusd", NAME="fusd/%k"
+(2): Framework for User Space Devices; allows a daemon to create
+system entries / device entries that can be serviced by a userspace
+application. Despite the similar name, it is not related to FUSE
+(which is used to implement filesystems in userspace) or any of
+the suggested APIs for allowing userspace PCI device drivers. FUSD is
+intended for implementing high-level device-class drivers.
-Monty
+(3): ...and the knee jerk support reaction, 'ps ax, look for esd, and
+kill it.'
+(4): A similar strategy is envisioned for hiding the ALSA devices being
+used by PulseAudio and offering emulated equivalents such that legacy
+ALSA apps can also work through PulseAudio without modification.
+Whether that's done with a similar daemon, through an alternate
+libasound or using an ALSA module, the goal is the same. We *can*
+stamp out dmix in our lifetimes.
+CURRENT STATE:
+
+oss2pulse has just now reached the point of 'worth testing, please
+comment.' The code is sound, but raw and unfinished. Numerous small
+details are incomplete or known to be incorrect. Among them:
+
+1) no mmap support for /dev/dsp yet (should be there within two weeks).
+
+2) no select (poll) yet (should be there in a few days).
+
+3) numerous unimplemented ioctl()s.
+
+4) Mixer mapping is a bit of a hack. See the 'RFC' section.
+
+5) the fusd implementation as yet does not have fully generic class
+ support. It can only create devices of a class that doesn't
+ already exist, but handles the 'sound' class as a special case.
+ This requires a small kernel patch to correct and will be available
+ soon.
+
+Despite these unfinished bits, most OSS apps already work and work
+properly.
+
+THINGS I'D ESPECIALLY LIKE FEEDBACK ON:
+
+1) 'FUSD', which claims to be pronounced 'fused', not 'fuse - dee' is
+confusingly similar to the unrelated FUSE. For fusd to be adopted, it
+needs another name. ("Exodev"? "Userdev"?)
+
+2) FUSD, at the moment, takes as arguments to its registration function a
+'name' and a 'devname'. Confusingly, 'name' specifies the name of the
+device under /dev and 'devname' (not present in the original fusd, it
+appears in Kor's update to kernel 2.6) seems to be a mostly
+meaningless symbol embedded in the registered kobject. Might anyone
+be able to shed some light on why exactly the independent 'devname'
+field is useful?
+
+3) Pulse has no control over the hardware master volume, but the vast
+majority of OSS apps are only capable of using the master and simply
+assume it is there. The plan, not implemented yet, is to have
+'Master' map to the source/sink gain and implement PCM/IGAIN via
+in-daemon software scaling.
+
+Monty
+20070111
\ No newline at end of file
More information about the commits
mailing list