Re: which are the pieces of ALSA source code responsible for setting sample rate ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sergei Steshenko wrote:
> -----Original Message-----
> From: stan <ghjeold_i_mwee@xxxxxxx>
> To: Sergei Steshenko <steshenko_sergei@xxxxxxx>
> Date: Tue, 01 Jul 2008 06:50:50 -0700
> Subject: Re:  which are the ieces of ALSA source code responsiblefor setting sample rate ?
>
>   
>> Sergei Steshenko wrote:
>>     
>>> Hello All,
>>>
>>> as already known, I am one of those who advocate the possibility to mandate sample rate and not let applications to change it.
>>>
>>> I think a possible, though ugly, solution is like this:
>>>
>>> 1) to locate pieces of ALSA code responsible for setting sample rate;
>>> 2) to change (in my own copy) the pieces so they would know only one sample rate;
>>> 3) to compile and install the modified code.
>>>
>>> I also think that I would like to have an ALSA snapshot per sample rate and will uninstall/install the snapshot I need
>>> - most likely the two most used will be for 44100Hz and 48000Hz sample rates.
>>>
>>> So, which are the pieces ?
>>>
>>> Thanks,
>>>   Sergei.
>>>
>>>   
>>>       
>> Why not write a small program that calls the alsa interface and sets the 
>> rate to whatever you want.  This must be how the applications you are 
>> concerned about are doing it.  The api call is snd_pcm_hw_params_set_rate.
>>
>>  From the alsa-project api
>>
>> int snd_pcm_hw_params_set_rate 	( 	snd_pcm_t 
>> <http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#gb5676348e7618b444e28907607660cef> 
>> *  	/pcm/,
>>
>> 	
>> 	snd_pcm_hw_params_t 
>> <http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#g232a2e2b6bb7bb2dca2885eec2e095b3> 
>> *  	/params/,
>>
>> 	
>> 	unsigned int  	/val/,
>>
>> 	
>> 	int  	/dir/ 	 
>>
>> 	) 	
>> 	
>> 	
>>
>> Restrict a configuration space to contain only one rate.
>>
>> *Parameters:*
>>
>>     	/pcm/  	PCM handle
>>
>>     	/params/  	Configuration space
>>
>>     	/val/  	approximate rate
>>
>>     	/dir/  	Sub unit direction
>>
>> *Returns:*
>>     0 otherwise a negative error code if configuration space would
>>     become empty
>>
>> Wanted exact value is <,=,> val following dir (-1,0,1)
>>
>>
>>     
>
> As was many times explained in this list, applications can change the rate.
>
> So, if I write and run such a program, and then start an application that can change sample rate, it will, and this is what I want
> to avoid.
>
> I was thinking of modifying the piece of code which reports audio card capabilities - if such a piece exists.
>
> For each version (for each sample rate) the piece of code will report just _one_ sample rate, so hopefully the rest of ALSA won't
> even try to set a different sample rate.
>
> Thanks,
>   Sergei.
>
>   
I remember seeing the rates hard coded somewhere in the alsa tree.  I 
can't remember if it was in the lib code or the driver code.  You could 
have alternate versions of the routine with those rates.  Load the 
alternate when you want to lock the rate.  Just follow the set...rate 
call above to see where it is looking, and change the return from that 
to only return the rate you want.

There might be another way that is simpler to do this that someone more 
knowledgeable than me can describe.  I'm thinking of the configuration 
data or in an asoundrc.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user

[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux