double speed (ADAT), and hw params ordering

double speed (ADAT), and hw params ordering

[Paul Davis]

i've been wondering what to do about setting sample rates in the
hammerfall and h-dsp drivers. fernando and gary from CCRMA have made
the excellent suggestion that rather than have the driver pretend that
all rates are available all the time, as it currently does, that we
have a control switch to go between regular rates and the "double
speed" or "bitsplit" rates (64kHz-96kHz) which reduce the channel
count.  i think this is an excellent idea. you would not be able to
use the switch while the device was open. when you opened it, you
would find (for example) a device with 14 channels (12 ADAT plus 2
SPDIF) at 64-96kHz or 26 channels (24 ADAT+2 SPDIF) at 32-48kHz.

if anyone objects to this model, please let me know. right now, its
more or less impossible to get access to the higher rates.

on a related note, although the above suggestion will fix this
particular problem, it seems that it might be wise to consider adding
a parameter order information field to the driver API, so that drivers
can say "you have to set param P first, then param N, then param
O". the default would obviously be "don't care", but for devices that
lose certain capabilities when certain parameters are set, it would
make things very much easier.

--p



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

Re: double speed (ADAT), and hw params ordering

[Takashi Iwai]

At Thu, 18 Jul 2002 14:58:07 -0400,
Paul Davis wrote:
> 
> i've been wondering what to do about setting sample rates in the
> hammerfall and h-dsp drivers. fernando and gary from CCRMA have made
> the excellent suggestion that rather than have the driver pretend that
> all rates are available all the time, as it currently does, that we
> have a control switch to go between regular rates and the "double
> speed" or "bitsplit" rates (64kHz-96kHz) which reduce the channel
> count.  i think this is an excellent idea. you would not be able to
> use the switch while the device was open. when you opened it, you
> would find (for example) a device with 14 channels (12 ADAT plus 2
> SPDIF) at 64-96kHz or 26 channels (24 ADAT+2 SPDIF) at 32-48kHz.
 
i vote for this idea.

> if anyone objects to this model, please let me know. right now, its
> more or less impossible to get access to the higher rates.
> 
> on a related note, although the above suggestion will fix this
> particular problem, it seems that it might be wise to consider adding
> a parameter order information field to the driver API, so that drivers
> can say "you have to set param P first, then param N, then param
> O". the default would obviously be "don't care", but for devices that
> lose certain capabilities when certain parameters are set, it would
> make things very much easier.

agreed that it's good to have such one.
but how to implement this?
from the design of hw_constraint, i don't think it's so easy...


Takashi


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

Re: double speed (ADAT), and hw params ordering

[Jaroslav Kysela]

On Fri, 19 Jul 2002, Takashi Iwai wrote:

> At Thu, 18 Jul 2002 14:58:07 -0400,
> Paul Davis wrote:
> > 
> > i've been wondering what to do about setting sample rates in the
> > hammerfall and h-dsp drivers. fernando and gary from CCRMA have made
> > the excellent suggestion that rather than have the driver pretend that
> > all rates are available all the time, as it currently does, that we
> > have a control switch to go between regular rates and the "double
> > speed" or "bitsplit" rates (64kHz-96kHz) which reduce the channel
> > count.  i think this is an excellent idea. you would not be able to
> > use the switch while the device was open. when you opened it, you
> > would find (for example) a device with 14 channels (12 ADAT plus 2
> > SPDIF) at 64-96kHz or 26 channels (24 ADAT+2 SPDIF) at 32-48kHz.
>  
> i vote for this idea.

Paul, what's wrong to offer all possible configurations? Could

> > if anyone objects to this model, please let me know. right now, its
> > more or less impossible to get access to the higher rates.
> > 
> > on a related note, although the above suggestion will fix this
> > particular problem, it seems that it might be wise to consider adding
> > a parameter order information field to the driver API, so that drivers
> > can say "you have to set param P first, then param N, then param
> > O". the default would obviously be "don't care", but for devices that
> > lose certain capabilities when certain parameters are set, it would
> > make things very much easier.
> 
> agreed that it's good to have such one.
> but how to implement this?
> from the design of hw_constraint, i don't think it's so easy...
> 
> 
> Takashi
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



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

