Re: dmix plugin

[Abramo Bagnara <abramo.bagnara@libero.it>]

Jaroslav Kysela wrote:
> 
> On Thu, 13 Feb 2003, Abramo Bagnara wrote:
> 
> > Jaroslav Kysela wrote:
> > >
> > > Hi all,
> > >
> > >         a next step to get the lowlatency sharing of exclusive PCM devices
> > > is in ALSA CVS - the dmix (direct mixing) plugin..
> > >         How it works? Basically, the playback in driver runs forewer
> > > without any xrun detection. The ring buffer (only just played areas) is
> > > also silenced in each interrupt. Then we have multiple clients and a
> > > process (server) which passes the file descriptor of playback devices to
> > > them. The server also takes care about freeing of used shm memory and
> > > semaphore.
> > >         The big step forward is that we share one mmaped ring buffer
> > > accross many processes and each process can add samples into it without
> > > any process<->kernel swaps. Also, each processes are independant, thus
> > > failing of one doesn't break others. It's not multithreaded, we don't need
> > > this mechanism.
> >
> > Good work, Jaroslav!
> >
> > I'd like to understand how you've thought to solve:
> > a) contemporary access to same sample
> > b) sum overflow (now I'm unable to remember the technical term)
> >
> > For a) I can imagine some effective tricks (xadd or
> > store/sum/check/retry or period size mutex), but I really don't see what
> > you'll invent for b) ;-)
> 
> a) yes, we need look for the most effective locking scheme for sample
>    updates; at first glance, the instruction which does add+saturation
>    doesn't exist for i386 (MMX offers saturation, but it operates only
>    with mmx registers)

	old = *dst;
again:
	new = old + *src;
	if (new > 0x7fff)
		new = 0x7fff;
	else if (new < -0x8000)
		new = -0x8000;
	old1 = cmpxchg(dst, old, new);
	if (unlikely(old != old1)) {
		old = old1;
		goto again;
	}

might be a good approach on most architectures

> b) sum overflow: we can lower volume of samples before sum; I think that
>    hardware works in this way, too

Here I don't understand you. Suppose we have 3 samples to mix:
a = 0x7500
b = 0x7400
c = 0x8300

If you do a + b + c (in this order) you obtain:
d=0
d += a -> 7500
d += b -> 0xe900 -> 0x7fff
d += c -> 0x02ff

while the correct result is 0x6c00. You see?

> I don't hear any audiable problems on my UP machine with current scheme
> which doesn't take care about a) nor b). I tried six simultaneous streams.

It's hard to detect sound quality mixing six random sound sources ;-)

> > One thing I'm definitely sure is that this is the *perfect* approach for
> > pcm_share (at least now I don't see any drawbacks).
> 
> Yes, my next goal is to move common code for such plugins to separate file
> and create share and capture-tee (any idea for better name?) plugins.

pcm_snoop of course ;-)

Take in account in the design to use it for both capture and playback
(i.e. pcm_snoop is always capture of course, but the snooped pcm
direction may be both).

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf