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:[EMAIL PROTECTED]
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
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
