Re: dsnoop, dshare and dmix plugins

Re: dsnoop, dshare and dmix plugins

[Florian Bomers]

just to clarify: all 3 plugins will not enable several processes to use the same
soundcard's channels, i.e. software mixing?

Thanks,
Florian


> Hi all,
> 
>         the dmix plugin was extended to support channel bindings and
> mixing code for 32-bit samples (24-bit resolution).
>         I'd like to introduce new two plugins (seems also "most wanted" by
> ALSA users): dsnoop and dshare. The dsnoop plugin allows spliting of one
> stream to more applications. And finally the dshare plugin does sharing of
> channels (thus you may use your multi-channel device for separated
> independent tasks). The ALSA configuration syntax for both of new plugins
> is same as for the dmix plugin. Please note that dshare plugin must have
> the bindings section with unique destination channels otherwise it won't
> work.
> 
>                                                 Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SuSE Labs

-- 
Florian Bomers
Java Sound
Java Software/Sun Microsystems, Inc.
http://java.sun.com/products/java-media/sound/


-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Ville Syrjälä]

On Thu, Mar 20, 2003 at 02:13:18PM -0800, Florian Bomers wrote:
> just to clarify: all 3 plugins will not enable several processes to use the same
> soundcard's channels, i.e. software mixing?

dmix does just that. Works fine here, ipc_key stuff and all :)

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Ville Syrjälä]

On Thu, Mar 20, 2003 at 02:13:18PM -0800, Florian Bomers wrote:
> just to clarify: all 3 plugins will not enable several processes to use the same
> soundcard's channels, i.e. software mixing?

dmix does just that. Works fine here. ipc_key stuff and all :)

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

dsnoop, dshare and dmix plugins

[Jaroslav Kysela]

Hi all,

	the dmix plugin was extended to support channel bindings and 
mixing code for 32-bit samples (24-bit resolution).
	I'd like to introduce new two plugins (seems also "most wanted" by
ALSA users): dsnoop and dshare. The dsnoop plugin allows spliting of one
stream to more applications. And finally the dshare plugin does sharing of
channels (thus you may use your multi-channel device for separated
independent tasks). The ALSA configuration syntax for both of new plugins
is same as for the dmix plugin. Please note that dshare plugin must have
the bindings section with unique destination channels otherwise it won't
work.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Takashi Iwai]

At Wed, 19 Mar 2003 17:49:51 +0100 (CET),
Jaroslav wrote:
> 
> Hi all,
> 
> 	the dmix plugin was extended to support channel bindings and 
> mixing code for 32-bit samples (24-bit resolution).
> 	I'd like to introduce new two plugins (seems also "most wanted" by
> ALSA users): dsnoop and dshare. The dsnoop plugin allows spliting of one
> stream to more applications. And finally the dshare plugin does sharing of
> channels (thus you may use your multi-channel device for separated
> independent tasks). The ALSA configuration syntax for both of new plugins
> is same as for the dmix plugin. Please note that dshare plugin must have
> the bindings section with unique destination channels otherwise it won't
> work.

great!
it seems that the last meeting stimulated you so effectively :)


could you post a couple of example configurations and usages?
it would help many users to give a try, i believe.


ciao,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Jaroslav Kysela]

On Wed, 19 Mar 2003, Takashi Iwai wrote:

> At Wed, 19 Mar 2003 17:49:51 +0100 (CET),
> Jaroslav wrote:
> > 
> > Hi all,
> > 
> > 	the dmix plugin was extended to support channel bindings and 
> > mixing code for 32-bit samples (24-bit resolution).
> > 	I'd like to introduce new two plugins (seems also "most wanted" by
> > ALSA users): dsnoop and dshare. The dsnoop plugin allows spliting of one
> > stream to more applications. And finally the dshare plugin does sharing of
> > channels (thus you may use your multi-channel device for separated
> > independent tasks). The ALSA configuration syntax for both of new plugins
> > is same as for the dmix plugin. Please note that dshare plugin must have
> > the bindings section with unique destination channels otherwise it won't
> > work.
> 
> great!
> it seems that the last meeting stimulated you so effectively :)
> 
> 
> could you post a couple of example configurations and usages?

