Re: dmix plugin

Re: dmix plugin

[Jaroslaw Sobierski]

> > 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?

AFAIK most hardware does not mix by reducing volume before the sum. On the
contrary, it is usually summed "as is" to a wider register, and often even so
used. For example, a sound card able to mix 16 chanels of 16 bits would have
a 16+4 bits or 24 bit register were the channels are added and no saturation
can occur. In good hardware this would not even be downscaled back to 16 bits,
but a 24 bit D/A converter would be used instead. In older times (Gravis Ultra
Sound and I think older SB AWE) this could easily be spotted by the difference
in supported "hardware" channels and "software" channels. A card with a 32 bit
sum register and 24 bit DA could support (as above) 16 hardware channels and 
for example 64 software channels (mixed together in quadrouplets to the 16 hw).

In our case, such "solution" would have to affect the whole buffer, meaning 
we would need 3 (or better yet 4) bytes per sample, which would eventually get
reduced back to 2 bytes on the way out to the sound card. This seems neither
elegant nor memory efficient but would work, and also solves the "a)" problem
because we don't need to saturate so an atomic add can be performed on each
sample. 

--------------
Fycio (J.Sobierski)
 fycio@gucio.com


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

Re: Re: dmix plugin

[Jaroslav Kysela]

On Mon, 17 Feb 2003, Jaroslaw Sobierski wrote:

> > > 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?
> 
> AFAIK most hardware does not mix by reducing volume before the sum. On the
> contrary, it is usually summed "as is" to a wider register, and often even so
> used. For example, a sound card able to mix 16 chanels of 16 bits would have
> a 16+4 bits or 24 bit register were the channels are added and no saturation
> can occur. In good hardware this would not even be downscaled back to 16 bits,
> but a 24 bit D/A converter would be used instead. In older times (Gravis Ultra
> Sound and I think older SB AWE) this could easily be spotted by the difference
> in supported "hardware" channels and "software" channels. A card with a 32 bit
> sum register and 24 bit DA could support (as above) 16 hardware channels and 
> for example 64 software channels (mixed together in quadrouplets to the 16 hw).
> 
> In our case, such "solution" would have to affect the whole buffer, meaning 
> we would need 3 (or better yet 4) bytes per sample, which would eventually get
> reduced back to 2 bytes on the way out to the sound card. This seems neither
> elegant nor memory efficient but would work, and also solves the "a)" problem
> because we don't need to saturate so an atomic add can be performed on each
> sample. 

Yes, this solution is good. I've though about it, too. Unfortunately, it 
adds additional transfers including saturation from the "sum" ring buffer 
to the DMA buffer of hardware.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



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

Re: Re: dmix plugin

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> On Mon, 17 Feb 2003, Jaroslaw Sobierski wrote:
> 
> > > > 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?
> >
> > AFAIK most hardware does not mix by reducing volume before the sum. On the
> > contrary, it is usually summed "as is" to a wider register, and often even so
> > used. For example, a sound card able to mix 16 chanels of 16 bits would have
> > a 16+4 bits or 24 bit register were the channels are added and no saturation
> > can occur. In good hardware this would not even be downscaled back to 16 bits,
> > but a 24 bit D/A converter would be used instead. In older times (Gravis Ultra
> > Sound and I think older SB AWE) this could easily be spotted by the difference
> > in supported "hardware" channels and "software" channels. A card with a 32 bit
> > sum register and 24 bit DA could support (as above) 16 hardware channels and
> > for example 64 software channels (mixed together in quadrouplets to the 16 hw).
> >
> > In our case, such "solution" would have to affect the whole buffer, meaning
> > we would need 3 (or better yet 4) bytes per sample, which would eventually get
> > reduced back to 2 bytes on the way out to the sound card. This seems neither
> > elegant nor memory efficient but would work, and also solves the "a)" problem
> > because we don't need to saturate so an atomic add can be performed on each
> > sample.
> 
> Yes, this solution is good. I've though about it, too. Unfortunately, it
> adds additional transfers including saturation from the "sum" ring buffer
> to the DMA buffer of hardware.

I remember you that the main point of dmix existence is the "direct"
part.

If we'd need to use an intermediate buffer and a mixing thread, the dmix
approach lose our interest.

A solution might be to have a shared parallel sw ring buffer where to
store the exact value:

        xadd(sw, *src);
	do {
		v = *sw;
		if (v > 0x7fff)
			s = 0x7fff;
		else if (v < -0x8000)
			s = -0x8000;
		else
	     		s = v;
		*hw = v;
	} while (unlikely(v != *sw));
	
This should solve also the atomicity update.

Comments?

-- 
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

Re: Re: dmix plugin

[Jaroslav Kysela]

On Mon, 17 Feb 2003, Abramo Bagnara wrote:

> Jaroslav Kysela wrote:
> > 
> > On Mon, 17 Feb 2003, Jaroslaw Sobierski wrote:
> > 
> > > > > 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?
> > >
> > > AFAIK most hardware does not mix by reducing volume before the sum. On the
> > > contrary, it is usually summed "as is" to a wider register, and often even so
> > > used. For example, a sound card able to mix 16 chanels of 16 bits would have
> > > a 16+4 bits or 24 bit register were the channels are added and no saturation
> > > can occur. In good hardware this would not even be downscaled back to 16 bits,
> > > but a 24 bit D/A converter would be used instead. In older times (Gravis Ultra
> > > Sound and I think older SB AWE) this could easily be spotted by the difference
> > > in supported "hardware" channels and "software" channels. A card with a 32 bit
> > > sum register and 24 bit DA could support (as above) 16 hardware channels and
> > > for example 64 software channels (mixed together in quadrouplets to the 16 hw).
> > >
> > > In our case, such "solution" would have to affect the whole buffer, meaning
> > > we would need 3 (or better yet 4) bytes per sample, which would eventually get
> > > reduced back to 2 bytes on the way out to the sound card. This seems neither
> > > elegant nor memory efficient but would work, and also solves the "a)" problem
> > > because we don't need to saturate so an atomic add can be performed on each
> > > sample.
> > 
> > Yes, this solution is good. I've though about it, too. Unfortunately, it
> > adds additional transfers including saturation from the "sum" ring buffer
> > to the DMA buffer of hardware.
> 
> I remember you that the main point of dmix existence is the "direct"
> part.
> 
> If we'd need to use an intermediate buffer and a mixing thread, the dmix
> approach lose our interest.
> 
> A solution might be to have a shared parallel sw ring buffer where to
> store the exact value:
> 
>         xadd(sw, *src);
> 	do {
> 		v = *sw;
> 		if (v > 0x7fff)
> 			s = 0x7fff;
> 		else if (v < -0x8000)
> 			s = -0x8000;
> 		else
> 	     		s = v;
> 		*hw = v;
> 	} while (unlikely(v != *sw));
> 	
> This should solve also the atomicity update.
> 
> Comments?

We probably talk about same thing, but in different words. I also don't 
think that atomicity is an problem when xadd() is atomic (and it is atomic 
for i386).

Then you need to do the saturation and store to the hardware ring buffer, 
but if this operation is after xadd() then we don't care about atomicity, 
because we are 100% sure that we have a valid result.

Algorithm:

	while (count) {
		atomic_xadd(sum_ring_buffer[idx], local_buffer[idx]);
		hw_ring_buffer[idx] = saturate(sum_ring_buffer[idx]);
	}


						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



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

