How to tell user level hardware not support a certain format in a certain sample rate

How to tell user level hardware not support a certain format in a certain sample rate

[Richard Zhao]

Hi,

runtime->hw.rates and runtime->hw.formats indicate the rate and
formats hardware can support, so the user level plugins can
auto-convert the audio data. But hardware may not support a certain
combin of sample rate and format, and will cause hw_parm fail. In such
case, plugin auto-convert will not work.
How can I let userlevel know the failure conbin, so let auto-convert work?

Thanks
Richard

Re: How to tell user level hardware not support a certain format in a certain sample rate

[Richard Zhao]

2009/2/23 Richard Zhao <linuxzsc@gmail.com>:
> Hi,
>
> runtime->hw.rates and runtime->hw.formats indicate the rate and
> formats hardware can support, so the user level plugins can
> auto-convert the audio data. But hardware may not support a certain
> combin of sample rate and format, and will cause hw_parm fail. In such
> case, plugin auto-convert will not work.
> How can I let userlevel know the failure conbin, so let auto-convert work?
>
> Thanks
> Richard
>

Anybody can do me a favor please?

Thanks
Richard

Re: How to tell user level hardware not support a certain format in a certain sample rate

[Takashi Iwai]

At Mon, 2 Mar 2009 22:04:04 +0800,
Richard Zhao wrote:
> 
> 2009/2/23 Richard Zhao <linuxzsc@gmail.com>:
> > Hi,
> >
> > runtime->hw.rates and runtime->hw.formats indicate the rate and
> > formats hardware can support, so the user level plugins can
> > auto-convert the audio data. But hardware may not support a certain
> > combin of sample rate and format, and will cause hw_parm fail. In such
> > case, plugin auto-convert will not work.
> > How can I let userlevel know the failure conbin, so let auto-convert work?
> >
> > Thanks
> > Richard
> >
> 
> Anybody can do me a favor please?

Could you be more specific, e.g. test cases with numbers?

There are some known problems with the configuration space reduction,
and I think your problem is one of them, though.  Basically, the
config space is reduced one after one for each
snd_pcm_hw_params_refine(), and the existence of a singular point
makes hard to pick up the right point.

If the problem is such one, currently there is no elegant solution.


Takashi

Re: How to tell user level hardware not support a certain format in a certain sample rate

[Clemens Ladisch]

Richard Zhao wrote:
> runtime->hw.rates and runtime->hw.formats indicate the rate and
> formats hardware can support, so the user level plugins can
> auto-convert the audio data. But hardware may not support a certain
> combin of sample rate and format,

Did you install your own constraint rules, as described in section
"Constraints" of "Writing an ALSA Driver"?


Best regards,
Clemens

Re: How to tell user level hardware not support a certain format in a certain sample rate

[Richard Zhao]

On Mon, Mar 2, 2009 at 11:58 PM, Clemens Ladisch <clemens@ladisch.de> wrote:
> Richard Zhao wrote:
>> runtime->hw.rates and runtime->hw.formats indicate the rate and
>> formats hardware can support, so the user level plugins can
>> auto-convert the audio data. But hardware may not support a certain
>> combin of sample rate and format,
>
> Did you install your own constraint rules, as described in section
> "Constraints" of "Writing an ALSA Driver"?
>
>
> Best regards,
> Clemens
>

Sure I can add rules. but the rules will be checked as hw_param. If
hw_param failed, does alsalib convert fmt or sample rate
automatically?

For example:
One codec, support:
44.1k : s8 s16 s24 s32
96k:  s24 s32

When user try to play s8/s16 96k audio file, hw_param will fail. I
don't know, how to let alsalib convert s8/s16 to s32 or convert 96k to
44.1k automatically?

Thanks
Richard

Re: How to tell user level hardware not support a certain format in a certain sample rate

[Clemens Ladisch]

Richard Zhao wrote:
> Sure I can add rules. but the rules will be checked as hw_param. If
> hw_param failed, does alsalib convert fmt or sample rate
> automatically?
> 
> For example:
> One codec, support:
> 44.1k : s8 s16 s24 s32
> 96k:  s24 s32
> 
> When user try to play s8/s16 96k audio file, hw_param will fail.

This is not how the rules work.

Initializing a device works like this:
1) The application opens the device, and the driver's open callback gets
   called.
2) The application chooses hardware parameters; ALSA checks that these
   values conform to the device's limitations.
3) After all hardware parameters are known, the driver's hw_params
   callback gets called.

When you driver adds constraint rules, it has do this in the open
callback (so that the rules are available in step 2 above).  Your
constraint rules will be called when the application tries to select
parameters; this is before the hw_params callback gets called.

In your example above, the open callback would install two rule
functions: one to remove s8/s16 if 96k has been selected, and one to
remove 96k if s8/s16 has been selected.

When the hw_params callback is called, ALSA guarantees that the
parameters are valid for the device.


HTH
Clemens

Re: How to tell user level hardware not support a certain format in a certain sample rate

[Richard Zhao]

On Mon, Mar 16, 2009 at 4:54 PM, Clemens Ladisch <clemens@ladisch.de> wrote:
> Richard Zhao wrote:
>> Sure I can add rules. but the rules will be checked as hw_param. If
>> hw_param failed, does alsalib convert fmt or sample rate
>> automatically?
>>
>> For example:
>> One codec, support:
>> 44.1k : s8 s16 s24 s32
>> 96k:  s24 s32
>>
>> When user try to play s8/s16 96k audio file, hw_param will fail.
>
> This is not how the rules work.
>
> Initializing a device works like this:
> 1) The application opens the device, and the driver's open callback gets
>   called.
> 2) The application chooses hardware parameters; ALSA checks that these
>   values conform to the device's limitations.
> 3) After all hardware parameters are known, the driver's hw_params
>   callback gets called.
>
> When you driver adds constraint rules, it has do this in the open
> callback (so that the rules are available in step 2 above).  Your
> constraint rules will be called when the application tries to select
> parameters; this is before the hw_params callback gets called.
>
> In your example above, the open callback would install two rule
> functions: one to remove s8/s16 if 96k has been selected, and one to
> remove 96k if s8/s16 has been selected.
>
> When the hw_params callback is called, ALSA guarantees that the
> parameters are valid for the device.
>
>
> HTH
> Clemens
>

Hi Clemens,

Thank you!  I see. After set every hw parm, snd_pcm_hw_refine will
called, then the corresponding constraints(rules) will be checked.

Thanks again!
Richard