maximum tolerable sampling frequency difference for a driver

maximum tolerable sampling frequency difference for a driver

[chri]

Let's say that the driver cannot set the exact sampling frequency
asked via hwparms but something near (because of the granularity of
the result of the clock division). What is the maximum difference that
should be accepted (in Hz or in %)? I guess that there are 2 factors
playing a role:

1) if the frequency is too different then the upper layers report a
undeflow/overflow

2) the sound just doesn't sound good (just a bit too presto or too adagio)

So what difference should be accepted instead of returning -EINVAL?

Thanks,

-- 
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."

Re: maximum tolerable sampling frequency difference for a driver

[Mark Brown]

On Tue, Nov 11, 2008 at 05:17:00PM +0100, chri wrote:
> Let's say that the driver cannot set the exact sampling frequency
> asked via hwparms but something near (because of the granularity of
> the result of the clock division). What is the maximum difference that
> should be accepted (in Hz or in %)? I guess that there are 2 factors
> playing a role:

It's relatively application-specific - it'll depend on things like how
accurate the clocks were in the first place and what the sound is being
used for (system beeps are going to tolerate a lot more than something
doing audiophile quality stuff).

> So what difference should be accepted instead of returning -EINVAL?

If this is for the Samsung boards you've been posting patches for then a
few percent should be OK most of the time.

Re: maximum tolerable sampling frequency difference for a driver

[Clemens Ladisch]

chri wrote:
> Let's say that the driver cannot set the exact sampling frequency
> asked via hwparms ...

This never happens.

The driver tells the ALSA framework what frequencies it supports, either
by setting individual bits in the .rates field, or by installing a
constraint by calling snd_pcm_hw_constraint_list() or some other of the
constraint functions when the device is opened.  ALSA then makes sure
that the driver always gets values in hw_params that meet these
constraints.

When an application requests a frequency that is not supported by the
device, it is the application that must decide whether the actual
frequency is acceptable.


HTH
Clemens

Re: maximum tolerable sampling frequency difference for a driver

[Mark Brown]

On Wed, Nov 12, 2008 at 04:35:44PM +0100, Clemens Ladisch wrote:

> When an application requests a frequency that is not supported by the
> device, it is the application that must decide whether the actual
> frequency is acceptable.

In theory.  In practice few applications have substantial tolerance for
this and in many situations the cost of dealing with it (such as doing
soft conversion) is worse than a small error.

Re: maximum tolerable sampling frequency difference for a driver

[christian pellegrin]

On Wed, Nov 12, 2008 at 4:46 PM, Mark Brown <broonie@sirena.org.uk> wrote:
> On Wed, Nov 12, 2008 at 04:35:44PM +0100, Clemens Ladisch wrote:
>
>> When an application requests a frequency that is not supported by the
>> device, it is the application that must decide whether the actual
>> frequency is acceptable.
>
> In theory.  In practice few applications have substantial tolerance for
> this and in many situations the cost of dealing with it (such as doing
> soft conversion) is worse than a small error.
>

I see, thank you both for the answer.

-- 
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."