Re: Re: dmix plugin

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> On Mon, 17 Feb 2003, Abramo Bagnara wrote:
> 
> > Jaroslav Kysela wrote:
> > >
> > > On Mon, 17 Feb 2003, Jaroslaw Sobierski wrote:
> > >
> > > > > > 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?
> > > >
> > > > AFAIK most hardware does not mix by reducing volume before the sum. On the
> > > > contrary, it is usually summed "as is" to a wider register, and often even so
> > > > used. For example, a sound card able to mix 16 chanels of 16 bits would have
> > > > a 16+4 bits or 24 bit register were the channels are added and no saturation
> > > > can occur. In good hardware this would not even be downscaled back to 16 bits,
> > > > but a 24 bit D/A converter would be used instead. In older times (Gravis Ultra
> > > > Sound and I think older SB AWE) this could easily be spotted by the difference
> > > > in supported "hardware" channels and "software" channels. A card with a 32 bit
> > > > sum register and 24 bit DA could support (as above) 16 hardware channels and
> > > > for example 64 software channels (mixed together in quadrouplets to the 16 hw).
> > > >
> > > > In our case, such "solution" would have to affect the whole buffer, meaning
> > > > we would need 3 (or better yet 4) bytes per sample, which would eventually get
> > > > reduced back to 2 bytes on the way out to the sound card. This seems neither
> > > > elegant nor memory efficient but would work, and also solves the "a)" problem
> > > > because we don't need to saturate so an atomic add can be performed on each
> > > > sample.
> > >
> > > Yes, this solution is good. I've though about it, too. Unfortunately, it
> > > adds additional transfers including saturation from the "sum" ring buffer
> > > to the DMA buffer of hardware.
> >
> > I remember you that the main point of dmix existence is the "direct"
> > part.
> >
> > If we'd need to use an intermediate buffer and a mixing thread, the dmix
> > approach lose our interest.
> >
> > A solution might be to have a shared parallel sw ring buffer where to
> > store the exact value:
> >
> >         xadd(sw, *src);
> >       do {
> >               v = *sw;
> >               if (v > 0x7fff)
> >                       s = 0x7fff;
> >               else if (v < -0x8000)
> >                       s = -0x8000;
> >               else
> >                       s = v;
> >               *hw = v;
> >       } while (unlikely(v != *sw));
> >
> > This should solve also the atomicity update.
> >
> > Comments?
> 
> We probably talk about same thing, but in different words. I also don't
> think that atomicity is an problem when xadd() is atomic (and it is atomic
> for i386).
> 
> Then you need to do the saturation and store to the hardware ring buffer,
> but if this operation is after xadd() then we don't care about atomicity,
> because we are 100% sure that we have a valid result.
> 
> Algorithm:
> 
>         while (count) {
>                 atomic_xadd(sum_ring_buffer[idx], local_buffer[idx]);
>                 hw_ring_buffer[idx] = saturate(sum_ring_buffer[idx]);
>         }

You're wrong: xadd is atomic but xadd/read/saturation/write is not.

Without the loop I've added you risk to write on hw_ring_buffer an *old*
value:

A:		B:
xadd
read
		xadd
		read
		saturate
		write
saturate
write

-- 
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

Re: Re: dmix plugin

[Jaroslav Kysela]

On Mon, 17 Feb 2003, Abramo Bagnara wrote:

> You're wrong: xadd is atomic but xadd/read/saturation/write is not.
> 
> Without the loop I've added you risk to write on hw_ring_buffer an *old*
> value:
> 
> A:		B:
> xadd
> read
> 		xadd
> 		read
> 		saturate
> 		write
> saturate
> write

I see, the read/saturate/write must be atomic, too. In this case, it would
be better to use a global (or a set of) mutex(es) to lock the hardware
ring buffer. The futexes are nice.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



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

Re: Re: dmix plugin

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> On Mon, 17 Feb 2003, Abramo Bagnara wrote:
> 
> > You're wrong: xadd is atomic but xadd/read/saturation/write is not.
> >
> > Without the loop I've added you risk to write on hw_ring_buffer an *old*
> > value:
> >
> > A:            B:
> > xadd
> > read
> >               xadd
> >               read
> >               saturate
> >               write
> > saturate
> > write
> 
> I see, the read/saturate/write must be atomic, too. In this case, it would
> be better to use a global (or a set of) mutex(es) to lock the hardware
> ring buffer. The futexes are nice.

They are nice indeed, but definitely not the right solution here.

Although I don't know if it's the absolute best solution, the 'retry'
approach I've proposed is far better and much more efficient.

-- 
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

Re: Re: dmix plugin

[tomasz motylewski]

On Mon, 17 Feb 2003, Jaroslaw Sobierski wrote:

> > 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?

Well, but when adding a+b we have no idea that that overlow will be compensated
by next very big negative sample. Also mixing signals which already fill 90% of
dynamic range is not a good idea. My "fix" is heuristic - it works for
occasional _small_ overflows like 0x4100+0x4000 -> 0x7fff is much better than
0x8100. 

