[Desktop_architects] Making Sound On Linux Just Work
Leon Shiman
leon at magic.shiman.com
Tue Dec 13 12:36:29 PST 2005
Ignoring the 5 years of work that was done on MAS
(http://www.MediaApplicationServer.net) - with the endorsement and
participation of the Sun, IBM, HP, Hummingbird, and WRQ sponsors of X.Org,
may be a little shortsighted - don't you think?
It is also useful to ask just which user's needs are being represented? What
is the first target for an audio/media capability as an integral desktop
technology?
Prioritization of requirements is a necessary first step.
Leon
>Date: Tue, 13 Dec 2005 15:19:24 -0500
>From: Paul Davis <paul at linuxaudiosystems.com>
>To: desktop_architects at lists.osdl.org
>Subject: [Desktop_architects] Making Sound On Linux Just Work
>
>Given the ongoing firefighting over such trivialities as printing and
>usablenessfulility, it seems time for a Now For Something Completely
>Different moment. After an insane week at work, I finally managed to
>collate and organize a first pass at an initial analysis of what audio
>needs. Now its your turn to shoot it down, tear it up or pat me on the
>back. Anyone calling me a FUCKING IDIOT will be met with indifference
>and ambiguous affectations.
>
>Round Two of this will involve suggestions for how to satisfy the final
>state of this analysis.
>
>--p
>
> Making Sound Just Work
> ------------------------
>
>One of the "second tier" of requirements mentioned several times at
>the OSDL Portland Linux Desktop Architects workshop was "making audio
>on Linux just work". Many people find it easy to leave this
>requirement lying around in various lists of goals and requirements,
>but before we can make any progress on defining a plan to implement
>the goal, we first need to define it rather more precisely.
>
>This list is intended to avoid any implementation details, and is
>focused entirely on a task oriented analysis of the issues. Your input
>is sought to complete, improve and clarify this analysis.
>
>DEFINING THE GOAL
>=================
>
>The list below is a set of tasks that a user could reasonably expect
>to perform on a computer running Linux that has access to zero, one
>or more audio interfaces, as well as zero one or more network
>interfaces.
>
>The desired task should either work, or produce a sensible and
>comprehensible error message explaining why it failed. For example,
>attempting to control input gain on a device that has no hardware
>mixer should explain that the device has no controls for input gain.
>
> CONFIGURATION (see also MIXING below)
>
> - identify what audio h/w exists on the system
> - identify what network audio destinations are available
> - choose some given audio h/w or network endpoint
> as the default for input
> - ditto for output
> - enable/disable given audio h/w
> - easily (auto)load any kernel modules required for
> given functionality
>
> PLAYBACK
>
> - play a compressed audio file
> * user driven (e.g. play(1))
> * app driven (e.g. {kde,gnome_play}_audiofile())
> - play a PCM encoded audio file (specifics as above)
> - hear system sounds
> - VOIP
> - game audio
> - music composition
> - music editing
> - video post production
>
> RECORDING
>
> - record from hardware inputs
> * use default audio interface
> * use other audio interface
> * specify which h/w input to use
> * control input gain
> - record from other application(s)
> - record from live (network-delivered) audio
> streams
> * PCM/lossless compression (WAV, FLAC etc)
> * lossy compression (mp3, ogg etc)
>
>
> MIXING
>
> - control h/w mixer device (if any)
>
> * allow use of a generic app for this
> * NOTE to non-audio-focused readers: the h/w mixer
> is part of the audio interface that is used
> to control signal levels, input selection
> for recording, and other h/w specific features.
> Some pro-audio interfaces do not have a h/w mixer,
> most consumer ones do. It has almost nothing
> to do with "hardware mixing" which describes
> the ability of the h/w to mix together multiple
> software-delivered audio data streams.
>
> - multiple applications using soundcard simultaneously
> - control application volumes independently
> - provide necessary apps for controlling specialized
> hardware (e.g. RME HDSP, ice1712, ice1724, liveFX)
>
> ROUTING
>
> - route audio to specific h/w among several installed devices
> - route audio between applications
> - route audio across network
> - route audio without using h/w (regardless to whether or
> not h/w is available; e.g. streaming media)
>
> MULTIUSER
>
> - which of the above should work in a multi-user scenario?
>
> FORMATS
>
> - basically, the task list if covered by the above list,
> but there are some added criteria:
>
> - audio data formats divide into:
> - direct sample data (e.g. RIFF/WAV, AIFF)
> - losslessly compressed (e.g. FLAC)
> - lossy compression (e.g. Vorbis, MP3)
> - apps that can handle a given division should all
> handle the same set of formats, with equal prowess.
> i.e. apps don't have to handle lossy compression
> formats, but if they do, they should all handle
> the same set of lossy compression formats. Principle:
> minimize user suprise.
> - user should see no or limited obstacles to handling
> proprietary formats
>
> MISC
>
> - use multiple soundcards as a single logical device
> - use multiple sub-devices as a single logical device
> (sub-devices are independent chipsets on
> a single audio interface; many soundcards
> have analog i/o and digital i/o available
> as two different sub-devices)
>
>
>
More information about the Desktop_architects
mailing list