Re: snd_pcm_hw_params_get_period_size() returning 0

[Carlos Munoz <carlos@kenati.com>]

Carlos Munoz wrote:

> 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
>
Well... it's not as perfect as I thought. To get it to work, I need to 
link the alsa-utils (aplay) with an alsa-lib that has versioned enabled 
(--with-versioned=no is not passed to configure). But then, the run time 
alsa-lib must be one compiled with '--with-versioned=no'. Does anyone 
know what's going on ?

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