Forwarding this, since it seems stuck in the moderation queue and I have
been unable to track down a list moderator...
--- Begin Message ---
Just in case, for some reason, this doesn't make it to you via
fedora-desktop-list
Monty
---------- Forwarded message ----------
From: Monty Montgomery <monty@xxxxxxxx>
Date: Jan 13, 2007 6:04 AM
Subject: Initial release of oss2pulse and updated fusd
To: Lennart Poettering <lennart@xxxxxxxxxxxxxx>, Pierre Ossman
<drzeus@xxxxxxxxx>, Kor Nielsen <kor@xxxxxxxx>,
fedora-desktop-list@xxxxxxxxxx
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.
WHAT IT DOES:
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).
(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.
(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.
(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.
SETUP:
Follow the directions here, not in the source INSTALL/README docs. I
know for certain the directions here are up to date. I've not yet
updated all the information in the source documentation as inherited
from earlier authors.
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.
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
--- End Message ---
--
Fedora-desktop-list mailing list
Fedora-desktop-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