Sure. First example is for the dmix plugin and ice1712 (10 playback 
channels - last two are S/PDIF, so this configuration allows sharing of 
the S/PDIF jack):

pcm.dmix_spdif {
        type dmix
        ipc_key 5678293
        ipc_key_add_uid yes
        slave {
                pcm "hw:0,0"
        }
        bindings {
                0 8
                1 9
        }
}

If you want to share first two analog channels with another applications, 
simply use the same ipc_key configuration:

pcm.dmix_analog {
        type dmix
        ipc_key 5678293
        ipc_key_add_uid yes
        slave {
                pcm "hw:0,0"
        }
        bindings {
                0 0
                1 1
        }
}

Next example is for the dsnoop plugin (also ice1712, S/PDIF capture):

pcm.dsnoop_spdif {
        type dsnoop
        ipc_key 5978293
        ipc_key_add_uid yes
        slave {
                pcm "hw:0,0"
        }
        bindings {
                0 8
                1 9
        }
}

If you ommit the "bindings" section, you'll get all channels. Also, you 
may define more pcm types with same ipc_key configuration with different 
bindings as well.

And finally the dshare plugin (used standard stereo device and using left 
and right channels separately):

pcm.dshare_left {
        type dshare
        ipc_key 6678293
        ipc_key_add_uid yes
        slave {
                pcm "hw:0,0"
        }
        bindings {
                0 0
        }
}

pcm.dshare_right {
        type dshare
        ipc_key 6678293
        ipc_key_add_uid yes
        slave {
                pcm "hw:0,0"
        }
        bindings {
                0 1
        }
}

Final words: I am very happy that we can do these things completely in the
user space but without client/server mechanisms as we promised at the 
beginning of the development.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Fernando Pablo Lopez-Lezcano]

> Sure. First example is for the dmix plugin and ice1712 (10 playback 
> channels - last two are S/PDIF, so this configuration allows sharing of 
> the S/PDIF jack):
> 
> pcm.dmix_spdif {
>         type dmix
>         ipc_key 5678293

Hmm, sorry for my ignorance, but what does this number mean and where
does it come from? (BTW, thanks for the examples!)

-- Fernando




-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Kristof Pelckmans]

I think the documentation library used to mention the usage of dmix, but since the last update, I can't find it anymore (normally : http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html)

The code mentions :
This plugin provides direct mixing of multiple streams. The resolution
for 32-bit mixing is only 24-bit. The low significant byte is filled with
zeros. The extra 8 bits are used for the saturation.

pcm.name {
type dmix# Direct mix
ipc_key INT# unique IPC key
ipc_key_add_uid BOOL# add current uid to unique IPC key
slave STR
# or
slave {# Slave definition
pcm STR# slave PCM name
# or
pcm { }# slave PCM definition
format STR# format definition
rate INT# rate definition
channels INT
period_time INT# in usec
# or
period_size INT# in bytes
buffer_time INT# in usec
# or
buffer_size INT # in bytes
periods INT# when buffer_size or buffer_time is not specified
}
bindings {# note: this is client independent!!!
N INT# maps slave channel to client channel N
}
}

I wonder how you know that the number you assign is not in use...

IPC stands for Inter-Process communication. I've never used it though...

Look at http://users.actcom.co.il/~choo/lupg/tutorials/multi-process/multi-process.html for more info

Cheers,

Kristof


-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Takashi Iwai]

At Thu, 20 Mar 2003 10:02:06 +0100,
Kristof Pelckmans wrote:
> 
> I wonder how you know that the number you assign is not in use...

well, there is no guarantee for that.

i think it would be more understandable to have the string type ipc
key, such as

pcm.dmix {
	type dmix
	ipc_key_str /usr/alsa/foo
	...
}

which generates an ipc key via ftok().


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Jaroslav Kysela]

On Thu, 20 Mar 2003, Takashi Iwai wrote:

> At Thu, 20 Mar 2003 10:02:06 +0100,
> Kristof Pelckmans wrote:
> > 
> > I wonder how you know that the number you assign is not in use...
> 
> well, there is no guarantee for that.
> 
> i think it would be more understandable to have the string type ipc
> key, such as
> 
> pcm.dmix {
> 	type dmix
> 	ipc_key_str /usr/alsa/foo
> 	...
> }
> 
> which generates an ipc key via ftok().

