Re: Making Audio on Linux Just Work: (1) defining the goals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux