[alsa-devel] maximum tolerable sampling frequency difference for a driver
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,
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.
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
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.
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.
participants (4)
-
chri -
christian pellegrin
-
Clemens Ladisch -
Mark Brown