maximum voices/channels

maximum voices/channels

[Cesar Hernandez]

Hi.

I have a question on using alsa sequencer. I am working on a kind of
piano program, and I want to know what is the maximum number of notes or
sampled voices (mapped to a note) that I can play at the same time...
I know that two or three notes may sound at the same sequencer channel,
but I don't know what is the maximum. 
Is there a maximum number of voices/notes per sequencer channel? Or it's
a maximum number counting all the channels...? Or it depends on the midi
output (timidity, midi keyboard...)

Thanks


-- 
Cesar Hernandez
chernandez@genos.es
Genos Open Source S.L.


http://genos.es
http://www.genos.org



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Volume per voices

[Dino]

Hi there,
   i'm looking for setting a volume per voice(pcm stream) but it seems to be
impossible. I've found only a plugin to do it in software but i'd like to do it
in Hardware. Is it a feature not supported by alsa? If so, can i open a feature
request? I think it's an easy thing to do and even if a sound card couldn't do
it  a simple multiplication in software does the job.

tnx,
   Dino Puller


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

Re: Volume per voices

[Clemens Ladisch]

Dino wrote:
>    i'm looking for setting a volume per voice(pcm stream) but it seems to be
> impossible. I've found only a plugin to do it in software but i'd like to do it
> in Hardware. Is it a feature not supported by alsa?

The Emu10k1 and VIA82xxx drivers have volume controls for each
hardware PCM stream.  Most other hardware cannot do this.


HTH
Clemens



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices

[Dino Puller]

Clemens Ladisch wrote:

>Dino wrote:
>  
>
>>   i'm looking for setting a volume per voice(pcm stream) but it seems to be
>>impossible. I've found only a plugin to do it in software but i'd like to do it
>>in Hardware. Is it a feature not supported by alsa?
>>    
>>
>
>The Emu10k1 and VIA82xxx drivers have volume controls for each
>hardware PCM stream.  Most other hardware cannot do this.
>  
>
But with emu10k1 or via82xxx can i access to volume controls in a 
standard manner provided by alsa? If so is it only a lack of some 
drivers? How can i know if my device supports this volume control?

tnx,
    Dino Puller

>
>HTH
>Clemens
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Alsa-devel mailing list
>Alsa-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/alsa-devel
>
>  
>



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices

[Clemens Ladisch]

Dino Puller wrote:

> Clemens Ladisch wrote:
>
> >The Emu10k1 and VIA82xxx drivers have volume controls for each
> >hardware PCM stream.  Most other hardware cannot do this.
>
> But with emu10k1 or via82xxx can i access to volume controls in a
> standard manner provided by alsa?

You can access them like any other mixer control.

There is no ALSA function to map from a PCM stream to this control.

> How can i know if my device supports this volume control?

Check if you're running with these drivers.

There should be a common API for all hardware/software mixing
implementations, but currently there isn't.


Regards,
Clemens



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Volume per voices [Feature Request]

[Dino Puller]

Hi all,
    i don't know if this is the right place to ask for a new feature, 
BTW here it is:
It's should be very useful to have a standard way/function to map volume 
per PCM stream. For now seems that only emu10k1 and via82xxx has a 
volume control for each PCM streams, probably because a lack on the 
others drivers. Where the HW/driver doesn't support this control, it's 
should be emulated via software.

Thanks,
    Dino Puller



Clemens Ladisch wrote:

>Dino Puller wrote:
>
>  
>
>>Clemens Ladisch wrote:
>>
>>    
>>
>>>The Emu10k1 and VIA82xxx drivers have volume controls for each
>>>hardware PCM stream.  Most other hardware cannot do this.
>>>      
>>>
>>But with emu10k1 or via82xxx can i access to volume controls in a
>>standard manner provided by alsa?
>>    
>>
>
>You can access them like any other mixer control.
>
>There is no ALSA function to map from a PCM stream to this control.
>
>  
>
>>How can i know if my device supports this volume control?
>>    
>>
>
>Check if you're running with these drivers.
>
>There should be a common API for all hardware/software mixing
>implementations, but currently there isn't.
>
>
>Regards,
>Clemens
>
>
>  
>



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

RE: Volume per voices [Feature Request]

[Giuliano Pochini]

On 26-Jul-2005 Dino Puller wrote:
> Hi all,
>     i don't know if this is the right place to ask for a new feature,
> BTW here it is:
> It's should be very useful to have a standard way/function to map volume
> per PCM stream. For now seems that only emu10k1 and via82xxx has a
> volume control for each PCM streams, probably because a lack on the
> others drivers. Where the HW/driver doesn't support this control, it's
> should be emulated via software.

Most cards have hw volume, but ALSA cannot answer this simple question:
given this PCM handle, what numid:index control controls the gain of its
Nth channel ?
That question is not as simple as it may seem at first glance. The ctl
may not exist at all if the cards do not support it or if the PCM is
not an hardware PCM (eg. is uses dmix). Even if the card has a simple
1:1 relation between a PCM device and an hw control, some plugins (route,
multi or any combination of any plugins) may have shuffled things...


--
Giuliano.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Clemens Ladisch]

Giuliano Pochini wrote:
> On 26-Jul-2005 Dino Puller wrote:
> > It's should be very useful to have a standard way/function to map volume
> > per PCM stream. For now seems that only emu10k1 and via82xxx has a
> > volume control for each PCM streams, probably because a lack on the
> > others drivers. Where the HW/driver doesn't support this control, it's
> > should be emulated via software.
>
> Most cards have hw volume, but ALSA cannot answer this simple question:
> given this PCM handle, what numid:index control controls the gain of its
> Nth channel ?

But it would be very easy for the driver to answer this question, and
to extend ALSA accordingly.

> That question is not as simple as it may seem at first glance. The ctl
> may not exist at all if the cards do not support it

The ALSA library could add a software volume plugin in this case.

> or if the PCM is not an hardware PCM (eg. is uses dmix). Even if
> the card has a simple 1:1 relation between a PCM device and an hw
> control, some plugins (route, multi or any combination of any
> plugins) may have shuffled things...

These plugins would pass through the information from the slave
plugin, if appropriate.  If not, we have the same case as when there
is no hardware control.


Regards,
Clemens



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Jaroslav Kysela]

On Wed, 27 Jul 2005, Clemens Ladisch wrote:

> Giuliano Pochini wrote:
> > On 26-Jul-2005 Dino Puller wrote:
> > > It's should be very useful to have a standard way/function to map volume
> > > per PCM stream. For now seems that only emu10k1 and via82xxx has a
> > > volume control for each PCM streams, probably because a lack on the
> > > others drivers. Where the HW/driver doesn't support this control, it's
> > > should be emulated via software.
> >
> > Most cards have hw volume, but ALSA cannot answer this simple question:
> > given this PCM handle, what numid:index control controls the gain of its
> > Nth channel ?
> 
> But it would be very easy for the driver to answer this question, and
> to extend ALSA accordingly.

It's not necessary. The alsa-lib can do it, but having consistent control 
names in driver is not a bad idea, too.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Wed, 27 Jul 2005 10:23:42 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 27 Jul 2005, Clemens Ladisch wrote:
> 
> > Giuliano Pochini wrote:
> > > On 26-Jul-2005 Dino Puller wrote:
> > > > It's should be very useful to have a standard way/function to map volume
> > > > per PCM stream. For now seems that only emu10k1 and via82xxx has a
> > > > volume control for each PCM streams, probably because a lack on the
> > > > others drivers. Where the HW/driver doesn't support this control, it's
> > > > should be emulated via software.
> > >
> > > Most cards have hw volume, but ALSA cannot answer this simple question:
> > > given this PCM handle, what numid:index control controls the gain of its
> > > Nth channel ?
> > 
> > But it would be very easy for the driver to answer this question, and
> > to extend ALSA accordingly.
> 
> It's not necessary. The alsa-lib can do it, but having consistent control 
> names in driver is not a bad idea, too.