Re: double speed (ADAT), and hw params ordering

[Jaroslav Kysela]

On Fri, 19 Jul 2002, Takashi Iwai wrote:

> At Thu, 18 Jul 2002 14:58:07 -0400,
> Paul Davis wrote:
> > 
> > i've been wondering what to do about setting sample rates in the
> > hammerfall and h-dsp drivers. fernando and gary from CCRMA have made
> > the excellent suggestion that rather than have the driver pretend that
> > all rates are available all the time, as it currently does, that we
> > have a control switch to go between regular rates and the "double
> > speed" or "bitsplit" rates (64kHz-96kHz) which reduce the channel
> > count.  i think this is an excellent idea. you would not be able to
> > use the switch while the device was open. when you opened it, you
> > would find (for example) a device with 14 channels (12 ADAT plus 2
> > SPDIF) at 64-96kHz or 26 channels (24 ADAT+2 SPDIF) at 32-48kHz.
>  
> i vote for this idea.

Paul, what's wrong to offer all possible configurations? Could you explain 
the problems?

> > if anyone objects to this model, please let me know. right now, its
> > more or less impossible to get access to the higher rates.
> > 
> > on a related note, although the above suggestion will fix this
> > particular problem, it seems that it might be wise to consider adding
> > a parameter order information field to the driver API, so that drivers
> > can say "you have to set param P first, then param N, then param
> > O". the default would obviously be "don't care", but for devices that
> > lose certain capabilities when certain parameters are set, it would
> > make things very much easier.
> 
> agreed that it's good to have such one.
> but how to implement this?
> from the design of hw_constraint, i don't think it's so easy...

I think that this implementation will create a big mess for the 
application developers. Also, I'm not sure, if it's really needed, because 
our refining code should already reduce the available configurations. 
Applications should use *_near() functions in order of their priority. You 
can't predict, if rate or count of channels or any other parameter is more 
important for a specific application.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com




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

(no subject)

[Fernando Pablo Lopez-Lezcano]

> > > on a related note, although the above suggestion will fix this
> > > particular problem, it seems that it might be wise to consider adding
> > > a parameter order information field to the driver API, so that drivers
> > > can say "you have to set param P first, then param N, then param
> > > O". the default would obviously be "don't care", but for devices that
> > > lose certain capabilities when certain parameters are set, it would
> > > make things very much easier.
> > 
> > agreed that it's good to have such one.
> > but how to implement this?
> > from the design of hw_constraint, i don't think it's so easy...
> 
> I think that this implementation will create a big mess for the 
> application developers. Also, I'm not sure, if it's really needed, because 
> our refining code should already reduce the available configurations. 
> Applications should use *_near() functions in order of their priority. You 
> can't predict, if rate or count of channels or any other parameter is more 
> important for a specific application.

[not exactly an answer but more details on what is actually happening]

