-----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.
> >
> >
> > -------------------------------------------------------------------------
> > 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
> >
>
> -------------------------------------------------------------------------
> 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
>
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.
Thanks,
Sergei.
-------------------------------------------------------------------------
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
