oss2pulse/README

   1 This is a quick writeup to get the oss2pulse daemon running as things
   2 stand at 2007-01-19.  Things are as yet unfinished, and this applies
   3 to both fusd and oss2pulse.
   4
   5 WHAT IT DOES:
   6
   7 oss2pulse is an OSS emulation daemon for PulseAudio, much like
   8 oss2jack for the Jack daemon(1).  Using fusd(2), it creates real
   9 /dev/dsp, /dev/mixer and /dev/sndstat entries that are intended to be
  10 functionally indistinguishable from real OSS devices, but are
  11 serviced by the PulseAudio daemon.  In this way, legacy OSS
  12 applications work properly and cooperatively with PulseAudio,
  13 eliminating the historical problem of 'sound stops working after the
  14 desktop makes a noise'(3).  Thus we can move to Pulse on the
  15 desktop without affecting legacy OSS apps(4).
  16
  17 (1): oss2pulse and oss2jack share some amount of code; I originally
  18 started porting from oss2jack but found it was easier to start with
  19 padsp and just use oss2jack as a fusd interaction example.
  20
  21 (2): Framework for User Space Devices; allows a daemon to create
  22 system entries / device entries that can be serviced by a userspace
  23 application.  Despite the similar name, it is not related to FUSE
  24 (which is used to implement filesystems in userspace) or any of
  25 the suggested APIs for allowing userspace PCI device drivers.  FUSD is
  26 intended for implementing high-level device-class drivers.
  27
  28 (3): ...and the knee jerk support reaction, 'ps ax, look for esd, and
  29 kill it.'
  30
  31 (4): A similar strategy is envisioned for hiding the ALSA devices being
  32 used by PulseAudio and offering emulated equivalents such that legacy
  33 ALSA apps can also work through PulseAudio without modification.
  34 Whether that's done with a similar daemon, through an alternate
  35 libasound or using an ALSA module, the goal is the same.  We *can*
  36 stamp out dmix in our lifetimes.
  37
  38 CURRENT STATE:
  39
  40 oss2pulse has just now reached the point of 'worth testing, please
  41 comment.'  The code is sound, but raw and unfinished.  Numerous small
  42 details are incomplete or known to be incorrect.  Among them:
  43
  44 1) no mmap support for /dev/dsp yet (should be there within two weeks).
  45
  46 2) numerous unimplemented ioctl()s.
  47
  48 3) Mixer mapping is a bit of a hack. See the 'RFC' section.
  49
  50 Despite these unfinished bits, most OSS apps already work and work
  51 properly.
  52
  53 THINGS I'D ESPECIALLY LIKE FEEDBACK ON:
  54
  55 1) 'FUSD', which claims to be pronounced 'fused', not 'fuse - dee' is
  56 confusingly similar to the unrelated FUSE.  For fusd to be adopted, it
  57 needs another name. ("Exodev"?  "Userdev"?)
  58
  59 2) FUSD, at the moment, takes as arguments to its registration function a
  60 'name' and a 'devname'.  Confusingly, 'name' specifies the name of the
  61 device under /dev and 'devname' (not present in the original fusd, it
  62 appears in Kor's update to kernel 2.6) seems to be a mostly
  63 meaningless symbol embedded in the registered kobject.  Might anyone
  64 be able to shed some light on why exactly the independent 'devname'
  65 field is useful?
  66
  67 3) Pulse has no control over the hardware master volume, but the vast
  68 majority of OSS apps are only capable of using the master and simply
  69 assume it is there.  The plan, not implemented yet, is to have
  70 'Master' map to the source/sink gain and implement PCM/IGAIN via
  71 in-daemon software scaling.
  72
  73 Monty
  74 20070117