Skip to contentSkip to conversation

Envy24HT

PATCH In review James Stafford 3 participants 6 messages Nov 24, 2002 – Dec 4, 2002

lore
Share & tools
lore
#0 lore raw

Has anyone started work on a driver for the VIA VT1724 (alias Envy24HT)?

The company I work for are planning to release a PC104+ card based on this chipset (paired with the VT1616) in the very near future so I have access to one of the evaluation kits from VIA.

If noone else is working on a driver, I may be able to persuade my boss to allow me to work on it. However, my knowledge of the architecture of this chip and audio hardware in general is currently quite limited.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

#1 lore raw
Quoted 9 lines · James Stafford

Has anyone started work on a driver for the VIA VT1724 (alias Envy24HT)?

The company I work for are planning to release a PC104+ card based on this chipset (paired with the VT1616) in the very near future so I have access to one of the evaluation kits from VIA.

If noone else is working on a driver, I may be able to persuade my boss to allow me to work on it. However, my knowledge of the architecture of this chip and audio hardware in general is currently quite limited.

It's possible to add the support to the ICE1712 driver for this new chip, but it's difficult without hardware.

Jaroslav

-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

#2 lore raw
Quoted 8 lines · you
Quoted 6 lines · James Stafford

Has anyone started work on a driver for the VIA VT1724 (alias Envy24HT)?

The company I work for are planning to release a PC104+ card based on this chipset (paired with the VT1616) in the very near future so I have access to one of the evaluation kits from VIA.

Quoted 6 lines
Quoted 3 lines

If noone else is working on a driver, I may be able to persuade my boss to allow me to work on it. However, my knowledge of the architecture of this chip and audio hardware in general is currently quite limited.

It's possible to add the support to the ICE1712 driver for this new chip, but it's difficult without hardware.

I have now modified the ICE1712 driver downloaded from the CVS on 26th November to add basic support for the Envy24HT. I will tidy the code up and hopefully send a patch by the weekend.

-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en

#3 lore raw

PATCH 1/1 Envy24HT

Attached are two patches that add basic Envy24HT support to the ICE1712 driver and VT1616 to the AC97 codec driver. They were made against the cvs from today.

Issues:
Quote from VT1616 data sheet: "The VT1616 powers up with pins 39 and 41 assigned to the Front channel DACs as described in the 2.2 specification. When this bit is to “0”, the output pins get assigned to the Rear stereo DAC pair with an independent volume control."
The reference design uses pins 39 and 41 for the left and right rear outputs. I have added a control to set this bit to 0 but the default is 1. Should a patch function be used to set the default to 0?

When using applications such as MPlayer and ac3dec, the centre/lfe and rear outputs are swapped so that the data for the rear comes out of centre/lfe and vice versa. Is there something I have missed here?

Todo:
Capture has not been tested
Add support for rates of 176.4 KHz and 192KHz
Add support for internal S/PDIF transmitter and MPU-401
Fix the Fifo error interrupt handling.
Possibly add support for Envy24HT specific options to the envy24control program

#4 lore raw
Quoted 4 lines · James Stafford

Attached are two patches that add basic Envy24HT support to the ICE1712 driver and VT1616 to the AC97 codec driver. They were made against the cvs from today.

Quoted 8 lines

Issues:
Quote from VT1616 data sheet: "The VT1616 powers up with pins 39 and 41 assigned to the Front channel DACs as described in the 2.2 specification. When this bit is to �0�, the output pins get assigned to the Rear stereo DAC pair with an independent volume control."
The reference design uses pins 39 and 41 for the left and right rear outputs. I have added a control to set this bit to 0 but the default is 1. Should a patch function be used to set the default to 0?

I think that the default should be left in the AC97 code and write the appropriate configuration after snd_ac97_mixer() call when you detect your hardware and VT1616 codec.

Quoted 3 lines

When using applications such as MPlayer and ac3dec, the centre/lfe and rear outputs are swapped so that the data for the rear comes out of centre/lfe and vice versa. Is there something I have missed here?

We send data in this order: channel0,1 = front; channel2,3 = rear; channel4,5 = center/lfe ; if your hardware has swapped some stereo paths, you need to swap channels in software - see alsa-lib/src/conf/cards/ICH.conf - ICH.pcm.surround51.0 {} section

I've applied your patch and fixed one missing update in ice1712.h. Also, the driver id is changed in CVS.

Jaroslav

-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs

-------------------------------------------------------
This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en

#5 lore raw
Quoted 3 lines · you

I think that the default should be left in the AC97 code and write the appropriate configuration after snd_ac97_mixer() call when you detect your hardware and VT1616 codec.

I have added a build_controls function in the amp.c file which sets the relavent ac97 register. Is this the correct way to do this?

Quoted 4 lines

We send data in this order: channel0,1 = front; channel2,3 = rear; channel4,5 = center/lfe ; if your hardware has swapped some stereo paths, you need to swap channels in software - see alsa-lib/src/conf/cards/ICH.conf - ICH.pcm.surround51.0 {} section

Once I have a conf file, what do I do with it and how do I use it?

As a test, I added

pcm.ice1724 {
	type plug
	ttable.0.0 1
	ttable.1.1 1
	ttable.2.4 1
	ttable.3.5 1
	ttable.4.2 1
	ttable.5.3 1
	slave.pcm {
		type hw
		card 0
		device 0
	}
}

to my ~/.asoundrc file.
The channels were then routed correctly when using the "ice1724" device.

-------------------------------------------------------
This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en