The idea of dmix as I understand it is that buffer is already in the native
format for the sound card. So if sound card supports 24 bit, OK. But then
people will start mixing 24 bit samples :-)

> AFAIK most hardware does not mix by reducing volume before the sum. On the
> contrary, it is usually summed "as is" to a wider register, and often even so

And here our "wider register" is 16bit. That means end users should not expect
too much if thay mix full power signals on it.

BTW. If you have uncorrelated signals, then to mix 4 signals it may be good
enough to reduce the amplitude of them just factor 2, because power will drop
factor 4. Ocassionally there will be overrruns, but 0x7fff limit will make it
almost not hearable. Not a correct fix, but I can assure you that it works in
standard cases :-)

Best regards,
--
Tomasz Motylewski
BFAD GmbH & Co. KG



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

RE: dmix plugin

[Marc Titinger]

> well, route (or plug) has the capability for software mix (in a
> certain meaning), but not for separate pcm streams.  you can downmix
> the multi-channels in a stream via route plugin if the channels is
> given.
> 
> but it's defenitely different from what dmix plugin does, and perhaps
> it's different from what Marc wants, too...

You got my point : route may looks like soft mix, but actually is downmix with the possibility of setting gains. I guess gains are what makes sense using the asoundrc configuration instead of leaving the downmix to the plughw (I assume plughw would downmix a stereo stream to a mono hw pcm, even if nothing is asoundrc-configured).
 
 
> > Some cards with multiple open hardware acceleration doesn't 
> need this 
> > default. Also, the dmix plugin has some limited things so I 
> don't prefer 
> > to select it as default.
> 
> agreed here, although i feel it's also nice to set it as default for a
> consumer card which has no hardware mix function.
> 
> please note that you can re-define the default in asoundrc.
> if you want to set up dmix as the system default, you can define it in
> /etc/asound.conf, too.
>
 
This makes me enthousiastic about those configuration files : it's a pity that no GUI is yet available to help design complex files ; consider the fact that some hardware manufacturers spend time on developping pricy console enabled hardware, console interfaces and SDK.
A good GUI for asoundrc wouldn't be far from a console interface, especially if some settings can be automated via the sequencer : imagine a gain (or any parameter) could be dependent of a MIDI code !






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

RE: dmix plugin

[Marc Titinger]

This looks Great !

I haven't yet experimented a lot with .asoundrc files, so please excuse me if the following questions are irrelevant or OTO, but:

I was wondering if one could define a plug pcm, that offers two stereo pairs routed with policy "average" to a single-stereo "hw" slave.

My understanding is that until this dmix pcm, there was no "official" means supported by alsalib to achieve software mix of streams comming from differents apps.

Could I have one app open the first pair of my hypothetic plug pcm, and another app open the second pair ?
I guess this would be managed like a concurrent access to a pcm, and block or fail the second open() call. 

Would'nt it be nice to create a dmix pcm "behind"  a such plug pcm, to provide mix in a transparent way ?

thanks for your light over this 
Marc.



> -----Original Message-----
> From: Jaroslav Kysela [mailto:perex@suse.cz]
> Sent: mercredi 12 février 2003 10:46
> To: ALSA development
> Subject: [Alsa-devel] dmix plugin
> 
> 
> 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.
> 
> Here is an .asoundrc example configuration (plugin defaults 
> are 48kHz, 
> stereo, signed 16-bit little endian):
> 
> pcm.dmix {
> 	type dmix
> 	ipc_key 1234	# must be unique for all dmix plugins!!!!
> 	slave {
> 		pcm "hw:0,0"
> 	}
> }
> 
> 	Then try: 'aplay -Dplug:dmix <filename>' on multiple consoles.
> 
> 	Note that it's still alpha code and there are some not correctly
> implemented functions (like drain, rewind and more). Note 
> that you'll need
> also the latest ALSA driver from CVS, because the silence settings was
> enhanced a bit and bug in the timer code will crash your machine.
> 
> 					Enjoy it!
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SuSE Labs
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

RE: dmix plugin

