[alsa-devel] Dealing with 'siamesed' DAC sample rates
john.utz at dmx.com
Thu Aug 30 21:42:10 CEST 2007
tnx for your input!
On Thu, 30 Aug 2007 12:28:10 -0700 (PDT)
"Trent Piepho" <xyzzy at speakeasy.org> wrote:
> On Thu, 30 Aug 2007, John Utz wrote:
> > The thrice cursed vt1618 has the DAC sample rates regs for the
> > Surround and Center/LFE DAC's (0x2E, 0x30) set to RO and locked to
> > whatever rate that the Front DAC is set to.
> > So, i *think* that i want to change my driver code to poke the value
> > for setting hw:0,1 (should be reg 0x2e) into 0x2c instead? or am i
> > barking up the wrong tree?
> Wouldn't that mean if you are using hw:0,0 at 48kHz and then tried to
> use hw:0,1 at 44.1kHz, that hw:0,0 would switch sample rates too, in
> the middle of playback?
Yes, absolutely true, i wondered if somebody would notice that
> Of course, this would go the other way too. If you're using hw:0,1
> at 48k and then start hw:0,0 at 44.1k, the sample rate of hw:0,1 gets
> 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?
> If any are, the sample rate is locked to whatever
> it is set at. If they aren't, then you can change all the sample
> rates by writing to the 0x2e register.
*How* would i do that? that's the nub of my problem, unlike volume and
jack settings, the 'build_ops' structure doesnt present a place to put
a 'sample rate change' callback.
So my problem is that i cant figure out *where* to do this in a way to
do this in patch_vt1618(), i only see ways to hack it in to the
generic portions of the driver and that's a pretty terrible idea.
> When the device is opened, you check if any other DACs are in use
> too. If any are, the hw constraints are set to the current sample
> rate. If none are, then the sample rate constraint can be any
> supported rate.
Same problem holds.
tnx for your suggestions tho, if you have any further thoughts i'd be
interested in hearing them from you or anybody else because this issue
is going to wreck my chances of taking the last us summer holiday
weekend off :-(
More information about the Alsa-devel