On Sun, 19 Oct 2003, Frank Barknecht wrote:

> Hallo,
> Jaroslav Kysela hat gesagt: // Jaroslav Kysela wrote:
>
> > Here is a complex example:
>
> Thank you, I think I now understand the syntax. I have two more
> questions, though...
>
> > pcm.dmix1 {
> >         type dmix
> >         ipc_key 1024
> >         slave {
> >                 pcm "hw:0,0"
> >                 period_time 0
> >                 period_size 1024
> >                 buffer_size 8192
> >                 #periods 128
> >                 rate 8000
>
> Am I right that these values *have* to match the capabilities of the
> hardware? For example this example does not work on my Midiman Delta,
> and I wouldn't expect it to.

See my previous mail. For your card, 8192 is too much, try 4096 for the
buffer_size parameter.

> >         bindings {
> >                 0 0
> >                 1 1
> >         }
>
> The docs say about bindings:
>
>         bindings {              # note: this is client independent!!!
>                 N INT           # maps slave channel to client channel N
>         }
>
> Do I understand this correctly, that for example this binding
>
> bindings {
> 0 1
> 1 0 }
>
>
> would just switch left and right channels in a simple stereo stream?

Yes, but the real benefit for the multichannel card is that you can cut
the number of transferred channels. In my case, the plugins - which
operates on top of the dmix1 PCM definition - will transfer only two
channels and dmix will mix only two channels. It will save time for you
(when comparing to the full playback bandwith of your ICE1712 based card -
10 channels). Anyway, for the "channel split" purpose, it is better to use
the dshare plugin which does not do any mixing, but you can give selected
channels to different applications (it was also most wanted feature from
some users).

Perhaps one more example to make things clear:

pcm.dmix01 {
        type dmix
        ipc_key 1024
        slave {
                pcm "hw:0,0"
                period_time 0
                period_size 1024
                buffer_size 4096
                rate 44100              # we want to play CDs only
        }
        bindings {
                0 0
                1 1
        }
}

pcm.dmix23 {
        type dmix
        ipc_key 1024
        slave {
                pcm "hw:0,0"
                period_time 0
                period_size 1024
                buffer_size 4096
                rate 44100              # we want to play CDs only
        }
        bindings {
                0 2
                1 3
        }
}

Ok, we have two dmix pcms with same ipc_key. That's ok, because we want to
operate with the same exclusive output device "hw:0,0". The 'dmix01' sends
a stereo stream to channels 0 and 1 while the 'dmix23' sends a stereo
stream to channels 2 and 3. Again, both pcms are sharing one device and
because dmix plugin is used, multiple clients are suported. If you change
'type dmix' to 'type dshare', only one clients per pcm definition is
supported, but the trasfers are very fast because no mixing is done.
Note: slave {} parameters should match otherwise the hw:0,0 parameters
will be allocated for the first pcm which opened the hw:0,0 device.

                                                Jaroslav

-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com
_______________________________________________
Alsa-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-user

Reply via email to