That's a question. This is a quote from the ftok() man page:

"Of course no guarantee can be given that the resulting key_t is unique."

I think that the best solution is to create a communication file with 
information about used unique IPC key and add a verification that used 
IPC semaphores and IPC areas are ours.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Fernando Pablo Lopez-Lezcano]

> > > I wonder how you know that the number you assign is not in use...
> > 
> > well, there is no guarantee for that.
> > 
> > i think it would be more understandable to have the string type ipc
> > key, such as
> > 
> > pcm.dmix {
> > 	type dmix
> > 	ipc_key_str /usr/alsa/foo
> > 	...
> > }
> > 
> > which generates an ipc key via ftok().
> 
> That's a question. This is a quote from the ftok() man page:
> 
> "Of course no guarantee can be given that the resulting key_t is unique."
> 
> I think that the best solution is to create a communication file with 
> information about used unique IPC key and add a verification that used 
> IPC semaphores and IPC areas are ours.

It would be nice that the user not need to type magic numbers into a
configuration file, unique or not. I don't know what it involves, but it
would make using the configuration file much easier. 

-- Fernando




-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Patrick Shirkey]

Fernando Pablo Lopez-Lezcano wrote:
> 
> It would be nice that the user not need to type magic numbers into a
> configuration file, unique or not. I don't know what it involves, but it
> would make using the configuration file much easier. 
> 

Even nicer is if this could be embedded like the dmix was eventually so 
that it is unnecessary to use the .asoundrc :)

-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: dsnoop, dshare and dmix plugins

[Jaroslav Kysela]

On Fri, 21 Mar 2003, Patrick Shirkey wrote:

> Fernando Pablo Lopez-Lezcano wrote:
> > 
> > It would be nice that the user not need to type magic numbers into a
> > configuration file, unique or not. I don't know what it involves, but it
> > would make using the configuration file much easier. 
> > 
> 
> Even nicer is if this could be embedded like the dmix was eventually so 
> that it is unnecessary to use the .asoundrc :)

It's a little problematic to add dshare to the global configuration file. 
I've added the dsnoop plugin just now.

						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: dsnoop, dshare and dmix plugins

[Takashi Iwai]

At Fri, 21 Mar 2003 13:56:50 +0100 (CET),
Jaroslav wrote:
> 
> On Fri, 21 Mar 2003, Patrick Shirkey wrote:
> 
> > Fernando Pablo Lopez-Lezcano wrote:
> > > 
> > > It would be nice that the user not need to type magic numbers into a
> > > configuration file, unique or not. I don't know what it involves, but it
> > > would make using the configuration file much easier. 
> > > 
> > 
> > Even nicer is if this could be embedded like the dmix was eventually so 
> > that it is unnecessary to use the .asoundrc :)
> 
> It's a little problematic to add dshare to the global configuration file. 

it would be cool if we have the dynamic voice-assignment function in
dshare...  just a thought.


Takashi


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

Re: dsnoop, dshare and dmix plugins

[Jaroslav Kysela]

On Fri, 21 Mar 2003, Takashi Iwai wrote:

> At Fri, 21 Mar 2003 13:56:50 +0100 (CET),
> Jaroslav wrote:
> > 
> > On Fri, 21 Mar 2003, Patrick Shirkey wrote:
> > 
> > > Fernando Pablo Lopez-Lezcano wrote:
> > > > 
> > > > It would be nice that the user not need to type magic numbers into a
> > > > configuration file, unique or not. I don't know what it involves, but it
> > > > would make using the configuration file much easier. 
> > > > 
> > > 
> > > Even nicer is if this could be embedded like the dmix was eventually so 
> > > that it is unnecessary to use the .asoundrc :)
> > 
> > It's a little problematic to add dshare to the global configuration file. 
> 
> it would be cool if we have the dynamic voice-assignment function in
> dshare...  just a thought.

Can you elaborate more? How we can predict if user want the first two 
(analog) or last two (s/pdif) channels from 10 in the ice1712 case?

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: dsnoop, dshare and dmix plugins

