Sergei Steshenko wrote:
> -----Original Message-----
> From: klondike <franxisco1988@xxxxxxxxx>
> To: "Sergei Steshenko" <steshenko_sergei@xxxxxxx>,alsa-user@xxxxxxxxxxxxxxxxxxxxx
> Date: Tue, 1 Jul 2008 16:14:44 +0200
> Subject: which are the pieces of ALSA source code responsiblefor setting sample rate ?
>
>
>> ---------- Forwarded message ----------
>> From: klondike <franxisco1988@xxxxxxxxx>
>> Date: 2008/7/1
>> Subject: Re: which are the pieces of ALSA source code
>> responsible for setting sample rate ?
>> To: stan <ghjeold_i_mwee@xxxxxxx>
>>
>>
>> on asoundrc you can fix the rate when you set the slave:
>> slave.pcm "hw:0,0"
>> # slave {
>> # pcm "hw:0,0" # you cannot use a "plug" device here, darn.
>> # period_time 0
>> # period_size 1024 # must be power of 2
>> # buffer_size 8192 # dito. It
>> # format "S32_LE"
>> # periods 128 # dito.
>> # rate 192000 # with rate 8000 you *will* hear,
>> # if ossmix is used :)
>> # }
>>
>>
>> 2008/7/1 stan <ghjeold_i_mwee@xxxxxxx>:
>>
>>> 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.
>>>
>>>
>>>
> If I understand correctly, .asoundrc "tricks" create pseudo devices, and applications may or may not pay attention to the
> pseudo devices.
>
> I want a bullet-proof solution, i.e. I want to deprive all applications of the ability to change sample rate in HW.
>
> Again and again, I want mandated system-wide sample rate setting.
>
>
Then you are probably going to have to write the code I suggested
above. You are modifying alsa in that case to think that your sound
device has only a single rate. Any application that uses alsa will get
only that rate.
-------------------------------------------------------------------------
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