The problem is that it's not clearly defined how to find the bound
control for the currently opened pcm.  We may assume that the index
number corresponds to the substream index, but this may be different
on drivers.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Wed, 27 Jul 2005 10:30:36 +0200,
I wrote:
> 
> At Wed, 27 Jul 2005 10:23:42 +0200 (CEST),
> Jaroslav wrote:
> > 
> > On Wed, 27 Jul 2005, Clemens Ladisch wrote:
> > 
> > > Giuliano Pochini wrote:
> > > > On 26-Jul-2005 Dino Puller wrote:
> > > > > It's should be very useful to have a standard way/function to map volume
> > > > > per PCM stream. For now seems that only emu10k1 and via82xxx has a
> > > > > volume control for each PCM streams, probably because a lack on the
> > > > > others drivers. Where the HW/driver doesn't support this control, it's
> > > > > should be emulated via software.
> > > >
> > > > Most cards have hw volume, but ALSA cannot answer this simple question:
> > > > given this PCM handle, what numid:index control controls the gain of its
> > > > Nth channel ?
> > > 
> > > But it would be very easy for the driver to answer this question, and
> > > to extend ALSA accordingly.
> > 
> > It's not necessary. The alsa-lib can do it, but having consistent control 
> > names in driver is not a bad idea, too.
> 
> The problem is that it's not clearly defined how to find the bound
> control for the currently opened pcm.  We may assume that the index
> number corresponds to the substream index, but this may be different
> on drivers.

Well, I mean, we have no API for providing this information.
Not only PCM but other controls (e.g. effects like chorus/reverb)
would be bound to a PCM voice, so only defining consistent control
names wouldn't suffice.

I believe PCM iface attribute could be used for such a purpose, but
unfortunately, the situation is confusing.  Some drivers already use
PCM iface for different purposes (e.g. hdsp) and some use mixer iface
for exactly this purpose (e.g. emu10k1)...


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Clemens Ladisch]

Takashi Iwai wrote:

> At Wed, 27 Jul 2005 10:30:36 +0200,
> I wrote:
> >
> > The problem is that it's not clearly defined how to find the bound
> > control for the currently opened pcm.  We may assume that the index
> > number corresponds to the substream index, but this may be different
> > on drivers.
>
> Well, I mean, we have no API for providing this information.
> Not only PCM but other controls (e.g. effects like chorus/reverb)
> would be bound to a PCM voice, so only defining consistent control
> names wouldn't suffice.
>
> I believe PCM iface attribute could be used for such a purpose,

As far as I see, the iface/device/subdevice fields were designed for
exactly this purpose, i.e., associating a control with a specific
(sub)device.

> but unfortunately, the situation is confusing.  Some drivers
> already use PCM iface for different purposes (e.g. hdsp) and some
> use mixer iface for exactly this purpose (e.g. emu10k1)...

Then I'd consider these drivers buggy.

I'll write a patch unless anybody objects ...


Regards,
Clemens



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Wed, 27 Jul 2005 17:21:33 +0200 (METDST),
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> 
> > At Wed, 27 Jul 2005 10:30:36 +0200,
> > I wrote:
> > >
> > > The problem is that it's not clearly defined how to find the bound
> > > control for the currently opened pcm.  We may assume that the index
> > > number corresponds to the substream index, but this may be different
> > > on drivers.
> >
> > Well, I mean, we have no API for providing this information.
> > Not only PCM but other controls (e.g. effects like chorus/reverb)
> > would be bound to a PCM voice, so only defining consistent control
> > names wouldn't suffice.
> >
> > I believe PCM iface attribute could be used for such a purpose,
> 
> As far as I see, the iface/device/subdevice fields were designed for
> exactly this purpose, i.e., associating a control with a specific
> (sub)device.
> 
> > but unfortunately, the situation is confusing.  Some drivers
> > already use PCM iface for different purposes (e.g. hdsp) and some
> > use mixer iface for exactly this purpose (e.g. emu10k1)...
> 
> Then I'd consider these drivers buggy.
> 
> I'll write a patch unless anybody objects ...

Basically I agree with fixing this mess.

The only concern is the backward compatibility.  Especially, apps
specific to hdsp assume that the controls have PCM iface.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Clemens Ladisch]

Takashi Iwai wrote:

> Clemens Ladisch wrote:
> >
> > Takashi Iwai wrote:
> >
> > > but unfortunately, the situation is confusing.  Some drivers
> > > already use PCM iface for different purposes (e.g. hdsp) and some
> > > use mixer iface for exactly this purpose (e.g. emu10k1)...
> >
> > Then I'd consider these drivers buggy.
> >
> > I'll write a patch unless anybody objects ...
>
> Basically I agree with fixing this mess.
>
> The only concern is the backward compatibility.  Especially, apps
> specific to hdsp assume that the controls have PCM iface.

As long as those apps are part of the alsa-tools package, we can
change them, too.

It seems hdspmixer uses both .numid and all other fields of the
control ID to select controls.  This needs to be changed anyway ...


Regards,
Clemens



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Thu, 28 Jul 2005 09:25:57 +0200 (METDST),
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> 
> > Clemens Ladisch wrote:
> > >
> > > Takashi Iwai wrote:
> > >
> > > > but unfortunately, the situation is confusing.  Some drivers
> > > > already use PCM iface for different purposes (e.g. hdsp) and some
> > > > use mixer iface for exactly this purpose (e.g. emu10k1)...
> > >
> > > Then I'd consider these drivers buggy.
> > >
> > > I'll write a patch unless anybody objects ...
> >
> > Basically I agree with fixing this mess.
> >
> > The only concern is the backward compatibility.  Especially, apps
> > specific to hdsp assume that the controls have PCM iface.
> 
> As long as those apps are part of the alsa-tools package, we can
> change them, too.
> 
> It seems hdspmixer uses both .numid and all other fields of the
> control ID to select controls.  This needs to be changed anyway ...

In addition, we have hook elements in card configurations.
For example, EMU10K1.conf accesse "EMU10K1 PCM *" controls.
Looks like we need to fix them, too.


BTW, I found your changes around IEC958 controls.  Shall we handle
"IEC958 Playback Default" as PCM or mixer?
"IEC958 Playback PCM Stream" is certainly bound to a PCM but the
former isn't.  Anyway, let's sort out these messes, too.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Clemens Ladisch]

Takashi Iwai wrote:
> BTW, I found your changes around IEC958 controls.  Shall we handle
> "IEC958 Playback Default" as PCM or mixer?

I made those controls PCM where the SPDIF output can be directly
accessed as a separate stream, i.e., where the control affects the
data (and _only_ the data) sent through this stream.


Regards,
Clemens



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Mon, 1 Aug 2005 17:29:48 +0200 (METDST),
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> > BTW, I found your changes around IEC958 controls.  Shall we handle
> > "IEC958 Playback Default" as PCM or mixer?
> 
> I made those controls PCM where the SPDIF output can be directly
> accessed as a separate stream, i.e., where the control affects the
> data (and _only_ the data) sent through this stream.

IMO, the type should be consistent.  "IEC958 Playback Default" and
"IEC958 Playback PCM Stream" should belong definitely to IFACE_PCM.
(So "* Mask", too.)  They don't need to be accessed through "mixer".
It's purpose is just for the PCM.  So, converting them all to
IFACE_PCM would be better.

Meanwhile, "IEC958 Playback Switch" would be a mixer element, since
this can be a control that user wants to change on the fly.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Clemens Ladisch]

Takashi Iwai wrote:
> Clemens Ladisch wrote:
> > Takashi Iwai wrote:
> > > BTW, I found your changes around IEC958 controls.  Shall we handle
> > > "IEC958 Playback Default" as PCM or mixer?
> >
> > I made those controls PCM where the SPDIF output can be directly
> > accessed as a separate stream, i.e., where the control affects the
> > data (and _only_ the data) sent through this stream.
>
> IMO, the type should be consistent.  "IEC958 Playback Default" and
> "IEC958 Playback PCM Stream" should belong definitely to IFACE_PCM.
> (So "* Mask", too.)  They don't need to be accessed through "mixer".
> It's purpose is just for the PCM.  So, converting them all to
> IFACE_PCM would be better.

But what device should those controls use when there is more than one
stream that can send data to the SPDIF output, or when there is none?


Regards,
Clemens



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Tue, 2 Aug 2005 16:13:08 +0200 (METDST),
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> > Clemens Ladisch wrote:
> > > Takashi Iwai wrote:
> > > > BTW, I found your changes around IEC958 controls.  Shall we handle
> > > > "IEC958 Playback Default" as PCM or mixer?
> > >
> > > I made those controls PCM where the SPDIF output can be directly
> > > accessed as a separate stream, i.e., where the control affects the
> > > data (and _only_ the data) sent through this stream.
> >
> > IMO, the type should be consistent.  "IEC958 Playback Default" and
> > "IEC958 Playback PCM Stream" should belong definitely to IFACE_PCM.
> > (So "* Mask", too.)  They don't need to be accessed through "mixer".
> > It's purpose is just for the PCM.  So, converting them all to
> > IFACE_PCM would be better.
> 
> But what device should those controls use when there is more than one
> stream that can send data to the SPDIF output, or when there is none?

Good point.

I still believe they should belong to PCM iface.  Think the purpose of
these controls.

The problem is that the binding rule between a control and a PCM
stream using device/subdevice seems inssuficient for such cases.

For solving this kind of problem, I'm considering to add a extended
attribute to each control.  It can contain atribtrary additional
information, for example, dB range of a volume control, or a list of
corresponding PCM streams.  The kernel API should be as simple as
possible (just get/set via ioctl), the rest parse will be done in
user-space.

But, even before this addition (if we really do), I think it's worthy
to move iface to PCM since it will clean up the mixer mess a bit.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Lee Revell]

On Tue, 2005-08-02 at 17:51 +0200, Takashi Iwai wrote:
> But, even before this addition (if we really do), I think it's worthy
> to move iface to PCM since it will clean up the mixer mess a bit.

The multichannel playback controls are already IFACE_PCM, do they need
any update to match this API change (which I have not been following
closely)?

Lee



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Tue, 02 Aug 2005 12:00:38 -0400,
Lee Revell wrote:
> 
> On Tue, 2005-08-02 at 17:51 +0200, Takashi Iwai wrote:
> > But, even before this addition (if we really do), I think it's worthy
> > to move iface to PCM since it will clean up the mixer mess a bit.
> 
> The multichannel playback controls are already IFACE_PCM, do they need
> any update to match this API change (which I have not been following
> closely)?

No, then it's OK :)


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Giuliano Pochini]

On Wed, 27 Jul 2005, Clemens Ladisch wrote:

> > Well, I mean, we have no API for providing this information.
> > Not only PCM but other controls (e.g. effects like chorus/reverb)
> > would be bound to a PCM voice, so only defining consistent control
> > names wouldn't suffice.
> >
> > I believe PCM iface attribute could be used for such a purpose,
>
> As far as I see, the iface/device/subdevice fields were designed for
> exactly this purpose, i.e., associating a control with a specific
> (sub)device.

How do they work ?


> > but unfortunately, the situation is confusing.  Some drivers
> > already use PCM iface for different purposes (e.g. hdsp) and some
> > use mixer iface for exactly this purpose (e.g. emu10k1)...
>
> Then I'd consider these drivers buggy.
>
> I'll write a patch unless anybody objects ...

The tutorial says nothing about control names, interfaces and their
arrangement and expecially how they are meant to be sorted out. In my
driver we have A analog channels and D digital channels. The driver
registers a "PCM Playback Volume" control as an array of A+D integers,
where each element is the gain (-128..+6) of each channel, but they don't
map directly to the PCM channels because the driver exports analog and
digital channels as two separate devices (this feature can be removed
easily). So pcmvol[0..A-1] controls the volume of hw:0,0 and
pcmvol[A..A+D-1] controls the volume of hw:0,1. Furthermore, the user
can open hw:0,0,x to address the xth channel.
The driver also has other controls that are quite hw-specific and I don't
think a generic application would be able to use them. Those controls are
not a problem, because I wrote echomixer to manage them. It is important
that apps can access basic controls, though.

If the way I arranged things is wrong, let me know...


--
Giuliano.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Clemens Ladisch]

Giuliano Pochini wrote:
>
> On Wed, 27 Jul 2005, Clemens Ladisch wrote:
>
> > As far as I see, the iface/device/subdevice fields were designed for
> > exactly this purpose, i.e., associating a control with a specific
> > (sub)device.
>
> How do they work ?

Set iface to the type of the ALSA device (HWDEP, PCM, RAWMIDI, TIMER,
SEQUENCER), and set device/subdevice to the device/subdevice numbers
(or device/substream numbers for PCM).

> The tutorial says nothing about control names, interfaces and their
> arrangement and expecially how they are meant to be sorted out.

This may be the reason why the drivers don't use these fields in any
consistent manner ...

> In my driver we have A analog channels and D digital channels. The
> driver registers a "PCM Playback Volume" control as an array of
> A+D integers, where each element is the gain (-128..+6) of each
> channel, but they don't map directly to the PCM channels because
> the driver exports analog and digital channels as two separate
> devices (this feature can be removed easily). So pcmvol[0..A-1]
> controls the volume of hw:0,0 and pcmvol[A..A+D-1] controls the
> volume of hw:0,1. Furthermore, the user can open hw:0,0,x to
> address the xth channel.

As far as I can see, no driver actually uses the subdevice (substream)
field for PCM substreams; probably because this would require a
separate control for each substream instead of using an array.

> The driver also has other controls that are quite hw-specific and
> I don't think a generic application would be able to use them.
> Those controls are not a problem, because I wrote echomixer to
> manage them. It is important that apps can access basic controls,
> though.

alsamixer shows only controls with MIXER interface.


Regards,
Clemens



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Jaroslav Kysela]

On Thu, 28 Jul 2005, Clemens Ladisch wrote:

> As far as I can see, no driver actually uses the subdevice (substream)
> field for PCM substreams; probably because this would require a
> separate control for each substream instead of using an array.

See emu10k1, trident .... They define controls in this way, but the 
interface is set to MIXER (and should be really changed to PCM).

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Thu, 28 Jul 2005 10:32:33 +0200 (CEST),
Jaroslav wrote:
> 
> On Thu, 28 Jul 2005, Clemens Ladisch wrote:
> 
> > As far as I can see, no driver actually uses the subdevice (substream)
> > field for PCM substreams; probably because this would require a
> > separate control for each substream instead of using an array.
> 
> See emu10k1, trident .... They define controls in this way, but the 
> interface is set to MIXER (and should be really changed to PCM).

IIRC, they use the index field, not subdevice.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Clemens Ladisch]

Takashi Iwai wrote:

> Jaroslav wrote:
> >
> > On Thu, 28 Jul 2005, Clemens Ladisch wrote:
> >
> > > As far as I can see, no driver actually uses the subdevice (substream)
> > > field for PCM substreams; probably because this would require a
> > > separate control for each substream instead of using an array.
> >
> > See emu10k1, trident .... They define controls in this way, but the
> > interface is set to MIXER (and should be really changed to PCM).
>
> IIRC, they use the index field, not subdevice.

A quick grep shows that the i2c drivers are the only ones to set the
subdevice field.

Shouldn't the other drivers be changed to use separate controls with
appropriate subdevice fields, instead of having .count > 0 ?


Regards,
Clemens



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Jaroslav Kysela]

On Thu, 28 Jul 2005, Takashi Iwai wrote:

> At Thu, 28 Jul 2005 10:32:33 +0200 (CEST),
> Jaroslav wrote:
> > 
> > On Thu, 28 Jul 2005, Clemens Ladisch wrote:
> > 
> > > As far as I can see, no driver actually uses the subdevice (substream)
> > > field for PCM substreams; probably because this would require a
> > > separate control for each substream instead of using an array.
> > 
> > See emu10k1, trident .... They define controls in this way, but the 
> > interface is set to MIXER (and should be really changed to PCM).
> 
> IIRC, they use the index field, not subdevice.

Yep, sorry. Of course, it's time to change (and add a new flag for 
snd_ctl_new1() which will change semantics for snd_kcontrol_new_t->count 
member from index to subdevice).

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Dino]

Hi,
   i'm glad about this interest over this feature. Now i have only a
question(probably a stupid question): Will be there a problem for a >=
surround40 device?

tnx,
   Dino


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Raymond]

In case of au8830, mono, stereo or quad PCM stream are pass through the 
hardware mixer to the stereo/quad AC97 codec (only front channels will 
pass through the equalizer before it go to AC97 codec)

This means the proposed volume control will have 2/4 values depend on 
the stereo/quad codec on au8830.

The rear speaker of Quadzilla/Home Studio - the addon cards of Turtle 
Beach Montego II is not yet supported.

1) front and rear speakers (Surround40) or
2) 2 speakers and 1 headphone or
3) 2 speakers or
4) 1 headphone

http://www.3dgw.com/hardware/soundcards/msmx300/index.php3

One nifty thing about the MX300 control panel is that it recognizes 
automatically what you have plugged into the Line Out's (speakers or 
headphones)

I think the alsa application need to ask the user for the 
speaker/headphone configuration if it want to support Surround40.


Dino wrote:
> Hi,
>    i'm glad about this interest over this feature. Now i have only a
> question(probably a stupid question): Will be there a problem for a >=
> surround40 device?
> 
> tnx,
>    Dino
> 




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Giuliano Pochini]

On Thu, 28 Jul 2005, Clemens Ladisch wrote:

> Giuliano Pochini wrote:
> >
> > On Wed, 27 Jul 2005, Clemens Ladisch wrote:
> >
> > > As far as I see, the iface/device/subdevice fields were designed for
> > > exactly this purpose, i.e., associating a control with a specific
> > > (sub)device.
> >
> > How do they work ?
>
> Set iface to the type of the ALSA device (HWDEP, PCM, RAWMIDI, TIMER,
> SEQUENCER), and set device/subdevice to the device/subdevice numbers
> (or device/substream numbers for PCM).

Nope, I can't make them match.


> > In my driver we have A analog channels and D digital channels. The
> > driver registers a "PCM Playback Volume" control as an array of
> > A+D integers, where each element is the gain (-128..+6) of each
> > channel, but they don't map directly to the PCM channels because
> > the driver exports analog and digital channels as two separate
> > devices (this feature can be removed easily). So pcmvol[0..A-1]
> > controls the volume of hw:0,0 and pcmvol[A..A+D-1] controls the
> > volume of hw:0,1. Furthermore, the user can open hw:0,0,x to
> > address the xth channel.
>
> As far as I can see, no driver actually uses the subdevice (substream)
> field for PCM substreams; probably because this would require a
> separate control for each substream instead of using an array.

My case is even more compicated because one ctl controls the volume of two
devices. A callback that gets snd_pcm_substream_t* and returns {int numid,
firstindex, lastindex} or sort of would make things much simpler wrt hw
controls. In case there are both hw volume and softvol, which has
priority ? :)
Without that callback, I perhaps can make it work splitting those controls
or merging the pcm devices. The former is better. It would not work
anyway if the user opens a subdevice !=0 (quite rare case).


> > The driver also has other controls that are quite hw-specific and
> > I don't think a generic application would be able to use them.
> > Those controls are not a problem, because I wrote echomixer to
> > manage them. It is important that apps can access basic controls,
> > though.
>
> alsamixer shows only controls with MIXER interface.

I was talking eg. about vmixer (mixes n PCM "voices" to m outputs) and
monitor mixer (mixes n inputs to m outputs). I don't think we should worry
about such complex controls.


--
Giuliano.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Thu, 28 Jul 2005 19:51:16 +0200 (CEST),
Giuliano Pochini wrote:
> 
> > > In my driver we have A analog channels and D digital channels. The
> > > driver registers a "PCM Playback Volume" control as an array of
> > > A+D integers, where each element is the gain (-128..+6) of each
> > > channel, but they don't map directly to the PCM channels because
> > > the driver exports analog and digital channels as two separate
> > > devices (this feature can be removed easily). So pcmvol[0..A-1]
> > > controls the volume of hw:0,0 and pcmvol[A..A+D-1] controls the
> > > volume of hw:0,1. Furthermore, the user can open hw:0,0,x to
> > > address the xth channel.
> >
> > As far as I can see, no driver actually uses the subdevice (substream)
> > field for PCM substreams; probably because this would require a
> > separate control for each substream instead of using an array.
> 
> My case is even more compicated because one ctl controls the volume of two
> devices. A callback that gets snd_pcm_substream_t* and returns {int numid,
> firstindex, lastindex} or sort of would make things much simpler wrt hw
> controls. In case there are both hw volume and softvol, which has
> priority ? :)

Returning a list of controls would be simplest as the lowlevel API.
The higher level API decides which control to use, for example,  while
h/w specific apps can use the lowlevel API to get certain controls
directly.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Raymond]

Takashi Iwai wrote:
> At Thu, 28 Jul 2005 19:51:16 +0200 (CEST),
> Giuliano Pochini wrote:
> 
>>>>In my driver we have A analog channels and D digital channels. The
>>>>driver registers a "PCM Playback Volume" control as an array of
>>>>A+D integers, where each element is the gain (-128..+6) of each
>>>>channel, but they don't map directly to the PCM channels because
>>>>the driver exports analog and digital channels as two separate
>>>>devices (this feature can be removed easily). So pcmvol[0..A-1]
>>>>controls the volume of hw:0,0 and pcmvol[A..A+D-1] controls the
>>>>volume of hw:0,1. Furthermore, the user can open hw:0,0,x to
>>>>address the xth channel.
>>>
>>>As far as I can see, no driver actually uses the subdevice (substream)
>>>field for PCM substreams; probably because this would require a
>>>separate control for each substream instead of using an array.
>>
>>My case is even more compicated because one ctl controls the volume of two
>>devices. A callback that gets snd_pcm_substream_t* and returns {int numid,
>>firstindex, lastindex} or sort of would make things much simpler wrt hw
>>controls. In case there are both hw volume and softvol, which has
>>priority ? :)
> 
> 
> Returning a list of controls would be simplest as the lowlevel API.
> The higher level API decides which control to use, for example,  while
> h/w specific apps can use the lowlevel API to get certain controls
> directly.
> 
> 

For those controls with SNDRV_CTL_ELEM_IFACE_PCM , ctl->id.device and 
ctl->id.subdevice.

Is it feasible to have a function which return snd_pcm_substream_t* of 
the PCM substream with parameters (snd_kcontrol_t *kcontrol, int device 
,int subdevice)  ?

The topology which the hardware mixers are connected depends on the 
number of channels (mono,stereo,quad,..) of the PCM substream




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Raymond]

In theory, and sound cards with hardware mixing can support this kind of
volume control.

au88x0 driver may provide this kind of volume control on playing PCM
streams by using hardware mixers.

However the hardware mixers are dynamically allocated in routine
snd_vortex_pcm_hw_params(), this means that the kcontrol can be put/get
only between snd_pcm_hw_params() (return no error) and
snd_pcm_hw_free()/snd_pcm_close().

Is there any flag in kcontrol which enable/disable the put/get from
mixer application ?

How do the alsa mixer application get notification when a PCM stream is
play by another alsa application ?

May be the volume controls can only be accessed by the alsa application
which open the PCM stream. (e.g. The hardware acclerated version of
openal http://www.lost.org.uk/openal.html or sound mixing/recording
application )

Is there any limitation of ctlid if the kcontrol is dynamically created
on snd_vortex_pcm_hw_params() and deleted on snd_vortex_pcm_hw_free() ?

There is no need for alsactl to store/restore the values of these kind
of volume controls.

Clemens Ladisch wrote:
> Takashi Iwai wrote:
> 
> 
>>At Wed, 27 Jul 2005 10:30:36 +0200,
>>I wrote:
>>
>>>The problem is that it's not clearly defined how to find the bound
>>>control for the currently opened pcm.  We may assume that the index
>>>number corresponds to the substream index, but this may be different
>>>on drivers.
>>
>>Well, I mean, we have no API for providing this information.
>>Not only PCM but other controls (e.g. effects like chorus/reverb)
>>would be bound to a PCM voice, so only defining consistent control
>>names wouldn't suffice.
>>
>>I believe PCM iface attribute could be used for such a purpose,
> 
> 
> As far as I see, the iface/device/subdevice fields were designed for
> exactly this purpose, i.e., associating a control with a specific
> (sub)device.
> 
> 
>>but unfortunately, the situation is confusing.  Some drivers
>>already use PCM iface for different purposes (e.g. hdsp) and some
>>use mixer iface for exactly this purpose (e.g. emu10k1)...
> 
> 
> Then I'd consider these drivers buggy.
> 
> I'll write a patch unless anybody objects ...
> 
> 


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Volume per voices [Feature Request]

[Clemens Ladisch]

Raymond wrote:
> In theory, and sound cards with hardware mixing can support this kind of
> volume control.
>
> au88x0 driver may provide this kind of volume control on playing PCM
> streams by using hardware mixers.
>
> However the hardware mixers are dynamically allocated in routine
> snd_vortex_pcm_hw_params(), this means that the kcontrol can be put/get
> only between snd_pcm_hw_params() (return no error) and
> snd_pcm_hw_free()/snd_pcm_close().

The driver could save the value and apply it when a stream is opened.

> Is there any flag in kcontrol which enable/disable the put/get from
> mixer application ?

Controls can be locked.

> How do the alsa mixer application get notification when a PCM stream is
> play by another alsa application ?

There are notifications when the control status changes, or when
controls are added/deleted.  (But I don't think these controls should
be added dynamically; it would be useful to know that they exist
before a PCM substream is opened.)

> There is no need for alsactl to store/restore the values of these kind
> of volume controls.

Indeed.  Most applications just get the first free substream.
Allowing the user to change 16 (or 32) different volume controls just
doesn't make sense in this context.


Regards,
Clemens



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [Openvortex-dev] Re: Re: Volume per voices [Feature Request]

[Maarten Vanraes]

> Raymond wrote:
>> There is no need for alsactl to store/restore the values of these kind
>> of volume controls.
>
> Indeed.  Most applications just get the first free substream.
> Allowing the user to change 16 (or 32) different volume controls just
> doesn't make sense in this context.

maybe an application should only change it's own volume control (not the
master volume control); if there is no such thing, it can make it in
software.

but! shouldn't it also be possible to make an application that can change
all these volume controls? like a switchboard or something?


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [Openvortex-dev] Re: Re: Volume per voices [Feature Request]

[Alien]

> Hi,
>
> On 7/28/05, Maarten Vanraes <maarten.vanraes@telenet.be> wrote:
>> > Raymond wrote:
>> >> There is no need for alsactl to store/restore the values of these
>> kind
>> >> of volume controls.
>> >
>> > Indeed.  Most applications just get the first free substream.
>> > Allowing the user to change 16 (or 32) different volume controls just
>> > doesn't make sense in this context.
>>
>> maybe an application should only change it's own volume control (not the
>> master volume control); if there is no such thing, it can make it in
>> software.
>
> I totally agree with that. Such a interface should handle not only
> volume (gain) IMHO. There are many other caracteristics that would be
> "very" interesting to make available to applications. Hopefuly one
> should be able to do gain or whatever settings using the PCM device
> handle, without requiring to figure out control names. Just like
> setting hwparams, but something that is possible to do in while the
> PCM device is running. By the way, why cant hwparams be set while the
> PCM device is running ? Many cards support changing samplerate and
> such while running (doppler effect simulation).
>
>> but! shouldn't it also be possible to make an application that can
>> change
>> all these volume controls? like a switchboard or something?
>
> There is a problem with that, because you never know, which
> application is using which subdevice. Even if you know that, many
> application open the PCM device just for the amount of time required
> to do playback/recording. That means that you wont be fast enough
> trying to catch a gain setting with your mouse or keyboard. And for
> the next time a application makes use of a PCM device, it could be a
> different one, and the question arrises, how do you remember the
> setting of a application on a specific device ?
>
> Better let each application handle that kind of controls/settings. If
> they don't do, then its the applications fault.

you have a good point there, but it might be usefull anyway...

at start, show only the ones used at that time, if there are added, add
them; if there are deleted, don't delete them, but remember and hold,
cause if new ones start, these get used anyway, and you can force it on
the newly started application as a default value, if the appl does it
himself, it just gets changed, one could even reset it or deny the appl to
change it...


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Raymond]

Clemens Ladisch wrote:
> Raymond wrote:
> 
>>In theory, and sound cards with hardware mixing can support this kind of
>>volume control.
>>
>>au88x0 driver may provide this kind of volume control on playing PCM
>>streams by using hardware mixers.
>>
>>However the hardware mixers are dynamically allocated in routine
>>snd_vortex_pcm_hw_params(), this means that the kcontrol can be put/get
>>only between snd_pcm_hw_params() (return no error) and
>>snd_pcm_hw_free()/snd_pcm_close().
> 
> 
> The driver could save the value and apply it when a stream is opened.
> 
>
>>Is there any flag in kcontrol which enable/disable the put/get from
>>mixer application ?
>
>
> Controls can be locked.
>
>

What is the meaning of SNDRV_CTL_ELEM_ACCESS_INACTIVE ?

Is it just a flag which the driver should check whether the value can be
written to the hardware registers ?

It seem to me that snd_vortex_pcm_adb_vol_put() are called even when
kcontrol is inactive (e.g alsactl restore after the driver is loaded)

What value (0 or 1) will be return by snd_vortex_pcm_adb_vol_put() when
kcontrol is inactive/locked ?









-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Volume per voices [Feature Request]

[Jaroslav Kysela]

On Fri, 12 Aug 2005, Raymond wrote:

> What is the meaning of SNDRV_CTL_ELEM_ACCESS_INACTIVE ?

Inactive means that the driver does not care when the application updates 
value. It means - this value can be written / read but has no effect / 
meaning. For example, PCM stream related volumes must be initialized to 
some reasonable default at the "open" stage. Then they are active until 
"release" is called. After "release" they become "inactive". You can also 
dynamically add and remove these PCM stream volume controls, but marking 
them inactive is more efficient.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Volume per voices [Feature Request]

[Jaroslav Kysela]

On Thu, 28 Jul 2005, Raymond wrote:

> In theory, and sound cards with hardware mixing can support this kind of
> volume control.
> 
> au88x0 driver may provide this kind of volume control on playing PCM
> streams by using hardware mixers.
> 
> However the hardware mixers are dynamically allocated in routine
> snd_vortex_pcm_hw_params(), this means that the kcontrol can be put/get
> only between snd_pcm_hw_params() (return no error) and
> snd_pcm_hw_free()/snd_pcm_close().

Nope. Please, define the controls at the driver initialization phase and 
make them inactive when the stream is not open. See emu10k1 or trident 
driver for hints. You must also map the voice volume with substream 
number.

Creating controls dymanically has only sense when hardware changes (like a 
new DSP is loaded for emu10k1).

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Raymond]

Jaroslav Kysela wrote:
> On Thu, 28 Jul 2005, Raymond wrote:
> 
> 
>>In theory, and sound cards with hardware mixing can support this kind of
>>volume control.
>>
> 
> Nope. Please, define the controls at the driver initialization phase and 
> make them inactive when the stream is not open. See emu10k1 or trident 
> driver for hints. You must also map the voice volume with substream 
> number.
> 

Beside volume control, Is it feasible to bind other controls (e.g.
Interaural Time Difference, Interaural Level Difference and SAMPLE RATE 
CONVERTOR - Doppler Effect ) to the substream ?


How can the alsa application access those controls
(SNDRV_CTL_ELEM_IFACE_PCM) using the handle return by snd_pcm_open() ?



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Mon, 01 Aug 2005 00:37:26 +0800,
Raymond wrote:
> 
> Jaroslav Kysela wrote:
> > On Thu, 28 Jul 2005, Raymond wrote:
> > 
> > 
> >>In theory, and sound cards with hardware mixing can support this kind of
> >>volume control.
> >>
> > 
> > Nope. Please, define the controls at the driver initialization phase and 
> > make them inactive when the stream is not open. See emu10k1 or trident 
> > driver for hints. You must also map the voice volume with substream 
> > number.
> > 
> 
> Beside volume control, Is it feasible to bind other controls (e.g.
> Interaural Time Difference, Interaural Level Difference and SAMPLE RATE 
> CONVERTOR - Doppler Effect ) to the substream ?

I think yes.  Whatever directly bound to a PCM substream should be
handled as IFACE_PCM with a certain subdevice number.


> How can the alsa application access those controls
> (SNDRV_CTL_ELEM_IFACE_PCM) using the handle return by snd_pcm_open() ?

By defining a new API for that purpose :)


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Volume per voices [Feature Request]

[Raymond]

Takashi Iwai wrote:
> At Mon, 01 Aug 2005 00:37:26 +0800,
> Raymond wrote:
> 
>>Jaroslav Kysela wrote:
>>
>>>On Thu, 28 Jul 2005, Raymond wrote:
>>>
>>>
>>>
>>>>In theory, and sound cards with hardware mixing can support this kind of
>>>>volume control.
>>>>
>>>
>>>Nope. Please, define the controls at the driver initialization phase and 
>>>make them inactive when the stream is not open. See emu10k1 or trident 
>>>driver for hints. You must also map the voice volume with substream 
>>>number.
>>>
>>
>>Beside volume control, Is it feasible to bind other controls (e.g.
>>Interaural Time Difference, Interaural Level Difference and SAMPLE RATE 
>>CONVERTOR - Doppler Effect ) to the substream ?
> 
> 
> I think yes.  Whatever directly bound to a PCM substream should be
> handled as IFACE_PCM with a certain subdevice number.
> 
> 

It's OK for au88x0 to use a sample rate different from that of PCM 
stream play the PCM stream to produce a different pitch.

Does the alsa-lib really allow using a kcontrol to change the sample 
rate while playing the PCM to produce the Doppler Effect ?











-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Volume per voices [Feature Request]

[Takashi Iwai]

At Fri, 05 Aug 2005 18:23:20 +0800,
Raymond wrote:
> 
> Takashi Iwai wrote:
> > At Mon, 01 Aug 2005 00:37:26 +0800,
> > Raymond wrote:
> > 
> >>Jaroslav Kysela wrote:
> >>
> >>>On Thu, 28 Jul 2005, Raymond wrote:
> >>>
> >>>
> >>>
> >>>>In theory, and sound cards with hardware mixing can support this kind of
> >>>>volume control.
> >>>>
> >>>
> >>>Nope. Please, define the controls at the driver initialization phase and 
> >>>make them inactive when the stream is not open. See emu10k1 or trident 
> >>>driver for hints. You must also map the voice volume with substream 
> >>>number.
> >>>
> >>
> >>Beside volume control, Is it feasible to bind other controls (e.g.
> >>Interaural Time Difference, Interaural Level Difference and SAMPLE RATE 
> >>CONVERTOR - Doppler Effect ) to the substream ?
> > 
> > 
> > I think yes.  Whatever directly bound to a PCM substream should be
> > handled as IFACE_PCM with a certain subdevice number.
> > 
> > 
> 
> It's OK for au88x0 to use a sample rate different from that of PCM 
> stream play the PCM stream to produce a different pitch.
> 
> Does the alsa-lib really allow using a kcontrol to change the sample 
> rate while playing the PCM to produce the Doppler Effect ?

Currently not officially supported.  The rate is assumed to be
constant.
But changing rate dynamically seems working, though.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Raymond]

Takashi Iwai wrote:
> At Mon, 01 Aug 2005 00:37:26 +0800,
> Raymond wrote:
> 
>>Jaroslav Kysela wrote:
>>
>>>On Thu, 28 Jul 2005, Raymond wrote:
>>>
>>>
>>>
>>>>In theory, and sound cards with hardware mixing can support this kind of
>>>>volume control.
>>>>
>>>
>>>Nope. Please, define the controls at the driver initialization phase and 
>>>make them inactive when the stream is not open. See emu10k1 or trident 
>>>driver for hints. You must also map the voice volume with substream 
>>>number.
>>>
>>
>>Beside volume control, Is it feasible to bind other controls (e.g.
>>Interaural Time Difference, Interaural Level Difference and SAMPLE RATE 
>>CONVERTOR - Doppler Effect ) to the substream ?
> 
> 
> I think yes.  Whatever directly bound to a PCM substream should be
> handled as IFACE_PCM with a certain subdevice number.
> 
> 
> 
>>How can the alsa application access those controls
>>(SNDRV_CTL_ELEM_IFACE_PCM) using the handle return by snd_pcm_open() ?
> 
> 
> By defining a new API for that purpose :)
> 
> 
> Takashi
> 
> 

Can this kind of volume control with iface = SNDRV_CTL_ELEM_IFACE_PCM
used by mixer application (e.g. alsamixer) or only the application which
open the PCM substream ?

Distortion occur when the combined gain of audio data, hardware mixer ,
equalizer and 3D effect > 6dB ( limit by the 18-bits DAC in AC97 codec)

Can negative number can be used in the kcontrol with type
SNDRV_CTL_ELEM_TYPE_INTEGER ? (i.e. uinfo->value.integer.min < 0 )

What is the maximum value can be assigned to uinfo->value.integer.max ?

In the ALSA au88x0 driver, the hardware mixer provide default gain of
6dB ( 16-bits auido data to 18-bits DAC in AC97 codec ) for the
left/right channels of au8820 and the rear channels of au8810/au8830 (to 
SDAC of quad codec),

For the front channels of au8810/au8830, zero gain in hardware mixer and
this 6dB gain is most likely controlled by the equalizer or 3D effect.

Is there any faster method to find the substream of the subdevice in
snd_vortex_adb_pcm_vol_put ?

struct snd_vortex {

...
	snd_kcontrol_t *ctl_pcm_vol[NR_ADB];
	int mixin[NR_ADB][4];		/* MIXIN */
         int pcm_vol[NR_ADB][4];         /* PCM VOLUME */
...

}

static int snd_vortex_adb_pcm_vol_info(snd_kcontrol_t *kcontrol,
snd_ctl_elem_info_t * uinfo)
{
	vortex_t *vortex = snd_kcontrol_chip(kcontrol);
	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
	uinfo->count = (VORTEX_IS_QUAD(vortex) ? 4 : 2);
	uinfo->value.integer.min = 0;
	uinfo->value.integer.max = 255;
	return 0;
}

static int snd_vortex_adb_pcm_change_vol(vortex_t *vortex,int mixin,int
mix,int volume)
{
	if ( volume >= 128 )
		vortex_mix_setinputvolumebyte(vortex, mix, mixin, volume-128);    // GAIN
GAIN
	else
		vortex_mix_setinputvolumebyte(vortex, mix, mixin, volume+128);    // ATTEN
ATTEN
	return 0;
}

static int snd_vortex_adb_pcm_vol_get(snd_kcontrol_t * kcontrol,
snd_ctl_elem_value_t * ucontrol)
{
	int i,subdevice;
	vortex_t *vortex = snd_kcontrol_chip(kcontrol);
	subdevice = kcontrol->id.subdevice;
	for (i=0; i<(VORTEX_IS_QUAD(vortex) ? 4 : 2 ); i++)
		ucontrol->value.integer.value[i] = vortex->pcm_vol[subdevice][i];	
	return 0;
}

static int snd_vortex_adb_pcm_vol_put(snd_kcontrol_t * kcontrol,
snd_ctl_elem_value_t * ucontrol)
{
	int i,j,changed,subdevice;
	vortex_t *vortex = snd_kcontrol_chip(kcontrol);
	subdevice=kcontrol->id.subdevice;
	changed = 0;
	if ( ( kcontrol->vd[0].access & SNDRV_CTL_ELEM_ACCESS_INACTIVE ) == 0 ) {
		for (i=0; i<NR_ADB; i++) {
			if ( vortex->dma_adb[i].substream != NULL ) {
				if ( vortex->dma_adb[i].substream->number == subdevice ) {
					for (j=0; j<(VORTEX_IS_QUAD(vortex) ? 4 : 2 ); j++) {
						if ( vortex->pcm_vol[subdevice][j] !=
ucontrol->value.integer.value[j] )
							changed=1;
						vortex->pcm_vol[subdevice][j] = ucontrol->value.integer.value[j];
					};
					switch(vortex->dma_adb[i].nr_ch) {
					case 1:
						for (j=0; j<(VORTEX_IS_QUAD(vortex) ? 4 : 2 ); j++) {
							snd_vortex_adb_pcm_change_vol(vortex,
vortex->mixin[subdevice][0], vortex->mixplayb[j],
vortex->pcm_vol[subdevice][j]);
						};
						break;
					case 2:
						for (j=0; j<2; j++) {
							snd_vortex_adb_pcm_change_vol(vortex,
vortex->mixin[subdevice][j], vortex->mixplayb[j],
vortex->pcm_vol[subdevice][j]);
							if (VORTEX_IS_QUAD(vortex))
								snd_vortex_adb_pcm_change_vol(vortex,
vortex->mixin[subdevice][j], vortex->mixplayb[j+2],
vortex->pcm_vol[subdevice][j+2]);
						};
						break;
					case 4:
						for (j=0; j<4; j++) {
							snd_vortex_adb_pcm_change_vol(vortex,
vortex->mixin[subdevice][j], vortex->mixplayb[j],
vortex->pcm_vol[subdevice][j]);
						};
						break;
					};
					return changed;
				};
			};
		};
	};
	return changed;
}