[Takashi Iwai]

At Fri, 21 Mar 2003 18:11:25 +0100 (CET),
Jaroslav wrote:
> 
> On Fri, 21 Mar 2003, Takashi Iwai wrote:
> 
> > At Fri, 21 Mar 2003 13:56:50 +0100 (CET),
> > Jaroslav wrote:
> > > 
> > > On Fri, 21 Mar 2003, Patrick Shirkey wrote:
> > > 
> > > > Fernando Pablo Lopez-Lezcano wrote:
> > > > > 
> > > > > It would be nice that the user not need to type magic numbers into a
> > > > > configuration file, unique or not. I don't know what it involves, but it
> > > > > would make using the configuration file much easier. 
> > > > > 
> > > > 
> > > > Even nicer is if this could be embedded like the dmix was eventually so 
> > > > that it is unnecessary to use the .asoundrc :)
> > > 
> > > It's a little problematic to add dshare to the global configuration file. 
> > 
> > it would be cool if we have the dynamic voice-assignment function in
> > dshare...  just a thought.
> 
> Can you elaborate more? How we can predict if user want the first two 
> (analog) or last two (s/pdif) channels from 10 in the ice1712 case?

well, a word "dynamic" was not suitable.
what i thought is something like "dshare:0" or "dshare:1" to route the
channel as an argument.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: dsnoop, dshare and dmix plugins

[Kristof Pelckmans]

Hi all,

I tried to use the dmix plugin, as mentioned :
> pcm.dmix_analog {
>         type dmix
>         ipc_key 5678293
>         ipc_key_add_uid yes
>         slave {
>                 pcm "hw:0,0"
>         }
>         bindings {
>                 0 0
>                 1 1
>         }
> }

When I do
aplay -D dmix_analog tv.wav 
Playing WAVE 'tv.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
aplay: set_params:810: Channels count non available

The wav-file was recorded from my M-Audio Delta 410 card. Could this still be a problem with the driver ?

So next I tried to do
aplay -D plug:dmix_analog tv.wav 
Playing WAVE 'tv.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo

Which plays some garbled sound, nothing that resembles what I recorded

The strange thing is that the dshare plugings work (no distorted sound), as long as I specify the 'plug' plugin :
aplay -D plug:dshare_right tv.wav

I'm confused about this behaviour, since I thought the memory mapping for dmix and dshare would be relatively similar.

One last question : can you combine dmix and dshare ?

Thanks for any comments !

Kristof

> pcm.dshare_left {
>         type dshare
>         ipc_key 6678293
>         ipc_key_add_uid yes
>         slave {
>                 pcm "hw:0,0"
>         }
>         bindings {
>                 0 0
>         }
> }
> 
> pcm.dshare_right {
>         type dshare
>         ipc_key 6678293
>         ipc_key_add_uid yes
>         slave {
>                 pcm "hw:0,0"
>         }
>         bindings {
>                 0 1
>         }
> }


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

Re: dsnoop, dshare and dmix plugins

[Jaroslav Kysela]

On Mon, 24 Mar 2003, Kristof Pelckmans wrote:

> Hi all,
> 
> I tried to use the dmix plugin, as mentioned :
> > pcm.dmix_analog {
> >         type dmix
> >         ipc_key 5678293
> >         ipc_key_add_uid yes
> >         slave {
> >                 pcm "hw:0,0"
> >         }
> >         bindings {
> >                 0 0
> >                 1 1
> >         }
> > }
> 
> When I do
> aplay -D dmix_analog tv.wav 
> Playing WAVE 'tv.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
> aplay: set_params:810: Channels count non available
> 
> The wav-file was recorded from my M-Audio Delta 410 card. Could this still be a problem with the driver ?

Can I see the output from 'aplay -v -D plug:dmix_analog tv.wav'?

> So next I tried to do
> aplay -D plug:dmix_analog tv.wav
> Playing WAVE 'tv.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
>
> Which plays some garbled sound, nothing that resembles what I recorded

