Complex mixer questions

Complex mixer questions

[Giuliano Pochini]

Please give me some suggestions about how to build a control interface
for this thing. The card has Ni inputs and No ouputs. It can route any
input to any number of outputs and each connection have a different
gain. e.g:

    ---50%----- Out0
   /
In0 ---30%----- Out3
   \         /
    \ -60%---
     X 
    / -100%---- Out4
   /          /
In5----10%----


How have I to call a switch that selects SPDIFCoax/SPDIFOpt/ADAT ?


Bye.




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: Complex mixer questions

[Paul Davis]

>Please give me some suggestions about how to build a control interface
>for this thing. The card has Ni inputs and No ouputs. It can route any
>input to any number of outputs and each connection have a different
>gain. e.g:
>
>    ---50%----- Out0
>   /
>In0 ---30%----- Out3
>   \         /
>    \ -60%---
>     X 
>    / -100%---- Out4
>   /          /
>In5----10%----

the hammerfall HDSP series are the same.

there are 2 questions:

   1) what ALSA API to use, and how to use it?
   2) what would a GUI look like?

for (2), i suggest you *carefully* study RME's totalmix application, a
version of which will soon be available for linux.

for (1), we use the control API but use it in a slightly unorthodox
way. the control API normally is used to set control values in a
simple 1:1 mapping between a control parameter and its new
value. instead, we use 2 parameters (the source and the destination)
and 1 value (the gain level). this does mean that alsactl can't handle
it correctly, but so far no better suggestion has arisen. the hdsp
series would have 1500+ control elements if we used the 1:1 method.

>How have I to call a switch that selects SPDIFCoax/SPDIFOpt/ADAT ?

just use the control API. there is no standard name for such a switch.

btw, what h/w is this?





-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

matrix mixer control (Re: Complex mixer questions)

[Takashi Iwai]

At Sat, 29 Mar 2003 09:14:48 -0500,
Paul Davis wrote:
> 
> >Please give me some suggestions about how to build a control interface
> >for this thing. The card has Ni inputs and No ouputs. It can route any
> >input to any number of outputs and each connection have a different
> >gain. e.g:
> >
> >    ---50%----- Out0
> >   /
> >In0 ---30%----- Out3
> >   \         /
> >    \ -60%---
> >     X 
> >    / -100%---- Out4
> >   /          /
> >In5----10%----
> 
> the hammerfall HDSP series are the same.
> 
> there are 2 questions:
> 
>    1) what ALSA API to use, and how to use it?
>    2) what would a GUI look like?
> 
> for (2), i suggest you *carefully* study RME's totalmix application, a
> version of which will soon be available for linux.

is it the gui that Thomas has worked on?
it would be nice to have such a tool in the common alsa-tools tree.
please send a patch if it's finished.


> for (1), we use the control API but use it in a slightly unorthodox
> way. the control API normally is used to set control values in a
> simple 1:1 mapping between a control parameter and its new
> value. instead, we use 2 parameters (the source and the destination)
> and 1 value (the gain level). this does mean that alsactl can't handle
> it correctly, but so far no better suggestion has arisen. the hdsp
> series would have 1500+ control elements if we used the 1:1 method.

i think it's good time to discuss this theme again.

as we talked in the LAD meeting, there are some possibilities:

1. implement it on hwdep device
2. implement it as a new control element (e.g. CTL_ELEM_MATRIX)
3. introduce a flag to allow the indirect access with CTL_ELEM_INTEGER
4. use 1500+ mixer elements.


we all agreed that really allocating thousands of elements is not
clever.  so, the case 4 would introduce some "virtual" mapping in the
kernel side, but from the user-space, it looks like a normal control
API access.  however, this will need many changes in the alsa core
code.


OTOH, the case 1 would need no change for the alsa core itself, but
the driver needs to implement by itself.  and above all, there is no
notification mechanism.

the case 2 is, IMO, the most straightforward way.  the info field will
have number of rows and columns, in addition to min, max and step
values.  the change in the alsa core wouldn't be too much.

the case 3 would be similar with case 2, but use an additional bit
flag to indicate the matrix type.

in the cases 2 and 3, you'll need to change alsactl to save/restore
the whole matrix data.  in the case 4, it's not.  the case 1, alsactl
cannot do it, since it's on hwdep device.


Takashi


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

