On 4/5/06, Reuben Martin <reuben.m@xxxxxxxxx> wrote: > It was posted to the OSDL Desktop architects mailing list. (Same list > that Linux made a statement about not liking Gnome that set off a big > hoopla) That should be Linus, not Linux. :P >See here: > http://lists.osdl.org/pipermail/desktop_architects/2005-December/000470.html > > -Reuben > > On 4/5/06, M P Smoak <smoak@xxxxxxx> wrote: > > > > Paul, did this effort result in the list of tasks that you were seeking? > > Maybe I missed it, but I've not seen any feedback on the result and > > where it went. I hope it went somewhere and is being worked on. Thanks > > you very much for your contributions. > > > > Marv > > > > On Monday 12 December 2005 11:47, Paul Davis wrote: > > > ( LAU folk: this is an initial outline of an email I want to dispatch > > > to the desktop-architects list in the very near future. Your comments > > > are eagerly sought. Note that this section specifically seeks to > > > avoid any discussion of implementations or specific approachs. I > > > would like to fully flesh out the list of tasks ASAP ) > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > 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) compressed audio > > > streams > > > > > > > > > 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 > > > > > > MULTIUSER > > > > > > - which of the above should work in a multi-user scenario? > > > > > > MISC > > > > > > - use multiple soundcards as a single logical device > > > > >