[Jaroslav Kysela]

On Wed, 12 Feb 2003, Marc Titinger wrote:

> This looks Great !
> 
> I haven't yet experimented a lot with .asoundrc files, so please excuse
> me if the following questions are irrelevant or OTO, but:
> 
> I was wondering if one could define a plug pcm, that offers two stereo
> pairs routed with policy "average" to a single-stereo "hw" slave.
> 
> My understanding is that until this dmix pcm, there was no "official"
> means supported by alsalib to achieve software mix of streams comming
> from differents apps.

Yes, that's true.

> Could I have one app open the first pair of my hypothetic plug pcm, and
> another app open the second pair ? I guess this would be managed like a
> concurrent access to a pcm, and block or fail the second open() call.
> 
> Would'nt it be nice to create a dmix pcm "behind"  a such plug pcm, to
> provide mix in a transparent way ?

Some cards with multiple open hardware acceleration doesn't need this 
default. Also, the dmix plugin has some limited things so I don't prefer 
to select it as default.

> 
> thanks for your light over this 
> Marc.

I've just added the definition of dmix plugin to the global alsa
configuration file. Usage (device name only):

plug:dmix
"plug:'dmix:RATE=44100'"
"plug:'dmix:SLAVE=\'hw:0,0,2\',RATE=44100'"

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



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

Re: dmix plugin

[Takashi Iwai]

At Wed, 12 Feb 2003 20:21:31 +0100 (CET),
Jaroslav wrote:
> 
> On Wed, 12 Feb 2003, Marc Titinger wrote:
> 
> > This looks Great !
> > 
> > I haven't yet experimented a lot with .asoundrc files, so please excuse
> > me if the following questions are irrelevant or OTO, but:
> > 
> > I was wondering if one could define a plug pcm, that offers two stereo
> > pairs routed with policy "average" to a single-stereo "hw" slave.
> > 
> > My understanding is that until this dmix pcm, there was no "official"
> > means supported by alsalib to achieve software mix of streams comming
> > from differents apps.
> 
> Yes, that's true.

well, route (or plug) has the capability for software mix (in a
certain meaning), but not for separate pcm streams.  you can downmix
the multi-channels in a stream via route plugin if the channels is
given.

but it's defenitely different from what dmix plugin does, and perhaps
it's different from what Marc wants, too...


> > Could I have one app open the first pair of my hypothetic plug pcm, and
> > another app open the second pair ? I guess this would be managed like a
> > concurrent access to a pcm, and block or fail the second open() call.
> > 
> > Would'nt it be nice to create a dmix pcm "behind"  a such plug pcm, to
> > provide mix in a transparent way ?
> 
> Some cards with multiple open hardware acceleration doesn't need this 
> default. Also, the dmix plugin has some limited things so I don't prefer 
> to select it as default.

agreed here, although i feel it's also nice to set it as default for a
consumer card which has no hardware mix function.

please note that you can re-define the default in asoundrc.
if you want to set up dmix as the system default, you can define it in
/etc/asound.conf, too.


Takashi


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

Re: dmix plugin

[Jaroslav Kysela]

On Thu, 13 Feb 2003, Takashi Iwai wrote:

> agreed here, although i feel it's also nice to set it as default for a
> consumer card which has no hardware mix function.

We can add the special configuration to card-specific configuration files
(like for surround*, spdif etc.), but I was too lazy to do it ;-)

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: dmix plugin

[Jaroslav Kysela]

On Wed, 12 Feb 2003, Paul Davis wrote:

> >	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.
> 
> this all sounds fabulous, but could you explain a little about what is
> actually going on here? i'd like to understand the
> architecture/mechanism a little more deeply in ways that reading the
> source probably won't provide. 

I'll talk about the dmix plugin on LAD meeting in Karlsruhe, but the main
part (as for aserver) is the unix ability to send an active file
descriptor over unix socket (see send_fd() function in pcm_dmix.c and
snd_receive_fd() function in pcm_shm.c). Then we can mmap control
(appl_ptr), status (hw_ptr) and the DMA ring buffer from the driver's PCM
stream more times - ALSA driver supports it - for each client process
separately.

