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

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

[James Courtier-Dutton]

I have the following settings(see below) in my test audigyls driver 
version. Note the periods_min and periods_max both set to 2.
If the application opens the device with "plug:front".
Source code extract: -
dir=0;
err = snd_pcm_hw_params_get_periods_min(params, &periods_min,&dir);
dir=0;
err = snd_pcm_hw_params_get_periods_max(params, &periods_max,&dir);
printf("Periods range from %u to %u\n",periods_min, periods_max);

That will print the message: -
Periods range from 0 to 512

I thought that this should have printed: -
Periods range from 2 to 2

If my app sets the period size first, the buffer size can only be set to 
2*period size, so I would have expected the 
snd_pcm_hw_params_get_periods_max() to return 2 instead of 512.

Is this an alsa-lib bug ?

Cheers
James




static snd_pcm_hardware_t snd_audigyls_playback_hw = {
         .info =                 (SNDRV_PCM_INFO_MMAP |
                                  SNDRV_PCM_INFO_INTERLEAVED |
                                  SNDRV_PCM_INFO_BLOCK_TRANSFER |
                                  SNDRV_PCM_INFO_MMAP_VALID),
         .formats =              SNDRV_PCM_FMTBIT_S16_LE,
         .rates =                SNDRV_PCM_RATE_48000,
         .rate_min =             48000,
         .rate_max =             48000,
         .channels_min =         1,
         .channels_max =         6,
         .buffer_bytes_max =     (32*1024),
         .period_bytes_min =     64,
         .period_bytes_max =     (16*1024),
         .periods_min =          2,
         .periods_max =          2,
         .fifo_size =            0,


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

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

[Clemens Ladisch]

James Courtier-Dutton wrote:
> If the application opens the device with "plug:front".
> That will print the message: -
> Periods range from 0 to 512
>
> I thought that this should have printed: -
> Periods range from 2 to 2

Try without "plug:".


HTH
Clemens




-------------------------------------------------------
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

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

[James Courtier-Dutton]

Clemens Ladisch wrote:
> James Courtier-Dutton wrote:
> 
>>If the application opens the device with "plug:front".
>>That will print the message: -
>>Periods range from 0 to 512
>>
>>I thought that this should have printed: -
>>Periods range from 2 to 2
> 
> 
> Try without "plug:".
> 
> 
> HTH
> Clemens
> 
> 

Without the "plug:" I get
Periods range from 2 to 2

So without the "plug:", the function calls returns correctly.
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 ?

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

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

[Clemens Ladisch]

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




-------------------------------------------------------
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

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

[James Courtier-Dutton]

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