I think this is what is happening with the current driver (Gary, please
correct me if I'm wrong):  The application looks at the configuration
space and selects from it one particular sampling rate. Then it looks at
the channel count and sees a range of channel counts (10:18 - or some
numbers like that, I don't remember). The application chooses the minimum
channel count and the set function fails.

IMHO at that point the configuration space should have changed the number
of channels available to match the sampling rate selected so that the
channel count as advertised is legal (ie: if the selected sampling rate is
one of the "single speed" rates then the range of channels should be
18:18, if the sampling rate is one of the "double speed" rates then the
range should be 10:10).

The reverse is also true, if the application first selects number of 
channels the sampling rates should be constrained to the set of rates that 
can be supported by that number of channels. 

If it is not possible to do this with the current api, then the next best
solution I can imagine is to have a switch that changes the mode of the
card between single and double speed (that would make the dependency
between sample rate and number of channels dissapear).

-- Fernando



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

Re: (no subject)

[Abramo Bagnara]

Fernando Pablo Lopez-Lezcano wrote:
> 
> > > > on a related note, although the above suggestion will fix this
> > > > particular problem, it seems that it might be wise to consider adding
> > > > a parameter order information field to the driver API, so that drivers
> > > > can say "you have to set param P first, then param N, then param
> > > > O". the default would obviously be "don't care", but for devices that
> > > > lose certain capabilities when certain parameters are set, it would
> > > > make things very much easier.
> > >
> > > agreed that it's good to have such one.
> > > but how to implement this?
> > > from the design of hw_constraint, i don't think it's so easy...
> >
> > I think that this implementation will create a big mess for the
> > application developers. Also, I'm not sure, if it's really needed, because
> > our refining code should already reduce the available configurations.
> > Applications should use *_near() functions in order of their priority. You
> > can't predict, if rate or count of channels or any other parameter is more
> > important for a specific application.
> 
> [not exactly an answer but more details on what is actually happening]
> 
> I think this is what is happening with the current driver (Gary, please
> correct me if I'm wrong):  The application looks at the configuration
> space and selects from it one particular sampling rate. Then it looks at
> the channel count and sees a range of channel counts (10:18 - or some
> numbers like that, I don't remember). The application chooses the minimum
> channel count and the set function fails.
> 
> IMHO at that point the configuration space should have changed the number
> of channels available to match the sampling rate selected so that the
> channel count as advertised is legal (ie: if the selected sampling rate is
> one of the "single speed" rates then the range of channels should be
> 18:18, if the sampling rate is one of the "double speed" rates then the
> range should be 10:10).
> 
> The reverse is also true, if the application first selects number of
> channels the sampling rates should be constrained to the set of rates that
> can be supported by that number of channels.
> 
> If it is not possible to do this with the current api, then the next best
> solution I can imagine is to have a switch that changes the mode of the
> card between single and double speed (that would make the dependency
> between sample rate and number of channels dissapear).

I've designed current refine API to do exactly what you've described.

If this don't work for the specific card it's a card driver bug.

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy


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

Re: your mail

[Jaroslav Kysela]

On Sat, 20 Jul 2002, Fernando Pablo Lopez-Lezcano wrote:

> > > > on a related note, although the above suggestion will fix this
> > > > particular problem, it seems that it might be wise to consider adding
> > > > a parameter order information field to the driver API, so that drivers
> > > > can say "you have to set param P first, then param N, then param
> > > > O". the default would obviously be "don't care", but for devices that
> > > > lose certain capabilities when certain parameters are set, it would
> > > > make things very much easier.
> > > 
> > > agreed that it's good to have such one.
> > > but how to implement this?
> > > from the design of hw_constraint, i don't think it's so easy...
> > 
> > I think that this implementation will create a big mess for the 
> > application developers. Also, I'm not sure, if it's really needed, because 
> > our refining code should already reduce the available configurations. 
> > Applications should use *_near() functions in order of their priority. You 
> > can't predict, if rate or count of channels or any other parameter is more 
> > important for a specific application.
> 
> [not exactly an answer but more details on what is actually happening]
> 
> I think this is what is happening with the current driver (Gary, please
> correct me if I'm wrong):  The application looks at the configuration
> space and selects from it one particular sampling rate. Then it looks at
> the channel count and sees a range of channel counts (10:18 - or some
> numbers like that, I don't remember). The application chooses the minimum
> channel count and the set function fails.
> 
> IMHO at that point the configuration space should have changed the number
> of channels available to match the sampling rate selected so that the
> channel count as advertised is legal (ie: if the selected sampling rate is
> one of the "single speed" rates then the range of channels should be
> 18:18, if the sampling rate is one of the "double speed" rates then the
> range should be 10:10).
> 
> The reverse is also true, if the application first selects number of 
> channels the sampling rates should be constrained to the set of rates that 
> can be supported by that number of channels. 

You've described exactly the behaviour which should be implemented in your
paragraphs. If the current implementation is broken, then we should fix
it.

> If it is not possible to do this with the current api, then the next best
> solution I can imagine is to have a switch that changes the mode of the
> card between single and double speed (that would make the dependency
> between sample rate and number of channels dissapear).

You may look to snd_rme9652_hw_rule_channels(), 
snd_rme9652_hw_rule_channels_rate() and 
snd_rme9652_hw_rule_rate_channels() functions in rme9652.c.

These functions exactly describes the contraints for rate/channels.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



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

hdsp channel/sample rate issues

[Gary Scavone]

>From earlier replies of Jaroslav and Abramo, it sounds like the API
might already be able to handle this and perhaps the problem is in the
driver, but I'll just clarify my experience with the hdsp driver.

Here is the order of parameter setting I used to follow (on pcm
device, not plug interface!):

- query supported data formats, then set format.
- query the min/max channels, then set channels
- query supported sample rates, then set sample rate
- query number of periods, then set number of periods
- query min period size, then set period size

The hdsp driver always reports 18 channels for output (10 for input).  
If I use the above sequence (setting 18 output channels), the call to
set the sample rate fails (ex. 44100 Hz).  If I re-order the sequence
so that I set the sample rate first, it works.  If I attempt to use
the 88100 and 96000 rates reported by the driver, the call to set the
sample rate fails (Paul says that those rates are not available
through the pcm interface at the moment).  Paul also says that the
maximum number of output channels at these higher rates is less (10 or
8, don't remember).  So, the idea is that if I set the sample rate to
96000, the get_channels_min() function should report this lower value.

I think there are two issues here.  First, the available parameter
settings should automatically "scale" based on the previous settings
chosen and not require a certain sequence of events to succeed.

Second, there needs to be a means for reporting inter-parameter 
dependencies.

--gary


On Sat, 20 Jul 2002, Fernando Pablo Lopez-Lezcano wrote:

>>> > > on a related note, although the above suggestion will fix this
>>> > > particular problem, it seems that it might be wise to consider adding
>>> > > a parameter order information field to the driver API, so that drivers
>>> > > can say "you have to set param P first, then param N, then param
>>> > > O". the default would obviously be "don't care", but for devices that
>>> > > lose certain capabilities when certain parameters are set, it would
>>> > > make things very much easier.
>>> > 
>>> > agreed that it's good to have such one.
>>> > but how to implement this?
>>> > from the design of hw_constraint, i don't think it's so easy...
>>> 
>>> I think that this implementation will create a big mess for the 
>>> application developers. Also, I'm not sure, if it's really needed, because 
>>> our refining code should already reduce the available configurations. 
>>> Applications should use *_near() functions in order of their priority. You 
>>> can't predict, if rate or count of channels or any other parameter is more 
>>> important for a specific application.
>>
>>[not exactly an answer but more details on what is actually happening]
>>
>>I think this is what is happening with the current driver (Gary, please
>>correct me if I'm wrong):  The application looks at the configuration
>>space and selects from it one particular sampling rate. Then it looks at
>>the channel count and sees a range of channel counts (10:18 - or some
>>numbers like that, I don't remember). The application chooses the minimum
>>channel count and the set function fails.
>>
>>IMHO at that point the configuration space should have changed the number
>>of channels available to match the sampling rate selected so that the
>>channel count as advertised is legal (ie: if the selected sampling rate is
>>one of the "single speed" rates then the range of channels should be
>>18:18, if the sampling rate is one of the "double speed" rates then the
>>range should be 10:10).
>>
>>The reverse is also true, if the application first selects number of 
>>channels the sampling rates should be constrained to the set of rates that 
>>can be supported by that number of channels. 
>>
>>If it is not possible to do this with the current api, then the next best
>>solution I can imagine is to have a switch that changes the mode of the
>>card between single and double speed (that would make the dependency
>>between sample rate and number of channels dissapear).
>>
>>-- Fernando



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