RE: matrix mixer control (Re: Complex mixer questio

[Giuliano Pochini]

On 31-Mar-2003 Takashi Iwai wrote:
> as we talked in the LAD meeting, there are some possibilities:
>
> 1. implement it on hwdep device
> 2. implement it as a new control element (e.g. CTL_ELEM_MATRIX)
> 3. introduce a flag to allow the indirect access with CTL_ELEM_INTEGER
> 4. use 1500+ mixer elements.

I vote for 2. It provides what hi-end card drivers need and IMHO it
should be simple to implement. There is another possibility: two
virtual controls, row and column, select an element of the matrix and
a third control r/w the value. I don't like it. I prefer each element
controls a real hw parameter.

Bye.



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

Re: matrix mixer control (Re: Complex mixer questions)

[Jaroslav Kysela]

On Mon, 31 Mar 2003, Takashi Iwai wrote:

> i think it's good time to discuss this theme again.
> 
> as we talked in the LAD meeting, there are some possibilities:
> 
> 1. implement it on hwdep device
> 2. implement it as a new control element (e.g. CTL_ELEM_MATRIX)
> 3. introduce a flag to allow the indirect access with CTL_ELEM_INTEGER
> 4. use 1500+ mixer elements.
> 
> 
> we all agreed that really allocating thousands of elements is not
> clever.  so, the case 4 would introduce some "virtual" mapping in the
> kernel side, but from the user-space, it looks like a normal control
> API access.  however, this will need many changes in the alsa core
> code.
> 
> 
> OTOH, the case 1 would need no change for the alsa core itself, but
> the driver needs to implement by itself.  and above all, there is no
> notification mechanism.
> 
> the case 2 is, IMO, the most straightforward way.  the info field will
> have number of rows and columns, in addition to min, max and step
> values.  the change in the alsa core wouldn't be too much.

I think that we simply touch the barrier given by 'struct
sndrv_ctl_elem_id'. The identification which differentiate identical
controls is only the 'index' value. If we don't use 'struct
sndrv_ctl_elem_id' as the identification unit for read/writing of data,
then we end with trouble with notification and other representation
(single data unit locking, inactive flag etc). Imagine three or four
dimensional data types. Do you think that it's really worth to describe
these types? My original idea was to keep the control API as simple as
possible. The only one exception is the SNDRV_CTL_ELEM_TYPE_IEC958
structure but making more of those complicated data definitions seems to
be as a bad idea in my eyes.

The case 4) doesn't look as bad as it seems at first look. We do already 
have many controls in emu10k1 and trident drivers (route, pcm volumes 
etc.). If we optimize the memory usage and representation for these 
multiple identical controls, more drivers will benefit.

Note: Think in this way: If we have such large matrix mixer, then we
should allow to different applications sharing (lock -thus allocate- some
elements from matrix). Your suggested "solutions" (other than 4) don't
allow it fully. This might cause trouble in future.

> the case 3 would be similar with case 2, but use an additional bit
> flag to indicate the matrix type.

I don't understand. We have already SNDRV_CTL_ELEM_ACCESS_INDIRECT 
although it is not implemented. The problem here is that you will have 
totaly unoptimized event notification (because we can notify only change 
for whole row) and problematic sharing of single values (element locking).

> in the cases 2 and 3, you'll need to change alsactl to save/restore
> the whole matrix data.  in the case 4, it's not.  the case 1, alsactl
> cannot do it, since it's on hwdep device.

						Jaroslav

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




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