static snd_kcontrol_new_t snd_vortex_adb_pcm_vol = {
	.iface =	SNDRV_CTL_ELEM_IFACE_PCM,
	.name =		"ADB PCM Volume",
	.access = 	SNDRV_CTL_ELEM_ACCESS_READWRITE |
SNDRV_CTL_ELEM_ACCESS_INACTIVE,
	.info =		snd_vortex_adb_pcm_vol_info,
	.get =		snd_vortex_adb_pcm_vol_get,
	.put =		snd_vortex_adb_pcm_vol_put,
};


Do we need to make the front and rear channels of au8810/au8830 with
equal default gain and equal volume range ? e.g. Adding mixer between
equalizer and AC97 and a switch to allow each substream to bypass
equalizer, the other way is to set equalizer in bypass mode for all
substreams.


au8810/au8830
                                    (6db)
Front channels          +----------MIXER-------------+
                         |                            |
                         |(0dB)     (6dB)       (0dB) |
    DMA -> FIFO -> SRC -> MIXER -> Equalizer -> MIXER -> AC97
                |           |
                |           +--------------------------> SPDIF
                |
Rear channels  +--SRC -----------> MIXER -------------> SDAC
                                    (6dB)




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Manuel Jander]

Hi,

On Mon, 2005-08-29 at 10:28 +0800, Raymond wrote:
> Takashi Iwai wrote:
> > At Mon, 01 Aug 2005 00:37:26 +0800,
> > Raymond wrote:
> > 
> >>Jaroslav Kysela wrote:
> >>
> >>>On Thu, 28 Jul 2005, Raymond wrote:
> Can this kind of volume control with iface = SNDRV_CTL_ELEM_IFACE_PCM
> used by mixer application (e.g. alsamixer) or only the application which
> open the PCM substream ?

I guess not, because its PCM specific, and only valid on a PCM device
open context. Trying to find out which app is opening which PCM device
is just nonsense.

> Distortion occur when the combined gain of audio data, hardware mixer ,
> equalizer and 3D effect > 6dB ( limit by the 18-bits DAC in AC97 codec)

The maximum gain possible for a entire audio pipe should obvisouly not
exceeded.

> Can negative number can be used in the kcontrol with type
> SNDRV_CTL_ELEM_TYPE_INTEGER ? (i.e. uinfo->value.integer.min < 0 )

AFAIK, yes.

> What is the maximum value can be assigned to uinfo->value.integer.max ?

> In the ALSA au88x0 driver, the hardware mixer provide default gain of
> 6dB ( 16-bits auido data to 18-bits DAC in AC97 codec ) for the
> left/right channels of au8820 and the rear channels of au8810/au8830 (to 
> SDAC of quad codec),
> 
> For the front channels of au8810/au8830, zero gain in hardware mixer and
> this 6dB gain is most likely controlled by the equalizer or 3D effect.
> 
> Is there any faster method to find the substream of the subdevice in
> snd_vortex_adb_pcm_vol_put ?
> 
> struct snd_vortex {
> 
> ...
> 	snd_kcontrol_t *ctl_pcm_vol[NR_ADB];
> 	int mixin[NR_ADB][4];		/* MIXIN */
>          int pcm_vol[NR_ADB][4];         /* PCM VOLUME */
> ...
> 
> }
> 
> static int snd_vortex_adb_pcm_vol_info(snd_kcontrol_t *kcontrol,
> snd_ctl_elem_info_t * uinfo)
> {
> 	vortex_t *vortex = snd_kcontrol_chip(kcontrol);
> 	uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
> 	uinfo->count = (VORTEX_IS_QUAD(vortex) ? 4 : 2);
> 	uinfo->value.integer.min = 0;
> 	uinfo->value.integer.max = 255;
> 	return 0;
> }
> 
> static int snd_vortex_adb_pcm_change_vol(vortex_t *vortex,int mixin,int
> mix,int volume)
> {
> 	if ( volume >= 128 )
> 		vortex_mix_setinputvolumebyte(vortex, mix, mixin, volume-128);    // GAIN
> GAIN
> 	else
> 		vortex_mix_setinputvolumebyte(vortex, mix, mixin, volume+128);    // ATTEN
> ATTEN
> 	return 0;
> }

I would suggest using the correct signed or unsigned type instead of
doing explicit type conversions.

> static int snd_vortex_adb_pcm_vol_get(snd_kcontrol_t * kcontrol,
> snd_ctl_elem_value_t * ucontrol)
> {
> 	int i,subdevice;
> 	vortex_t *vortex = snd_kcontrol_chip(kcontrol);
> 	subdevice = kcontrol->id.subdevice;
> 	for (i=0; i<(VORTEX_IS_QUAD(vortex) ? 4 : 2 ); i++)
> 		ucontrol->value.integer.value[i] = vortex->pcm_vol[subdevice][i];	
> 	return 0;
> }

As the resource manager is written now, there is no other way to do
this. Any attempt to speed up would make the whole thing more complex,
and in opinion is not required. iterating 32 or 64 times in a short loop
on current PC is not a significant worload.

> static int snd_vortex_adb_pcm_vol_put(snd_kcontrol_t * kcontrol,
> snd_ctl_elem_value_t * ucontrol)
> {
> 	int i,j,changed,subdevice;
> 	vortex_t *vortex = snd_kcontrol_chip(kcontrol);
> 	subdevice=kcontrol->id.subdevice;
> 	changed = 0;
> 	if ( ( kcontrol->vd[0].access & SNDRV_CTL_ELEM_ACCESS_INACTIVE ) == 0 ) {
> 		for (i=0; i<NR_ADB; i++) {
> 			if ( vortex->dma_adb[i].substream != NULL ) {
> 				if ( vortex->dma_adb[i].substream->number == subdevice ) {
> 					for (j=0; j<(VORTEX_IS_QUAD(vortex) ? 4 : 2 ); j++) {
> 						if ( vortex->pcm_vol[subdevice][j] !=
> ucontrol->value.integer.value[j] )
> 							changed=1;
> 						vortex->pcm_vol[subdevice][j] = ucontrol->value.integer.value[j];
> 					};
> 					switch(vortex->dma_adb[i].nr_ch) {
> 					case 1:
> 						for (j=0; j<(VORTEX_IS_QUAD(vortex) ? 4 : 2 ); j++) {
> 							snd_vortex_adb_pcm_change_vol(vortex,
> vortex->mixin[subdevice][0], vortex->mixplayb[j],
> vortex->pcm_vol[subdevice][j]);
> 						};
> 						break;
> 					case 2:
> 						for (j=0; j<2; j++) {
> 							snd_vortex_adb_pcm_change_vol(vortex,
> vortex->mixin[subdevice][j], vortex->mixplayb[j],
> vortex->pcm_vol[subdevice][j]);
> 							if (VORTEX_IS_QUAD(vortex))
> 								snd_vortex_adb_pcm_change_vol(vortex,
> vortex->mixin[subdevice][j], vortex->mixplayb[j+2],
> vortex->pcm_vol[subdevice][j+2]);
> 						};
> 						break;
> 					case 4:
> 						for (j=0; j<4; j++) {
> 							snd_vortex_adb_pcm_change_vol(vortex,
> vortex->mixin[subdevice][j], vortex->mixplayb[j],
> vortex->pcm_vol[subdevice][j]);
> 						};
> 						break;
> 					};
> 					return changed;
> 				};
> 			};
> 		};
> 	};
> 	return changed;
> }

