snd_pcm_hw_params_get_period_size() returning 0

snd_pcm_hw_params_get_period_size() returning 0

[Carlos Munoz]

Hi all,

I tested my new driver with a simple application I wrote. I can play and 
record pcm files with no problem. However, I'm unable to get aplay to 
work. aplay just hangs. I was able to trace it to aplay.c:playback_go(). 
aplay is stuck in the while loop. After closer examination it turns out 
that the reason is because previously 
snd_pcm_hw_params_get_period_size() had set the period size to 0. 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 ?

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

Re: snd_pcm_hw_params_get_period_size() returning 0

[Lee Revell]

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

Your hw_params callback should have set this to a correct value, try
adding printks.

Lee



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

Re: snd_pcm_hw_params_get_period_size() returning 0

[Lee Revell]

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



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

Re: snd_pcm_hw_params_get_period_size() returning 0

[Carlos Munoz]

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 ?

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

Re: snd_pcm_hw_params_get_period_size() returning 0

[Takashi Iwai]

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


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

Re: snd_pcm_hw_params_get_period_size() returning 0

[Carlos Munoz]

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.

Thanks,


Carlos Munoz


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

Re: snd_pcm_hw_params_get_period_size() returning 0

[Takashi Iwai]

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


Takashi


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

Re: snd_pcm_hw_params_get_period_size() returning 0

[Jaroslav Kysela]

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 .

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


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

Re: snd_pcm_hw_params_get_period_size() returning 0

[Carlos Munoz]

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

Re: snd_pcm_hw_params_get_period_size() returning 0

[Carlos Munoz]

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