mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* i810_audio bug (?)
@ 2003-09-17 10:42 Reza Naima
  2003-09-17 13:22 ` Alan Cox
  0 siblings, 1 reply; 2+ messages in thread
From: Reza Naima @ 2003-09-17 10:42 UTC (permalink / raw)
  To: Kernel List


When I pass audio_samplerate = 32000 to 

       ioctl(afd, SNDCTL_DSP_SPEED, &audio_samplerate)

it changes my audio_sample rate from 32000 to 31627.

Now, this is causing problems with my downstream apps so I did some
investigating. Looking into i810_set_adc_rate() in i810_audio.c, 
there is some wierd math going on..

1) first, the original rate (32000) is converted to a new rate ..

	rate = (rate * clocking)/48000

	where clocking, in my case, is 48566. 

2) this new value is fed into newrate=ac97_set_adc_rate() which returns 
   the orignal sampling rate value (32000).  This number is then modified
   by the ratio

	dmabuf->rate = newrate * 48000 / clocking.

3) This results in the value 31627 that I'm seeing.  Now, is this the
   actual sample rate, or some internal value used to generate a 32000kbps
   sample rate?  If so, is it perhaps a bug that dmabuf->rate is being
   returned rather than newrate?


Thanks,
-Reza




^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: i810_audio bug (?)
  2003-09-17 10:42 i810_audio bug (?) Reza Naima
@ 2003-09-17 13:22 ` Alan Cox
  0 siblings, 0 replies; 2+ messages in thread
From: Alan Cox @ 2003-09-17 13:22 UTC (permalink / raw)
  To: Reza Naima; +Cc: Linux Kernel Mailing List

On Mer, 2003-09-17 at 11:42, Reza Naima wrote:
> 1) first, the original rate (32000) is converted to a new rate ..
> 
> 	rate = (rate * clocking)/48000
> 
> 	where clocking, in my case, is 48566. 

We measure the bitrate of the codec, because a lot of them are clocked
at odd frequencies not the official 48000 (I gather it saves parts). We
then adjust the rate to get what should be the right one.

> 3) This results in the value 31627 that I'm seeing.  Now, is this the
>    actual sample rate, or some internal value used to generate a 32000kbps
>    sample rate?  If so, is it perhaps a bug that dmabuf->rate is being
>    returned rather than newrate?

We take the rate you want, shift it for the 48Khz clock offset then ask
the codec to do that rate. ac97_set_dac_rate returns the value the codec
actually used (which may be quite different), and we then bend that back
the other way for the clocking.

So in your case it is going

         I want 32000
         I need to ask the codec for an adjusted value
         Write codec
         Read codec
         Codec replies 32000 (ie it doesnt do a full range of clocking)
         We realise it means you get 31627

Btw - from my experience with video playback audio clocks are +/- 5%
some of the time even when you ask for a rate it can do so software
needs to be fairly adaptive to such things.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-09-17 13:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-17 10:42 i810_audio bug (?) Reza Naima
2003-09-17 13:22 ` Alan Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®