Re: snd_pcm_hw_params_get_period_size() returning 0

[Carlos Munoz <carlos@kenati.com>]

Jaroslav Kysela wrote:

>On Mon, 3 Apr 2006, Takashi Iwai wrote:
>
>  
>
>>At Mon, 03 Apr 2006 10:46:34 -0700,
>>Carlos Munoz wrote:
>>    
>>
>>>Takashi Iwai wrote:
>>>
>>>      
>>>
>>>>At Fri, 31 Mar 2006 18:20:42 -0800,
>>>>Carlos Munoz wrote:
>>>> 
>>>>
>>>>        
>>>>
>>>>>Lee Revell wrote:
>>>>>
>>>>>   
>>>>>
>>>>>          
>>>>>
>>>>>>On Fri, 2006-03-31 at 17:00 -0800, Carlos Munoz wrote:
>>>>>>
>>>>>>
>>>>>>     
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Does 
>>>>>>>any one know why
>>>>>>>snd_pcm_hw_params_get_period_size() would be returning 0 ? Is it 
>>>>>>>something the driver did/didn't do ?
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>       
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>Argh, please disregard last message, that's not how the hw_params
>>>>>>callback works :-(
>>>>>>
>>>>>>Lee
>>>>>>
>>>>>>
>>>>>>
>>>>>>     
>>>>>>
>>>>>>            
>>>>>>
>>>>>Hi Lee,
>>>>>
>>>>>I digged further and this is what I found.
>>>>>
>>>>>snd_pcm_hw_params_get_period_size(...., int *val) does retrieve the 
>>>>>correct period size and updates val with it. However, val does not match 
>>>>>the address passed to it. I mean the caller of 
>>>>>snd_pcm_hw_params_get_period_size(.... 0x41becc) passes the address of 
>>>>>where the period size is to be stored as 0x41becc but 
>>>>>snd_pcm_hw_params_get_period_size() gets 0x7b83c0d8 and that's where it 
>>>>>puts the period size.
>>>>>
>>>>>This is on the Renesas SH7343 processor. alsa-lib is a dynamic library. 
>>>>>Should I expect the variable address be the same ?
>>>>>   
>>>>>
>>>>>          
>>>>>
>>>>No.  They must be different.  The value is stored to the original
>>>>address only when no error returns.  Unless that, a temporary variable
>>>>is used.  That's why you see two distinct addresses.
>>>>
>>>>
>>>>Takashi
>>>>
>>>>
>>>> 
>>>>
>>>>        
>>>>
>>>Hi Takashi,
>>>
>>>I understand what you are saying. However, this is not the case here. 
>>>The original address is wrong. I print the value of val (not _val) 
>>>passed to snd_pcm_hw_params_get_period_size() and it is wrong. See the code:
>>>
>>>#ifndef DOXYGEN
>>>int INTERNAL(snd_pcm_hw_params_get_period_size)(const 
>>>snd_pcm_hw_params_t *params, snd_pcm_uframes_t *val, int *dir)
>>>#else
>>>int snd_pcm_hw_params_get_period_size(const snd_pcm_hw_params_t *params, 
>>>snd_pcm_uframes_t *val, int *dir)
>>>#endif
>>>{
>>>    unsigned int _val;
>>>    printf("alsa-lib:snd_pcm_hw_params_get_period_size() - params=%p 
>>>val=%p dir=%p\n",
>>>           params, val, dir);
>>>    int err = snd_pcm_hw_param_get(params, SND_PCM_HW_PARAM_PERIOD_SIZE, 
>>>&_val, dir);
>>>    if (err >= 0)
>>>        *val = _val;
>>>
>>>    return err;
>>>}
>>>
>>>
>>>This printf shows val has an incorrect value (dir is also incorrect). I 
>>>don't think it's related to the alsa-lib but maybe a problem with our 
>>>build tool chain.
>>>      
>>>
>>OK, let me know if it turnes out to be a bug in alsa-lib :)
>>    
>>
>
>Or binutils. What does 'nm aplay | grep snd_pcm_hw_params_get_period_size' 
>show? Also, you might try to configure alsa-lib with --with-versioned=no .
>
>  
>
Hi Jaroslav,

Yes, using --with-versioned=no solved the problem. Now everything works. 
What does --with-versioned=no do ?

By the way the output of nm is the same for alsa-lib built  with and 
without the --with-versioned=no switch.

nm aplay | grep snd_pcm_hw_params_get_period_size
         U snd_pcm_hw_params_get_period_size@@ALSA_0.9.0rc4

Thanks,


Carlos


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642