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

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

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