[alsa-devel] Dealing with 'siamesed' DAC sample rates
john.utz at dmx.com
Fri Aug 31 18:37:14 CEST 2007
tnx so much for your suggestion, however, 'tis a bit more complicated
On Fri, 31 Aug 2007 13:20:29 +0200
"Takashi Iwai" <tiwai at suse.de> wrote:
> At Thu, 30 Aug 2007 12:42:10 -0700,
> John Utz wrote:
> > > It seems like the right thing to do would be to check if any other
> > > DACs are in use.
> > perhaps, but i dont think that there is a 'DAC IN USE' function. Are
> > you aware of one?
> Not in the ac97_codec side.
> Usually the rate-lock over streams is implemented in the controller
Ok, but in the case of the VT1618 it's implemented on the codec itself
and i have no choice.
With that in mind, is the fact that it's usually done on the controller
side relevant? Does this chip fact modify your thoughts?
So, by controller, do you mean the via8237 (via82xx) side?
I had pondered doing it there, but that would require the via82xx code
to know something about the codec that it's controlling and that code
at present seems to know nothing about the child codecs, how would i
get the codec ID value back to the via82xx code in order for it to do
any decision making?
> The driver knows which PCM (sub)stream is opened, so you can
> add hw_params constraint appropriately.
This seems like a very good hint that i will pursue.
But it will be difficult to implement at this moment because i am
completely clueless as to how to let the via82xx stuff know that it's
controlling a vt1618 (all the other codecs (vt1617, vt1616) evidently
dont have this little idiosyncracy.
More information about the Alsa-devel