[alsa-devel] Dealing with 'siamesed' DAC sample rates
Hello All;
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.
This was probably a reasonable choice with respect to what the typical end user might want to do, but i have to support content at 44100, not 48K.
So, here's the example of setting the front dac and getting the other dac's changed:
jutz-gntdv alsa-kernel # echo 0x2c 0xac44> /proc/asound/card0/codec97#0/ac97#0-0+regs jutz-gntdv alsa-kernel # cat /proc/asound/card0/codec97#0/ac97#0-0+regs| grep ac44 0:2c = ac44 0:2e = ac44 0:30 = ac44
The *problem* seems to be that alsa wants to *set* the register even tho the value that's in the register is already the right value (44100=ac44)
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?
Here's the problem that i am trying to solve:
Here's the output of speaker-test on the front (hw:0,0) and surround (hw:0,1) devices.
[root@DMX-116248 jutz]# ./speaker-test -c2 -Dhw:0,0 -r 44100
speaker-test 1.0.14rc2
Playback device is hw:0,0 Stream parameters are 44100Hz, S16_LE, 2 channels Using 16 octaves of pink noise Rate set to 44100Hz (requested 44100Hz) Buffer size range from 16 to 16384 Period size range from 8 to 8192 Using max buffer size 16384 Periods = 4 was set period_size = 4096 was set buffer_size = 16384 0 - Front Left ^X [root@DMX-116248 jutz]# ./speaker-test -c2 -Dhw:0,1 -r 44100
speaker-test 1.0.14rc2
Playback device is hw:0,1 Stream parameters are 44100Hz, S16_LE, 2 channels Using 16 octaves of pink noise ALSA ERROR hw_params: set (RATE) value = 44100 : Invalid argument ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 48000 PERIOD_TIME: (166 170667) PERIOD_SIZE: [8 8192] PERIOD_BYTES: [32 32768] PERIODS: [2 127] BUFFER_TIME: (333 341334) BUFFER_SIZE: [16 16384] BUFFER_BYTES: [64 65536] TICK_TIME: 1000 Rate 44100Hz not available for playback: Invalid argument Setting of hwparams failed: Invalid argument [root@DMX-116248 jutz]#
Does anybody have any suggestions?
tnx!
johnu
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?
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 changed.
It seems like the right thing to do would be to check if any other DACs are in use. 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.
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.
Hi Trent;
tnx for your input!
On Thu, 30 Aug 2007 12:28:10 -0700 (PDT) "Trent Piepho" xyzzy@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 detail :-)
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 changed.
mmhmm
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 :-(
tnx!
johnu
On 8/30/07, John Utz john.utz@dmx.com wrote:
Hello All;
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.
I don't think the driver should expose separate front and rear PCMs for this device as they cannot be controlled independently at the HW level.
Lee
Hi Lee;
On Thu, 30 Aug 2007 15:47:56 -0400 "Lee Revell" rlrevell@joe-job.com wrote:
On 8/30/07, John Utz john.utz@dmx.com wrote:
Hello All;
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.
I don't think the driver should expose separate front and rear PCMs for this device as they cannot be controlled independently at the HW level.
That's a good point.
However, they can be controlled independently for everything *other* than sample rate.
I'll have to ponder your point carefully and take it into consideration for what i decide to do when i push out a patch (hopefully one that will get accepted this time :-) )
But for our *product platform* the independent control is a must have, so i am kinda stuck solving this problem somehow, someway.
tnx!
johnu
Lee
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 side. The driver knows which PCM (sub)stream is opened, so you can add hw_params constraint appropriately.
Takashi
Hi Takashi;
tnx so much for your suggestion, however, 'tis a bit more complicated methinks....
On Fri, 31 Aug 2007 13:20:29 +0200 "Takashi Iwai" tiwai@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 side.
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.
Dang.
Takashi
At Fri, 31 Aug 2007 09:37:14 -0700, John Utz wrote:
Hi Takashi;
tnx so much for your suggestion, however, 'tis a bit more complicated methinks....
On Fri, 31 Aug 2007 13:20:29 +0200 "Takashi Iwai" tiwai@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 side.
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?
The problem is that it's the controller who handles DMA and decides which stream to play. AC97 is just a slave, which does the DA/AD conversion. So, what you have to take care is rather the controller side.
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?
VIA82xx can't control the multi-channel streams in separate DMAs, AFAIK. The multi-stream mode is for the single-codec and via82xx itself mixes the streams. Thus, it's neither for multi codecs nor multi-channel.s In the multi-channel mode, it can handle only one stream with multiple channels. So, you cannot start/stop the stream for each channel/codec separately.
Takashi
participants (4)
-
John Utz -
Lee Revell -
Takashi Iwai -
Trent Piepho