Re: [Jack-Devel] How to get mplayer and firefox/flash to play

On Tue, Dec 20, 2011 at 08:55:13PM -0500, Paul Davis wrote:
> On Tue, Dec 20, 2011 at 6:57 PM, Fons Adriaensen <[hidden]> wrote:
> 
> > If you just add the outputs from all client without any scaling
> > then there is no 'policy' involved,
> 
> what format are the samples in? do you do SRC? how about dithering?
> what latency exists for clients that asked for specific values (or
> didn't)? how are xruns handled? do i need to go on?
> 
> > client gets does not depend on the presence of any other as long
> > as the sum doesn't exceed the physical limits. If it does, that
> > is the user's problem. Just as it is when e.g. windows from two
> > or more apps overlap on the screen.
> 
> you might have noticed that X Window does not run in the kernel, for
> precisely the same reason that ALSA does not do in-kernel mixing.

Please rewind a few posts and read again. I never said it should be
done in kernel space. 

And what I have in mind is very close to what ALSA actually does,
it just gets presented in a different way.

Currently an app that wants a particalar sample rate, format,
whatever is supposed to either

1. configure the HW card, assuming it supports what the client
   wants, or

2. use one of those predefined 'plugins'.

The problems with the 'plugs' (2) are that

3. ALSA doesn't present them in the same way as HW devices
   (it tries to some extent) and consequenctly any app that
   just scans for HW cards, (typically the closed source
   things like Skype etc.) won't ever use them. 

4. They don't work as expected (try running Jack on plughw:x,y),
   and making them work as expected - that is provide all the
   access methods, options, etc. that ALSA offers on real HW
   devices also on an arbitrary stack of plugins - would
   complicate things no end and probably lead to absurd
   situations (such as conversions that cancel out).

As an example of (3), I'm currently trying to use the Harpex-b
app <harpex.net>. It's based on the Juce framework. It correctly
detects ALSA HW devices and presents them on a menu. Fine. Only
problem is that the Juce code chokes on 64-ch cards such as the
MADI ones. OK, just define a 'route' ALSA device (IIRC) with
less channels (it needs 8) or us the ALSA->Jack plugin. But that
doesn't work because ALSA doesn't present them as real devices.
By not doing that it misses the whole point of having such plugs
in the first place.

(1) can't be done if the sound card is supposed to be shared
between different apps. Selecting the sample rate, format etc.
should done by the a configuration utility. After that apps are
supposed to use the sound card as it is. 

What I propose is that the userspace part of ALSA 

5. Separates HW configuration from actually using a soundcard.
In other words the API to be used by a normal client informs
the client of the current sample rate, format, buffers size
and whatever, but does not require or even allow the client
to set any of those. Same for the access model: only mmap,
and clients are supposed to run their audio code in RT. All
this is very similar to the restrictions that Jack imposes.

6. Provides multi-client access - split inputs, sum outputs -
with eventually the option of exclusive access.

Clients that can't live with the restrictions of (5) link
with a library (part of the ALSA system) that provides sample
rate conversion, buffering, alternative access methods, and
whatever you can imagine in an easy way. This library replaces
all of dmix, dsnoop, route, etc. The essential difference is
that the client configures this as required instead of having
to use some predefined 'plugs' that it can't discover in the
first place.

All this would actually be simpler than what we have now.

Ciao,

-- 
FA

Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

1324468792.30591_0.ltw:2,a <20111221115942.GA26504 at linuxaudio dot org>