I have not much time right now, but the switch statement looked to me
somewhat redundant (?).

> static snd_kcontrol_new_t snd_vortex_adb_pcm_vol = {
> 	.iface =	SNDRV_CTL_ELEM_IFACE_PCM,
> 	.name =		"ADB PCM Volume",
> 	.access = 	SNDRV_CTL_ELEM_ACCESS_READWRITE |
> SNDRV_CTL_ELEM_ACCESS_INACTIVE,
> 	.info =		snd_vortex_adb_pcm_vol_info,
> 	.get =		snd_vortex_adb_pcm_vol_get,
> 	.put =		snd_vortex_adb_pcm_vol_put,
> };
> 
> 
> Do we need to make the front and rear channels of au8810/au8830 with
> equal default gain and equal volume range ? e.g. Adding mixer between
> equalizer and AC97 and a switch to allow each substream to bypass
> equalizer, the other way is to set equalizer in bypass mode for all
> substreams.

There is no need to waste any more mixers (there are a very precious
resource and its easy to run out of them). The EQ has a global gain
control, which should used instead.

> 
> au8810/au8830
>                                     (6db)
> Front channels          +----------MIXER-------------+
>                          |                            |
>                          |(0dB)     (6dB)       (0dB) |
>     DMA -> FIFO -> SRC -> MIXER -> Equalizer -> MIXER -> AC97
>                 |           |
>                 |           +--------------------------> SPDIF
>                 |
> Rear channels  +--SRC -----------> MIXER -------------> SDAC
>                                     (6dB)

SPDIF should not pass through SRC's. It should go strait from the FIFO
if possible. Only if the samplerate is something odd and the audio
format is stereo, maybe a SRC should be connected in between.

Nice work you are doing. Thank you very much for keeping this going ;)

Best Regards
Manuel




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Volume per voices [Feature Request]

[Jaroslav Kysela]

On Wed, 27 Jul 2005, Clemens Ladisch wrote:

> > I believe PCM iface attribute could be used for such a purpose,
> 
> As far as I see, the iface/device/subdevice fields were designed for
> exactly this purpose, i.e., associating a control with a specific
> (sub)device.
> 
> > but unfortunately, the situation is confusing.  Some drivers
> > already use PCM iface for different purposes (e.g. hdsp) and some
> > use mixer iface for exactly this purpose (e.g. emu10k1)...
> 
> Then I'd consider these drivers buggy.

I agree.

> I'll write a patch unless anybody objects ...

No objections from my side.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

RE: Volume per voices [Feature Request]

[Dino]

Scrive Giuliano Pochini <pochini@shiny.it>:

>
> On 26-Jul-2005 Dino Puller wrote:
> > Hi all,
> >     i don't know if this is the right place to ask for a new feature,
> > BTW here it is:
> > It's should be very useful to have a standard way/function to map volume
> > per PCM stream. For now seems that only emu10k1 and via82xxx has a
> > volume control for each PCM streams, probably because a lack on the
> > others drivers. Where the HW/driver doesn't support this control, it's
> > should be emulated via software.
>
> Most cards have hw volume, but ALSA cannot answer this simple question:
> given this PCM handle, what numid:index control controls the gain of its
> Nth channel ?
This is exactly what i'd like. I'd like to skip this access to a control gain,
and instead create a standard map to the relative pcm stream.

> That question is not as simple as it may seem at first glance. The ctl
> may not exist at all if the cards do not support it or if the PCM is
> not an hardware PCM (eg. is uses dmix). Even if the card has a simple
> 1:1 relation between a PCM device and an hw control, some plugins (route,
> multi or any combination of any plugins) may have shuffled things...
Hmm i know nothing about route and others plugins, but we can use this volume
control only if it's direct and use an emulation otherwise, it's a simple
access to a lookup table and two multipications. This emulation should be done
even if our hardware doesn't support this gain. At this purpouse i'm looking at
the code of cs46xx driver witch play with my soundcard, and i'm trying to add
this controls and its seems to work (a bit buggy but i've just started) btw
it's really simple to do.
Anyway it's strange that alsa doesn't support this feature, because the old GUS
classic supports volume per pcm, volume ramp, and looping! And alsa was born
from it's drivers.

regards,
   Dino

>
>
> --
> Giuliano.
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

RE: Volume per voices [Feature Request]

[Dino]

Scrive Giuliano Pochini <pochini@shiny.it>:

>
> On 26-Jul-2005 Dino Puller wrote:
> > Hi all,
> >     i don't know if this is the right place to ask for a new feature,
> > BTW here it is:
> > It's should be very useful to have a standard way/function to map volume
> > per PCM stream. For now seems that only emu10k1 and via82xxx has a
> > volume control for each PCM streams, probably because a lack on the
> > others drivers. Where the HW/driver doesn't support this control, it's
> > should be emulated via software.
>
> Most cards have hw volume, but ALSA cannot answer this simple question:
> given this PCM handle, what numid:index control controls the gain of its
> Nth channel ?
This is exactly what i'd like. I'd like to skip this access to a control gain,
and instead create a standard map to the relative pcm stream.

> That question is not as simple as it may seem at first glance. The ctl
> may not exist at all if the cards do not support it or if the PCM is
> not an hardware PCM (eg. is uses dmix). Even if the card has a simple
> 1:1 relation between a PCM device and an hw control, some plugins (route,
> multi or any combination of any plugins) may have shuffled things...
Hmm i know nothing about route and others plugins, but we can use this volume
control only if it's direct and use an emulation otherwise, it's a simple
access to a lookup table and two multipications. This emulation should be done
even if our hardware doesn't support this gain. At this purpouse i'm looking at
the code of cs46xx driver witch play with my soundcard, and i'm trying to add
this controls and its seems to work (a bit buggy but i've just started) btw
it's really simple to do.
Anyway it's strange that alsa doesn't support this feature, because the old GUS
classic supports volume per pcm, volume ramp, and looping! And alsa was born
from it's drivers.

regards,
   Dino

>
>
> --
> Giuliano.
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

Re: Volume per voices

[Takashi Iwai]

At Mon, 25 Jul 2005 16:22:31 +0200 (METDST),
Clemens Ladisch wrote:
> 
> Dino wrote:
> >    i'm looking for setting a volume per voice(pcm stream) but it seems to be
> > impossible. I've found only a plugin to do it in software but i'd like to do it
> > in Hardware. Is it a feature not supported by alsa?
> 
> The Emu10k1 and VIA82xxx drivers have volume controls for each
> hardware PCM stream. 

The recent via82xx driver uses these registers as alternative PCM
volumes for ac97 codecs without PCM volumes like C-Media ones.


Takashi


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: maximum voices/channels

[Clemens Ladisch]

Cesar Hernandez wrote:
> I want to know what is the maximum number of notes or sampled
> voices (mapped to a note) that I can play at the same time...

This depends on the synthesizer.  If you're using an external device,
there is almost no possibility to know how many voices it has.  Most
internal wavetable synthesizers share their voices with the PCM output
streams, and you cannot know how many voices a note uses without
looking into the soundfont.


HTH
Clemens



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: maximum voices/channels

[Jaroslav Kysela]

On Fri, 22 Jul 2005, Cesar Hernandez wrote:

> Hi.
> 
> I have a question on using alsa sequencer. I am working on a kind of
> piano program, and I want to know what is the maximum number of notes or
> sampled voices (mapped to a note) that I can play at the same time...
> I know that two or three notes may sound at the same sequencer channel,
> but I don't know what is the maximum. 
> Is there a maximum number of voices/notes per sequencer channel? Or it's
> a maximum number counting all the channels...? Or it depends on the midi
> output (timidity, midi keyboard...)

See 'snd_seq_port_info_get_midi_voices()' function.... It returns total 
number of voices allocated for the midi emulation and this value is not 
available for external synths, of course. The voice allocation is 
driver/sequencer client specific.

						Jaroslav

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


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click