1. Application Policy
The policy should be found in debian-multimedia package which contains the policy document and other misc goods for basic Debian Multimedia configuration.
1.1. process
The contents here are discussed in debian-multimedia mailing list.
1.2. configuring user/group settings
group 'audio': members will have access to audio hardware.
group 'video': members will have access to video hardware.
group 'cdrom': members will have access to CD-ROM/DVD-ROM hardware.
Known problems:
User permissions: These permissions are not configured automatically, so requires administrator intervention for every single user added to the system. 147518. By default users will not get video/audio device access and thus can't output audio or use 3D/XVideo(?) acceleration.
See DebianDesktopHowTo to set up automatic group memberships.
Realtime privilege support currently broken: Needs pam support 313588 326555
1.3. well-known device files
/dev/dvd |
symbollic link to DVD device |
/dev/cdrom |
symbollic link to CDROM device |
/dev/audio |
symbollic link to default OSS device |
/dev/dsp |
symbollic link to default OSS device |
1.4. sound input/output selection
When applications try to open a sound device, they should try to detect what sound output device is available. The priority of detection should be
- jack
- esd/arts/etc sound daemons
- alsa
- oss
and the applications should not start jack/esd/arts daemon themselves.
1.4.1. Currently discussed
Do we need to support all or just JACK/ALSA.
artsd supports JACK output
Yes, it is but aRTs is dead. It is no longer maintained upstream and there are no KDE4 applications that use aRTs sound system (Ubuntu has already dropped it). -- AlessioTreglia 2010-08-18 16:53:01
libjackasyn 'jacklaunch' allows OSS to JACK output.
1.5. jack
When connecting to jack as jack client, applications should have a reasonable default output connection. (This point was discussed in linux-audio-user, and trying to guess a default output without knowing what it really is considered not too favorable)
1.6. midi
ideas:
When MIDI is supported, it should have a documented MIDI sequencer input/output device, documented in /usr/share/debian-multimedia/midi/{application} in XXX format
or
Users should be able to specify which ports applications should automagically connect to, configured in /etc/debian-multimedia/midi/XXXX
Example ways of invoking MIDI synthesizer server
timidity |
timidity -B2,7 -Oj -iA |
for the programming interface, it is documented in alsa documentation, which can be found in libasound2-doc package in Debian.
about the protocol, refer to external documentation. e.g. http://www.hinton-instruments.co.uk/midi/midicode.html http://www.borg.com/~jglatt/tech/midispec.htm
1.7. LADSPA
packages should install LADSPA plugins in
/usr/lib/ladspa/*.so
and add a Provides: ladspa-plugin
packages supporting ladspa plugins should seek for LADSPA plugins in
/usr/local/lib/ladspa:/usr/lib/ladspa/ iff LADSPA_PATH is unset.
and add a Recommends: ladspa-plugin (or Depends)
Package names can be taken from upstream names. If the upstream name is ambiguous, or otherwise unsuitable for a Debian package name, the binary package should be named as:
ladspa-pluginname
1.8. DSSI
A DSSI plugin is a LADSPA plugin, and should be packaged similarly to LADSPA plugin.
Currently the packages are named dssi-XXX-XXXX.
dssi-host-XXX |
DSSI hosts |
dssi-plugin(s?)-XXX |
DSSI plugin? none are really packaged yet |
DSSI maintainers, please fill in here.
1.9. LV2 (LADSPA successor)
See /LV2.
1.10. session handling (LASH)
LASH is deprecated as well as ladcca, please use ladish. liblash-compat-dev provides a dummy support for LASH, it is only for backward compatibility.
1.11. Pure Data and other Pd-related things
Here are some fledgling guidelines for packaging Pd-related projects for Debian.
Package Naming
if it is a library that works with any Pd distro, then use a pd- prefix
if it is a library for a specific Pd distro, then use that as the prefix, i.e. puredata- or pdextended-.
Depends
if it will work with and Pd distro, use Depends: pd
if it requires a specific Pd distro, use Depends: puredata, etc.
Build-Depends
If its compiled C, then use Build-Depends: puredata-dev
2. Video Policy
2.1. v4l2
video4linux2 is in the kernel since 2.5.x
2.2. codecs
Each framework (mplayer, xine, vlc, gstreamer) has its own codec system. A codec such as theora is implemented as its own library (libtheora), which is then wrapped up by each of the multimedia frameworks.
MPlayer (from upstream) usually expects to find win32 codec DLLs in /usr/local/lib/codecs.
2.2.1. Free codecs
Applications should be packaged to support free codecs wherever possible, such as Theora and dirac.
2.3. Current Problems
There is no viable standard input/output system for video.
Gstreamer currently fills that gap in most parts.
2.4. Analog Recording Plugins
FIXME: This should probably be moved to a discussion page ... I'm not sure what is meant by this. The answer is LADSPA or LV2 plugins, probably run within ardour or another multi-track recording/editing application. There are several apps in addition to ardour that can group inputs to be routed through a given effect.
Where can info be found for coding plugins for audio captured through a AD/DA converter. i.e. a recording of 8 mics on a drum set but need a compression effect plugin. I see tons of MIDI but can never find stuff like this.