Re: matrix mixer control (Re: Complex mixer questio

[Giuliano Pochini]

On 31-Mar-2003 Jaroslav Kysela wrote:
>> the case 2 is, IMO, the most straightforward way.  the info field will
>> have number of rows and columns, in addition to min, max and step
>> values.  the change in the alsa core wouldn't be too much.
> 
> I think that we simply touch the barrier given by 'struct
> sndrv_ctl_elem_id'. The identification which differentiate identical
> controls is only the 'index' value. If we don't use 'struct
> sndrv_ctl_elem_id' as the identification unit for read/writing of data,
> then we end with trouble with notification and other representation
> (single data unit locking, inactive flag etc). Imagine three or four
> dimensional data types. [...]

.count is an uint32. Ok, suppose we do not change it. Then the low
level driver has to tell user space apps that the index number
addresses elements in a W*H matrix, so the apps will locate the
cell at (x,y) by a simple index=x+W*y.


Bye.



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

Re: matrix mixer control (Re: Complex mixer questio

[Jaroslav Kysela]

On Mon, 31 Mar 2003, Giuliano Pochini wrote:

> 
> On 31-Mar-2003 Jaroslav Kysela wrote:
> >> the case 2 is, IMO, the most straightforward way.  the info field will
> >> have number of rows and columns, in addition to min, max and step
> >> values.  the change in the alsa core wouldn't be too much.
> > 
> > I think that we simply touch the barrier given by 'struct
> > sndrv_ctl_elem_id'. The identification which differentiate identical
> > controls is only the 'index' value. If we don't use 'struct
> > sndrv_ctl_elem_id' as the identification unit for read/writing of data,
> > then we end with trouble with notification and other representation
> > (single data unit locking, inactive flag etc). Imagine three or four
> > dimensional data types. [...]
> 
> .count is an uint32. Ok, suppose we do not change it. Then the low
> level driver has to tell user space apps that the index number
> addresses elements in a W*H matrix, so the apps will locate the
> cell at (x,y) by a simple index=x+W*y.

Yes, except that the lowlevel driver won't tell that there is a matrix. It
can be indentified by element name (string) or by the description in the
user space. We decided to remove all mixer routing/connection/element
types (except the value types) information from the kernel space to
simplify drivers.

						Jaroslav

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



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

Re: matrix mixer control (Re: Complex mixer questio

[Paul Davis]

i don't understand this discussion. it seems to originate from
jaroslav's desire to have alsactl be capable of automatically working
correctly for everything. i say this because the current scheme with
the hdsp works just fine, and will work even better in thomas's new
version of the driver in which all the controls are in the hwdep
"namespace", so that regular mixer programs won't (or shouldn't) see
them. all that doesn't work is alsactl.

amixer is quite able to handle the current hdsp control design, and so
i ask again, why do we have both amixer and alsactl when they do
identical work but in different ways? amixer is more flexible, and i
think that it would be better to focus on extending it (for example,
by allowing it to handle multiple controls in one invocation) so that
it can replace alsactl and form the basis of a flexible, powerful
script-based configuration system. i think this is better than
requiring the "shoe-horning" of a difficult issue (matrix controls)
into unnatural frameworks. i say unnatural because the mixer on the
hdsp series really is a matrix, not 1564 individual controls.

--p






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

Re: matrix mixer control (Re: Complex mixer questio

[Jaroslav Kysela]

On Mon, 31 Mar 2003, Paul Davis wrote:

> i don't understand this discussion. it seems to originate from
> jaroslav's desire to have alsactl be capable of automatically working
> correctly for everything. i say this because the current scheme with
> the hdsp works just fine, and will work even better in thomas's new
> version of the driver in which all the controls are in the hwdep
> "namespace", so that regular mixer programs won't (or shouldn't) see
> them. all that doesn't work is alsactl.
> 
> amixer is quite able to handle the current hdsp control design, and so
> i ask again, why do we have both amixer and alsactl when they do
> identical work but in different ways? amixer is more flexible, and i
> think that it would be better to focus on extending it (for example,
> by allowing it to handle multiple controls in one invocation) so that
> it can replace alsactl and form the basis of a flexible, powerful
> script-based configuration system. i think this is better than
> requiring the "shoe-horning" of a difficult issue (matrix controls)
> into unnatural frameworks. i say unnatural because the mixer on the
> hdsp series really is a matrix, not 1564 individual controls.

amixer - command line oriented tool to handle card settings oriented only
         to mixer elements
alsactl - handle all elements and store/restore settings to/from a file at 
          one shot

I think that both tools are different. While amixer supports more human 
"readable" format to modify/read elements, the alsactl purpose is batch 
processing of card settings with exact file syntax.

Paul, with all respects, please, read my original message. I am (maybe) 
thinking a bit forward.

Actually, we are not able to ENUMERATE all hardware controls in a generic
way for HDSP regarless you are using the element values as identification
what to read/write or hwdep interface. You need to write your own tools
for this extension to API which is not "standard". No ALSA generic 
applications can share your control mechanism.

Little practise example: Imagine a small program using actual ALSA 
API which watches one control element and shows the actual value and 
writes down the changes. It can be used with EVERY CARD except HDSP with 
it's own API for the matrix mixer. Is this good or bad? It's bad. I was 
happy to see in Karslruhe the sequencer applications working together via 
one interface. The same applies to the control API. If you are different, 
applications don't talk with you anymore.

Also, if you will support all features as the control interface offers, 
then you'll end with nearly same code. And we definitely want to eliminate 
the code duplication.

Please, also think in direction, that we want to control the card settings 
over the control API but not to describe the connection layout (e.g. - 
there is a matrix of volumes with N x M size). This is definitely thing 
for the user space and we'll extend alsa-lib at some time to offer this 
layer to applications as well doing transparent mapping to the control 
elements.

						Jaroslav

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



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

Re: matrix mixer control (Re: Complex mixer questio

[Abramo Bagnara]

I agree with Jaroslav fully:
- have one ALSA control for each primitive hw control (1536 different 
controls)
- add a field to struct sndrv_ctl_elem_info explaining how index field 
of sndvr_ctl_elem_id should be interpreted (32,16+16,10+11+11, ecc.)

This permit to have native support for N dimensional control.

About kernel memory issues, this concerns easily solvable implementation 
detail to not worry about when designing sane API.

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

Re: matrix mixer control (Re: Complex mixer questio

[Jaroslav Kysela]

On Tue, 1 Apr 2003, Abramo Bagnara wrote:

> 
> I agree with Jaroslav fully:
> - have one ALSA control for each primitive hw control (1536 different 
> controls)
> - add a field to struct sndrv_ctl_elem_info explaining how index field 
> of sndvr_ctl_elem_id should be interpreted (32,16+16,10+11+11, ecc.)
> 
> This permit to have native support for N dimensional control.
> 
> About kernel memory issues, this concerns easily solvable implementation 
> detail to not worry about when designing sane API.

Ok, I've added the dimension description to the info structure. Although 
it is completely irrelevant to data transfers.

Also, I've implemented multi element in the kernel space to save memory 
and it makes the searching faster. The reference code is in the trident 
driver. I'll recode other drivers containing many "same" controls to use 
this method later.

The user space applications won't notice any changes.

						Jaroslav

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



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

Re: matrix mixer control (Re: Complex mixer questio

[Takashi Iwai]

At Tue, 1 Apr 2003 16:08:01 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 1 Apr 2003, Abramo Bagnara wrote:
> 
> > 
> > I agree with Jaroslav fully:
> > - have one ALSA control for each primitive hw control (1536 different 
> > controls)
> > - add a field to struct sndrv_ctl_elem_info explaining how index field 
> > of sndvr_ctl_elem_id should be interpreted (32,16+16,10+11+11, ecc.)
> > 
> > This permit to have native support for N dimensional control.
> > 
> > About kernel memory issues, this concerns easily solvable implementation 
> > detail to not worry about when designing sane API.
> 
> Ok, I've added the dimension description to the info structure. Although 
> it is completely irrelevant to data transfers.
 
sorry for the late response.

not much to say at this time, as you already decided.
i think the new scheme is fine, too.

a tiny glitch would be the use of numid in alsactl, although you can
avoid this via --force option.


> Also, I've implemented multi element in the kernel space to save memory 
> and it makes the searching faster. The reference code is in the trident 
> driver. I'll recode other drivers containing many "same" controls to use 
> this method later.

this sounds promising.


ciao,

Takashi


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

Re: matrix mixer control (Re: Complex mixer questio

[Paul Davis]

>Ok, I've added the dimension description to the info structure. Although 
>it is completely irrelevant to data transfers.
>
>Also, I've implemented multi element in the kernel space to save memory 
>and it makes the searching faster. The reference code is in the trident 
>driver. I'll recode other drivers containing many "same" controls to use 
>this method later.
>
>The user space applications won't notice any changes.

please don't do the hdsp yet. thomas will be sending a big patch for
the hdsp today or tomorrow. it will make merging easier.


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

Re: matrix mixer control (Re: Complex mixer questio

[Abramo Bagnara]

Jaroslav Kysela ha scritto:
> On Tue, 1 Apr 2003, Abramo Bagnara wrote:
> 
> 
>>I agree with Jaroslav fully:
>>- have one ALSA control for each primitive hw control (1536 different 
>>controls)
>>- add a field to struct sndrv_ctl_elem_info explaining how index field 
>>of sndvr_ctl_elem_id should be interpreted (32,16+16,10+11+11, ecc.)
>>
>>This permit to have native support for N dimensional control.
>>
>>About kernel memory issues, this concerns easily solvable implementation 
>>detail to not worry about when designing sane API.
> 
> 
> Ok, I've added the dimension description to the info structure. Although 
> it is completely irrelevant to data transfers.
> 
> Also, I've implemented multi element in the kernel space to save memory 
> and it makes the searching faster. The reference code is in the trident 
> driver. I'll recode other drivers containing many "same" controls to use 
> this method later.

The lack of sparse matrix support I see in your implementation is a very 
unfortunate design choice.

I suggest you to use an hash table pointing to a pair { kcontrol_index, 
kcontrol_volatile_index } (16+16 should be enough) for control id 
searching and to move index info into snd_kcontrol_volatile_t.

Note also that allocating snd_kcontrol_volatile's at end of struct 
_snd_kcontrol (i.e. adding

         snd_kcontrol_volatile_t vd[0];    /* volatile data */

at end of struct), you'd avoid an extra indirection and separate 
allocation (not had time to double check if this conflicts with 
something other, however).

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

Re: matrix mixer control (Re: Complex mixer questio

[Jaroslav Kysela]

On Wed, 2 Apr 2003, Abramo Bagnara wrote:

> Jaroslav Kysela ha scritto:
> > On Tue, 1 Apr 2003, Abramo Bagnara wrote:
> > 
> > 
> >>I agree with Jaroslav fully:
> >>- have one ALSA control for each primitive hw control (1536 different 
> >>controls)
> >>- add a field to struct sndrv_ctl_elem_info explaining how index field 
> >>of sndvr_ctl_elem_id should be interpreted (32,16+16,10+11+11, ecc.)
> >>
> >>This permit to have native support for N dimensional control.
> >>
> >>About kernel memory issues, this concerns easily solvable implementation 
> >>detail to not worry about when designing sane API.
> > 
> > 
> > Ok, I've added the dimension description to the info structure. Although 
> > it is completely irrelevant to data transfers.
> > 
> > Also, I've implemented multi element in the kernel space to save memory 
> > and it makes the searching faster. The reference code is in the trident 
> > driver. I'll recode other drivers containing many "same" controls to use 
> > this method later.
> 
> The lack of sparse matrix support I see in your implementation is a very 
> unfortunate design choice.
> 
> I suggest you to use an hash table pointing to a pair { kcontrol_index, 
> kcontrol_volatile_index } (16+16 should be enough) for control id 
> searching and to move index info into snd_kcontrol_volatile_t.

I don't understand. The matrix is simply mapped to linear space. There is
no requirement to do something special.

> Note also that allocating snd_kcontrol_volatile's at end of struct 
> _snd_kcontrol (i.e. adding
> 
>          snd_kcontrol_volatile_t vd[0];    /* volatile data */
> 
> at end of struct), you'd avoid an extra indirection and separate 
> allocation (not had time to double check if this conflicts with 
> something other, however).

Good idea. Done.

						Jaroslav

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




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

Re: matrix mixer control (Re: Complex mixer questio

[Abramo Bagnara]

Jaroslav Kysela ha scritto:
> On Wed, 2 Apr 2003, Abramo Bagnara wrote:
> 
> 
>>Jaroslav Kysela ha scritto:
>>
>>>On Tue, 1 Apr 2003, Abramo Bagnara wrote:
>>>
>>>
>>>
>>>>I agree with Jaroslav fully:
>>>>- have one ALSA control for each primitive hw control (1536 different 
>>>>controls)
>>>>- add a field to struct sndrv_ctl_elem_info explaining how index field 
>>>>of sndvr_ctl_elem_id should be interpreted (32,16+16,10+11+11, ecc.)
>>>>
>>>>This permit to have native support for N dimensional control.
>>>>
>>>>About kernel memory issues, this concerns easily solvable implementation 
>>>>detail to not worry about when designing sane API.
>>>
>>>
>>>Ok, I've added the dimension description to the info structure. Although 
>>>it is completely irrelevant to data transfers.
>>>
>>>Also, I've implemented multi element in the kernel space to save memory 
>>>and it makes the searching faster. The reference code is in the trident 
>>>driver. I'll recode other drivers containing many "same" controls to use 
>>>this method later.
>>
>>The lack of sparse matrix support I see in your implementation is a very 
>>unfortunate design choice.
>>
>>I suggest you to use an hash table pointing to a pair { kcontrol_index, 
>>kcontrol_volatile_index } (16+16 should be enough) for control id 
>>searching and to move index info into snd_kcontrol_volatile_t.
> 
> 
> I don't understand. The matrix is simply mapped to linear space. There is
> no requirement to do something special.

Perhaps I'm beginning to understand: you're using ordinary access for 
first N-1 dimensions and snd_kcontrol_volatile_t only for last dimension 
and only for contiguous values of index.

I believe this is not the right approach and linear search on a large 
number of controls should be avoided (because not scalable).

Also suppose to have a 10*10 control matrix but for each row but #3 you 
don't have a control for column #2, #4 and #6.

With your solution you still need to have 4*9+1=37 separate but 
identical snd_kcontrol_t instead of 1 if you adopt the solution I propose.

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

Re: matrix mixer control (Re: Complex mixer questio

[Jaroslav Kysela]

On Wed, 2 Apr 2003, Abramo Bagnara wrote:

> Jaroslav Kysela ha scritto:
> > On Wed, 2 Apr 2003, Abramo Bagnara wrote:
> > 
> > 
> >>Jaroslav Kysela ha scritto:
> >>
> >>>On Tue, 1 Apr 2003, Abramo Bagnara wrote:
> >>>
> >>>
> >>>
> >>>>I agree with Jaroslav fully:
> >>>>- have one ALSA control for each primitive hw control (1536 different 
> >>>>controls)
> >>>>- add a field to struct sndrv_ctl_elem_info explaining how index field 
> >>>>of sndvr_ctl_elem_id should be interpreted (32,16+16,10+11+11, ecc.)
> >>>>
> >>>>This permit to have native support for N dimensional control.
> >>>>
> >>>>About kernel memory issues, this concerns easily solvable implementation 
> >>>>detail to not worry about when designing sane API.
> >>>
> >>>
> >>>Ok, I've added the dimension description to the info structure. Although 
> >>>it is completely irrelevant to data transfers.
> >>>
> >>>Also, I've implemented multi element in the kernel space to save memory 
> >>>and it makes the searching faster. The reference code is in the trident 
> >>>driver. I'll recode other drivers containing many "same" controls to use 
> >>>this method later.
> >>
> >>The lack of sparse matrix support I see in your implementation is a very 
> >>unfortunate design choice.
> >>
> >>I suggest you to use an hash table pointing to a pair { kcontrol_index, 
> >>kcontrol_volatile_index } (16+16 should be enough) for control id 
> >>searching and to move index info into snd_kcontrol_volatile_t.
> > 
> > 
> > I don't understand. The matrix is simply mapped to linear space. There is
> > no requirement to do something special.
> 
> Perhaps I'm beginning to understand: you're using ordinary access for 
> first N-1 dimensions and snd_kcontrol_volatile_t only for last dimension 
> and only for contiguous values of index.
> 
> I believe this is not the right approach and linear search on a large 
> number of controls should be avoided (because not scalable).
> 
> Also suppose to have a 10*10 control matrix but for each row but #3 you 
> don't have a control for column #2, #4 and #6.
> 
> With your solution you still need to have 4*9+1=37 separate but 
> identical snd_kcontrol_t instead of 1 if you adopt the solution I propose.

I feel we are still thinking in a different way. The separating of
volatile data is only access and memory optimization. The code in the
control interface uses still linear lookups. Note that there is no
restriction to use this "multi" element for matrix only. Then address in
matrix is always mapped to linear one. If you want a gap inside matrix,
then set the INACTIVE flag to the access field (volatile data). It's quite
complicated to describe such incomplete matrixes in a generic way. Note
that the whole matrix is still represented as one multi element inside the
kernel space (except that volatile data are separate for each value inside
matrix).

						Jaroslav

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



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

Re: matrix mixer control (Re: Complex mixer questio

[Abramo Bagnara]

Jaroslav Kysela ha scritto:
> 
> I feel we are still thinking in a different way. The separating of
> volatile data is only access and memory optimization. The code in the
> control interface uses still linear lookups. Note that there is no
> restriction to use this "multi" element for matrix only. Then address in

I realized that.

> matrix is always mapped to linear one. If you want a gap inside matrix,
> then set the INACTIVE flag to the access field (volatile data). It's quite

It's not inactive, it does not exists.

> complicated to describe such incomplete matrixes in a generic way. Note

? Why complicated?

What about snd_ctl_add_index(ctl, index) (then you can use data tables, 
loops, wrappers, etc.)

> that the whole matrix is still represented as one multi element inside the
> kernel space (except that volatile data are separate for each value inside
> matrix).

This is true only for non sparse matrix.

Ortogonally to that, IMO the increasing numbers of controls in modern 
professional hardware justify the choice of hash table access to 
controls (try to imagine a 26 channel hardware level meter that need to 
be polled 50 times per second).

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

Re: matrix mixer control (Re: Complex mixer questio

[Paul Davis]

>Ortogonally to that, IMO the increasing numbers of controls in modern 
>professional hardware justify the choice of hash table access to 
>controls (try to imagine a 26 channel hardware level meter that need to 
>be polled 50 times per second).

TotalMix for the HDSP will not do that. Thomas is working on mapping
the meters into user space. Its not reasonable to do this via system
calls if you want to access them in an RT thread. As a fill-in measure
until that is done, I think he created a control that gets all the
values in a single system call.

--p



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

Re: matrix mixer control (Re: Complex mixer questio

[Jaroslav Kysela]

On Wed, 2 Apr 2003, Paul Davis wrote:

> >Ortogonally to that, IMO the increasing numbers of controls in modern 
> >professional hardware justify the choice of hash table access to 
> >controls (try to imagine a 26 channel hardware level meter that need to 
> >be polled 50 times per second).
> 
> TotalMix for the HDSP will not do that. Thomas is working on mapping
> the meters into user space. Its not reasonable to do this via system
> calls if you want to access them in an RT thread. As a fill-in measure
> until that is done, I think he created a control that gets all the
> values in a single system call.

Why peak reading requires a RT-task? It's not time critical operation.

						Jaroslav

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



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

Re: matrix mixer control (Re: Complex mixer questio

[Paul Davis]

>On Wed, 2 Apr 2003, Paul Davis wrote:
>
>> >Ortogonally to that, IMO the increasing numbers of controls in modern 
>> >professional hardware justify the choice of hash table access to 
>> >controls (try to imagine a 26 channel hardware level meter that need to 
>> >be polled 50 times per second).
>> 
>> TotalMix for the HDSP will not do that. Thomas is working on mapping
>> the meters into user space. Its not reasonable to do this via system
>> calls if you want to access them in an RT thread. As a fill-in measure
>> until that is done, I think he created a control that gets all the
>> values in a single system call.
>
>Why peak reading requires a RT-task? It's not time critical operation.

We're not talking about "metering" in the sense of visual display -
that's definitely not a real-time issue. But using the meter value can
be.  For example, JACK now makes port meter values available to
clients in their process() callbacks. Other native-ALSA applications
may want to use current meter values to affect their RT thread's
operation (e.g. threshold-gated recording initiation).

--p




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

Re: matrix mixer control (Re: Complex mixer questio

[Jaroslav Kysela]

On Wed, 2 Apr 2003, Abramo Bagnara wrote:

> Jaroslav Kysela ha scritto:
> > 
> > I feel we are still thinking in a different way. The separating of
> > volatile data is only access and memory optimization. The code in the
> > control interface uses still linear lookups. Note that there is no
> > restriction to use this "multi" element for matrix only. Then address in
> 
> I realized that.
> 
> > matrix is always mapped to linear one. If you want a gap inside matrix,
> > then set the INACTIVE flag to the access field (volatile data). It's quite
> 
> It's not inactive, it does not exists.
> 
> > complicated to describe such incomplete matrixes in a generic way. Note
> 
> ? Why complicated?
> 
> What about snd_ctl_add_index(ctl, index) (then you can use data tables, 
> loops, wrappers, etc.)

It breaks the linearity and makes lookups much slower.

> > that the whole matrix is still represented as one multi element inside the
> > kernel space (except that volatile data are separate for each value inside
> > matrix).
> 
> This is true only for non sparse matrix.
> 
> Ortogonally to that, IMO the increasing numbers of controls in modern 
> professional hardware justify the choice of hash table access to 
> controls (try to imagine a 26 channel hardware level meter that need to 
> be polled 50 times per second).

I don't mind if I have only one lookup for this set of controls as present 
in the current code. Actually, the most of cards have around tenths of 
controls (including HDSP driver after ported to use multi controls) so 
adding a hash lookup is not a big win in my eyes. Yes, we can do it in 
future, when we will have hundreds or thousands controls per card.

						Jaroslav

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



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

Re: matrix mixer control (Re: Complex mixer questio

[Abramo Bagnara]

Jaroslav Kysela ha scritto:
> On Wed, 2 Apr 2003, Abramo Bagnara wrote:
> 
> 
>>Jaroslav Kysela ha scritto:
>>
>>>I feel we are still thinking in a different way. The separating of
>>>volatile data is only access and memory optimization. The code in the
>>>control interface uses still linear lookups. Note that there is no
>>>restriction to use this "multi" element for matrix only. Then address in
>>
>>I realized that.
>>
>>
>>>matrix is always mapped to linear one. If you want a gap inside matrix,
>>>then set the INACTIVE flag to the access field (volatile data). It's quite
>>
>>It's not inactive, it does not exists.
>>
>>
>>>complicated to describe such incomplete matrixes in a generic way. Note
>>
>>? Why complicated?
>>
>>What about snd_ctl_add_index(ctl, index) (then you can use data tables, 
>>loops, wrappers, etc.)
> 
> 
> It breaks the linearity and makes lookups much slower.

This is why I combined that with hash table proposal i.e. contemporarily 
to clean, proper support for generic, maybe sparse, N-dimensional 
matrix, we would transform id lookup from O(n) to O(1).

>>>that the whole matrix is still represented as one multi element inside the
>>>kernel space (except that volatile data are separate for each value inside
>>>matrix).
>>
>>This is true only for non sparse matrix.
>>
>>Ortogonally to that, IMO the increasing numbers of controls in modern 
>>professional hardware justify the choice of hash table access to 
>>controls (try to imagine a 26 channel hardware level meter that need to 
>>be polled 50 times per second).
> 
> 
> I don't mind if I have only one lookup for this set of controls as present 
> in the current code. Actually, the most of cards have around tenths of 
> controls (including HDSP driver after ported to use multi controls) so 
> adding a hash lookup is not a big win in my eyes. Yes, we can do it in 
> future, when we will have hundreds or thousands controls per card.

I agree with you it's only an implementation detail now, but I sent my 
comments because my feeling is that time for that is already come.

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

Re: matrix mixer control (Re: Complex mixer questio

[Paul Davis]

>I agree with Jaroslav fully:

i agree fully with you. i'm not clear that this is what jaroslav was
proposing, but if so, then it seems good to me.

>- have one ALSA control for each primitive hw control (1536 different 
>controls)
>- add a field to struct sndrv_ctl_elem_info explaining how index field 
>of sndvr_ctl_elem_id should be interpreted (32,16+16,10+11+11, ecc.)


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

Re: matrix mixer control (Re: Complex mixer questio

[Matt Flax]

I think this is a great step forward ... it will open the door for 3D 
array audio applications.
Typically these applications use 3D speaker arrays which each have 
individual gains set for each audio 'object'.
Consequently depending on an audio object's location in 3D space, will 
depend on the relative speaker gains for that particular audio object.

Consequently each audio object has its own mixer matrix. There is also a 
master mixer matrix for calibration - this generally occurs when you 
have external amplifiers which are different or not calibrated.

Matt

On Mon, Mar 31, 2003 at 03:03:04PM +0200, Giuliano Pochini wrote:
> 
> On 31-Mar-2003 Jaroslav Kysela wrote:
> >> the case 2 is, IMO, the most straightforward way.  the info field will
> >> have number of rows and columns, in addition to min, max and step
> >> values.  the change in the alsa core wouldn't be too much.
> > 
> > I think that we simply touch the barrier given by 'struct
> > sndrv_ctl_elem_id'. The identification which differentiate identical
> > controls is only the 'index' value. If we don't use 'struct
> > sndrv_ctl_elem_id' as the identification unit for read/writing of data,
> > then we end with trouble with notification and other representation
> > (single data unit locking, inactive flag etc). Imagine three or four
> > dimensional data types. [...]
> 
> .count is an uint32. Ok, suppose we do not change it. Then the low
> level driver has to tell user space apps that the index number
> addresses elements in a W*H matrix, so the apps will locate the
> cell at (x,y) by a simple index=x+W*y.
> 
> 
> Bye.
> 
> 
> 
> -------------------------------------------------------
> 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/
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

-- 
http://mffm.darktech.org

WSOLA TimeScale Audio Mod  : http://mffmtimescale.sourceforge.net/
FFTw C++                   : http://mffmfftwrapper.sourceforge.net/
Vector Bass                : http://mffmvectorbass.sourceforge.net/
Multimedia Time Code       : http://mffmtimecode.sourceforge.net/


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

Re: matrix mixer control (Re: Complex mixer questio

[Justin Cormack]

On Mon, 2003-03-31 at 15:45, Matt Flax wrote:
> I think this is a great step forward ... it will open the door for 3D 
> array audio applications.
> Typically these applications use 3D speaker arrays which each have 
> individual gains set for each audio 'object'.
> Consequently depending on an audio object's location in 3D space, will 
> depend on the relative speaker gains for that particular audio object.
> 
> Consequently each audio object has its own mixer matrix. There is also a 
> master mixer matrix for calibration - this generally occurs when you 
> have external amplifiers which are different or not calibrated.

You can already do this with the hdsp matrix mixer (in fact I have with
8 speakers). Each channel has a mixer level for each speaker. For hdsp
you get 26 playback channels, ie 26 objects (plus the capture channels
too).

The thread is just about whether to tidy up the way the interface is
exposed.

Justin




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

Re: matrix mixer control (Re: Complex mixer questio

[Paul Davis]

>I think this is a great step forward ... it will open the door for 3D 
>array audio applications.
>Typically these applications use 3D speaker arrays which each have 
>individual gains set for each audio 'object'.
>Consequently depending on an audio object's location in 3D space, will 
>depend on the relative speaker gains for that particular audio object.
>
>Consequently each audio object has its own mixer matrix. There is also a 
>master mixer matrix for calibration - this generally occurs when you 
>have external amplifiers which are different or not calibrated.

actually, i think that this has almost nothing to do with 3d array
audio applications, because the code to do that generally runs in user
space.

the question under discussion concerns the control of hardware that
has matrix control elements, of which there are only 2 known at this
time. 

you could do 3d array audio stuff with many consumer cards entirely
within the application code. perhaps i misunderstood your point
entirely. 

--p


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

Re: matrix mixer control (Re: Complex mixer questio

[Abramo Bagnara]

Paul Davis ha scritto:
>>Ortogonally to that, IMO the increasing numbers of controls in modern 
>>professional hardware justify the choice of hash table access to 
>>controls (try to imagine a 26 channel hardware level meter that need to 
>>be polled 50 times per second).
> 
> 
> TotalMix for the HDSP will not do that. Thomas is working on mapping
> the meters into user space. Its not reasonable to do this via system
> calls if you want to access them in an RT thread. As a fill-in measure
> until that is done, I think he created a control that gets all the
> values in a single system call.

This open a more general problem for generic mmap support for controls, 
but I think this is postponible.

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

Re: matrix mixer control (Re: Complex mixer questio

[Paul Davis]

>Paul Davis ha scritto:
>>>Ortogonally to that, IMO the increasing numbers of controls in modern 
>>>professional hardware justify the choice of hash table access to 
>>>controls (try to imagine a 26 channel hardware level meter that need to 
>>>be polled 50 times per second).
>> 
>> 
>> TotalMix for the HDSP will not do that. Thomas is working on mapping
>> the meters into user space. Its not reasonable to do this via system
>> calls if you want to access them in an RT thread. As a fill-in measure
>> until that is done, I think he created a control that gets all the
>> values in a single system call.
>
>This open a more general problem for generic mmap support for controls, 
>but I think this is postponible.

or even just forgettable. i think that attempts to generalize this
stuff can go too far. whether this would be too far, i don't know.



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