Re: Possible bug in alsa-lib. snd_pcm_hw_params_get_periods_max() returning 512 instead of 2.

[James Courtier-Dutton <James@superbug.demon.co.uk>]

Clemens Ladisch wrote:
> James Courtier-Dutton wrote:
> 
>>I cannot think of any circumstances where doing sample rate conversion
>>(using the "plug:" plugin) would change the amount of periods.
>>Is this a bug in the "plug:" plugin ?
> 
> 
> Works as designed, I guess.  It's the job of the plug plugin to remove
> hardware limitations, just in case an application wants to use 42
> periods.
> 
> 
> Regards,
> Clemens
> 

Ok, well the "design" is not working, because with the "plug:", I still 
can only ever get 2 periods. i.e. If I set period_size to 1024, the 
buffer_size can only be set to 2048, when in fact I wanted to set the 
buffer_size to 8192. i.e. I wanted 8 periods, but "plug:" forced me to 
have 2, just like the hardware can do.

So, I conclude from this that the "plug:front" cannot handle a different 
amount of periods than "front".

I think that "plug:" works fine for sample rate and sample format 
conversions, but seems to fail on the number of periods adaptions.

James


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504