Re: [linux-audio-user] Making Audio on Linux Just Work: (1) defining the goals

From: Mark Knecht <markknecht@email-addr-hidden>
Date: Sat Dec 17 2005 - 22:36:11 EET

On 12/17/05, Lee Revell <rlrevell@email-addr-hidden-job.com> wrote:
> On Mon, 2005-12-12 at 11:47 -0500, 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.
> >
>
> If we can agree on the goals below the next step is to determine which
> of these don't already Just Work and of the remaining items, which will
> need to be solved at the application level (IOW specified in that
> desktop environment's requirements for a correct audio app) and which
> can be solved at lower level. For example, in order to control
> application volumes independently, in the event that the hardware does
> not support it do we require each app to implement a software volume
> control? Or can it be solved at the ALSA level without requiring an
> intermediate buffer or extra copy?
>
> Also we need to select a baseline system to determine how many of these
> items Just Work already. Personally I would recommend a recent Ubuntu
> distro with the latest Gnome release.
>
> Another question, where do we draw the line between things that should
> Just Work and which should be possible but require configuration by the
> user. For example "use multiple soundcards as a single logical device"
> is tricky - do you think it's realistic to expect an idiot proof
> interface for this?
>
> I'd also like to see the OSS API go away as it makes meeting the goals
> below much easier.
>
> > 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
> >

I don't know if it's implied somewhere in the comments above but I
think that, as a user coming from the Windows and recently Mac world
that making sure pretty much everything out there that gets linked on
a web page should be able to play from in the browser you are using.
There are some strange aspects about mplayer and web browsers, at
least on my systems, which can end up with multiple mp3's playing at
the same time. Stuff like starting an mp3/ogg/xxx file playing, and
then hitting the back button, should stop the audio, or if it doesn't,
hitting another audio link should stop the previous one from playing.

Anyway, that's my 2 cents. It's great that you guys are talking about
making this better.

Also, the OSS api could possibly go away but there are still huge
numbers of apps that depend on it. Lots of old Linux games, etc.,
shouldn't suddently fail. As long as alsa-oss handles that it should
be cool.

Thanks,
Mark
Received on Sun Dec 18 00:15:06 2005

This archive was generated by hypermail 2.1.8 : Sun Dec 18 2005 - 00:15:06 EET