The 32-bit mixing code is not debugged. Please, could you try to change
one line in pcm_dmix.c (alsa-lib/src/pcm/pcm_dmix.c) from
'#ifdef __i386__' to '#ifdef __i386XX__' and recompile library?
We'll see then if it's a problem with the i386 assembler code.

> The strange thing is that the dshare plugings work (no distorted sound),
> as long as I specify the 'plug' plugin : aplay -D plug:dshare_right
> tv.wav
>
> I'm confused about this behaviour, since I thought the memory mapping
> for dmix and dshare would be relatively similar.
>
> One last question : can you combine dmix and dshare ?

Nope. If you use only one application for specific channels (dmix plugin)
then you'll get same results as dshare. The only difference is that dshare
transfers are a bit more optimized (it does only copy not sum of samples).
Perhaps we can optimize dmix in this way later.

                                                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: dsnoop, dshare and dmix plugins

[Kristof Pelckmans]

Hello again,

Quoting Jaroslav Kysela <perex@suse.cz>:
> The 32-bit mixing code is not debugged. Please, could you try to change
> one line in pcm_dmix.c (alsa-lib/src/pcm/pcm_dmix.c) from
> '#ifdef __i386__' to '#ifdef __i386XX__' and recompile library?
> We'll see then if it's a problem with the i386 assembler code.
This works !!! It only plays to the last channel mentioned in the dmix configuration though (so channel 1, but not channel 0).

> Can I see the output from 'aplay -v -D plug:dmix_analog tv.wav'?
aplay -v -D plug:dmix_analog tv.wav
Playing WAVE 'tv.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
Plug PCM: Route conversion PCM (sformat=S32_LE)
Transformation table:
0 <- 0*0.5 + 1*0.5
Its setup is:
stream       : PLAYBACK
access       : RW_INTERLEAVED
format       : S32_LE
subformat    : STD
channels     : 2
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 32
buffer_size  : 6553
period_size  : 3276
period_time  : 68250
tick_time    : 0
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 3276
xfer_align   : 3276
start_threshold  : 6552
stop_threshold   : 6553
silence_threshold: 0
silence_size : 0
boundary     : 1717829632
Slave: Direct Stream Mixing PCM

Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S32_LE
subformat    : STD
channels     : 1
rate         : 48000
exact rate   : nan (0/0)
msbits       : 0
buffer_size  : 6553
period_size  : 3276
period_time  : 68250
tick_time    : 0
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 3276
xfer_align   : 3276
start_threshold  : 6552
stop_threshold   : 6553
silence_threshold: 0
silence_size : 0
boundary     : 1717829632
Hardware PCM card 0 'M Audio Delta 410' device 0 subdevice 0

Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S32_LE
subformat    : STD
channels     : 10
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 24
buffer_size  : 6553
period_size  : 3276
period_time  : 68250
tick_time    : 10000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 3276
xfer_align   : 3276
start_threshold  : 1
stop_threshold   : 1717829632
silence_threshold: 0
silence_size : 1717829632
boundary     : 1717829632

Cheers !

Kristof


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

Re: dsnoop, dshare and dmix plugins

[Patrick Shirkey]

Jaroslav Kysela wrote:
>
> 
> And finally the dshare plugin (used standard stereo device and using left 
> and right channels separately):
> 
> pcm.dshare_left {
>         type dshare
>         ipc_key 6678293
>         ipc_key_add_uid yes
>         slave {
>                 pcm "hw:0,0"
>         }
>         bindings {
>                 0 0
>         }
> }
> 
> pcm.dshare_right {
>         type dshare
>         ipc_key 6678293
>         ipc_key_add_uid yes
>         slave {
>                 pcm "hw:0,0"
>         }
>         bindings {
>                 0 1
>         }
> }
> 

Using the above example I get this error.

  arecord -f cd -D plug:dshare_left
ALSA lib dlmisc.c:107:(snd_dlsym_verify) unable to verify version for 
symbol _snd_pcm_dshare_open
ALSA lib pcm.c:1802:(snd_pcm_open_conf) symbol _snd_pcm_dshare_open is 
not defined inside (null)
arecord: main:479: audio open error: No such device or address

I would also like to test out the alsa_jack plugin but cannot find a 
reference to it anywhere. Has it been removed temporarily?


-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/