Once we have the hardware pointer which is updated from the interrupt
handler and the ring buffer common for each processes, it's sufficient to
add samples to the ring buffer at right time. Also, the interrupt handler
in the driver takes care about silencing of just played area before
hardware pointer is updated, thus we are sure, that samples won't be
played/accumulated more times.

Also, I use as the poll source the slave timer for the playback PCM 
stream. Slave timers can have multiple instances.
 
> this will be a godsend for consumer audio apps, thats for sure!

We can create more plugins in this way (a new version of share plugin to
share channels among processes, a tee plugin for capture etc..).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

dmix plugin

[Jaroslav Kysela]

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.

Here is an .asoundrc example configuration (plugin defaults are 48kHz, 
stereo, signed 16-bit little endian):

pcm.dmix {
	type dmix
	ipc_key 1234	# must be unique for all dmix plugins!!!!
	slave {
		pcm "hw:0,0"
	}
}

	Then try: 'aplay -Dplug:dmix <filename>' on multiple consoles.

	Note that it's still alpha code and there are some not correctly
implemented functions (like drain, rewind and more). Note that you'll need
also the latest ALSA driver from CVS, because the silence settings was
enhanced a bit and bug in the timer code will crash your machine.

					Enjoy it!
						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: dmix plugin

[Takashi Iwai]

At Wed, 12 Feb 2003 10:45:41 +0100 (CET),
Jaroslav wrote:
> 
> Here is an .asoundrc example configuration (plugin defaults are 48kHz, 
> stereo, signed 16-bit little endian):
> 
> pcm.dmix {
> 	type dmix
> 	ipc_key 1234	# must be unique for all dmix plugins!!!!
> 	slave {
> 		pcm "hw:0,0"
> 	}
> }
> 
> 	Then try: 'aplay -Dplug:dmix <filename>' on multiple consoles.

confirmed to work fine on my machine.  great!

one thing noticed is that even the different sample rate is accepted
without plug and ersults in too fast/slow playback.  just a minor
problem, though.


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: dmix plugin

[Jaroslav Kysela]

On Wed, 12 Feb 2003, Takashi Iwai wrote:

> At Wed, 12 Feb 2003 10:45:41 +0100 (CET),
> Jaroslav wrote:
> > 
> > Here is an .asoundrc example configuration (plugin defaults are 48kHz, 
> > stereo, signed 16-bit little endian):
> > 
> > pcm.dmix {
> > 	type dmix
> > 	ipc_key 1234	# must be unique for all dmix plugins!!!!
> > 	slave {
> > 		pcm "hw:0,0"
> > 	}
> > }
> > 
> > 	Then try: 'aplay -Dplug:dmix <filename>' on multiple consoles.
> 
> confirmed to work fine on my machine.  great!
> 
> one thing noticed is that even the different sample rate is accepted
> without plug and ersults in too fast/slow playback.  just a minor
> problem, though.

Note that aplay uses snd_pcm_hw_params_set_rate_near() function, so it's
not guaranteed that rate is same as requested. I've added a check to aplay
- if rate doesn't fall into 5% limit, then warning is reported now.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: dmix plugin

[Paul Davis]

>	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.

this all sounds fabulous, but could you explain a little about what is
actually going on here? i'd like to understand the
architecture/mechanism a little more deeply in ways that reading the
source probably won't provide. 

this will be a godsend for consumer audio apps, thats for sure!

--p


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: dmix plugin

[Abramo Bagnara]

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) ;-)

Without this correctness concerns this approach is very much efficient
(compared to server based one), I wonder only if this will be true also
when correctness will be taken in account. BTW someone knows how much is
relevant the audible impact of this lack of correctness?

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).

-- 
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

Re: dmix plugin

[Jaroslav Kysela]

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)
b) sum overflow: we can lower volume of samples before sum; I think that
   hardware works in this way, too

> Without this correctness concerns this approach is very much efficient
> (compared to server based one), I wonder only if this will be true also
> when correctness will be taken in account. BTW someone knows how much is
> relevant the audible impact of this lack of correctness?

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.

> 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.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



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

Re: dmix plugin

[Abramo Bagnara]

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