New Aztech Sound Galaxy driver

Hi Takashi.

This is a new driver for Aztech Sound Galaxy ISA soundcards based on the AZT1605 and AZT2316 chipsets. It's constructed as two seperate drivers for either chipset generated from the same source file, with (very) minimal ifdeffery.

The drivers check the SB DSP version to decide if they are being loaded for the right chip. AZT1605 returns 2.1 by default, and AZT2316 3.1. This isn't full-proof as the DSP version can actually be set through software but it's close enough -- as far as I've been able to see, the DSP version can not be stored in the EEPROM and the cards will therefore startup with the defaults.

This distinction could (with the same success rate) also be used to decide which chip we're looking at at runtime meaning a single, merged driver is also an option but I feel it's actually nicer this way. A merged driver would have to postpone translating the passed in resource values to the card configuration until it knew which one it was looking at and would need to postpone erring out on mpu_irq=10 for azt1605 and mpu_irq=3 for azt2316. If you differ, I will merge them, but I'd rather keep them seperate.

The drivers have been tested on various cards. For snd-azt1605:

FCC-ID I38-MMSN811: Aztech Sound Galaxy Nova 16 Extra FCC-ID I38-MMSN822: Aztech Sound Galaxy Pro 16 II

and for snd-azt2316:

FCC-ID I38-MMSN824: Aztech Sound Galaxy Pro 16 AB FCC-ID I38-MMSN826: Trust Sound Expert DeLuxe Wave 32 (05201) FCC-ID I38-MMSN830: Trust Sound Expert DeLuxe 16+ (05202) FCC-ID I38-MMSN847: Trust Sound Expert DeLuxe Wave 32-3D (06301) FCC-ID I38-MMSN852: Aztech Sound Galaxy Waverider Pro 32-3D

I38-MMSN826 is also known as "Aztech Sound Galaxy Waverider 32+".

All cards work fully -- full-duplex PCM, MIDI and FM. Full-duplex is a little flaky on some.

I38-MSN811 tends to not work in full duplex, but sometimes does with the highest success rate being achieved when you first start the capture and then a playback instead of the other way around (it's a CS4231-KL codec).

The cards with an AD1845XP codec (my I38-MMSN826 and one of my I38-MMSN830s) are also somewhat duplex-challenged. Sometimes full-duplex works, sometimes not and this varies from try to try. This seems likely to be a timing problem somewhere inside cs4231-lib.

I38-MMSN826 has an additional "ICS2115 WaveFront" wavetable synth onboard that isn't supported yet. The wavetable synths on I38-MMSN847 and I38-MMSN852 are wired directly to the standard MPU-401 UART and the AUX1 input on the codec and work without problem.

CD-ROM audio on the cards is routed to the codec "Line" input, Line-In to its Aux input, and FM/Wavetable to its AUX1 input. I did not rename the controls due to the capture source enumeration: I see that capture-source overrides are hardcoded in cs4231-lib and this is just too ugly to live.

Versus the old snd-sgalaxy driver, these drivers add support for the models without a configuration EEPROM (common), full-duplex, MPU-401 UART and OPL3. In the future they should grow support for that ICS2115 WaveFront synth on 826 and an hwdep interface to write to the EEPROM on the models that have one.

lib.c was split off in preparation of having snd-azt2320 use it as well and generally containing non soundgalaxy specific code that might at some point make it into an isa/lib.c or something. It's tiny, so it's not constructed as a helper module but simply compiled into both drivers.

[ all of the above is intended as a changelog ]

Given that they are new drivers with new names, they shouldn't disturb anything and can as far as I'm concerned make 1.0.15 but if you feel it's too late (and/or don't want the two seperate drivers), so be it. I can also submit a next patch removing the old sgalaxy driver now or just wait with that one...

Patch is against current alsa-kernel hg.

Rene.

diff -r 0687faf0e009 Documentation/ALSA-Configuration.txt
@@ -296,6 +296,74 @@ Prior to version 0.9.0rc4 options had a 
     Note: Some ALSA mixer applications don't handle the SPDIF sample rate 
            control correctly. If you have problems regarding this, try
            another ALSA compliant mixer (alsamixer works).
+
+  Module snd-azt1605
+  ------------------
+
+    Module for Aztech Sound Galaxy soundcards based on the Aztech AZT1605
+    chipset.
+
+    port	- port # for BASE (0x220,0x240,0x260,0x280)
+    wss_port	- port # for WSS (0x530,0x604,0xe80,0xf40)
+    irq		- IRQ # for WSS (7,9,10,11)
+    dma1	- DMA # for WSS playback (0,1,3)
+    dma2	- DMA # for WSS capture (0,1), -1 = disabled (default)
+    mpu_port	- port # for MPU-401 UART (0x300,0x330), -1 = disabled (default)
+    mpu_irq	- IRQ # for MPU-401 UART (3,5,7,9), -1 = disabled (default)
+    fm_port	- port # for OPL3 (0x388), -1 = disabled (default)
+
+    This module supports multiple cards. It does not support autoprobe: port,
+    wss_port, irq and dma1 have to be specified. The other values are
+    optional.
+
+    "port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240)
+    or the value stored in the card's EEPROM for cards that have an EEPROM and
+    their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can
+    be choosen freely from the options enumerated above.
+
+    If dma2 is specified and different from dma1, the card will operate in
+    full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to
+    enable capture since only channels 0 and 1 are available for capture.
+
+    Generic settings are "port=0x220 wss_port=0x530 irq=10 dma1=1 dma2=0
+    mpu_port=0x330 mpu_irq=9 fm_port=0x388".
+
+    Whatever IRQ and DMA channels you pick, be sure to reserve them for
+    legacy ISA in your BIOS.
+
+  Module snd-azt2316
+  ------------------
+
+    Module for Aztech Sound Galaxy soundcards based on the Aztech AZT2316
+    chipset.
+
+    port	- port # for BASE (0x220,0x240,0x260,0x280)
+    wss_port	- port # for WSS (0x530,0x604,0xe80,0xf40)
+    irq		- IRQ # for WSS (7,9,10,11)
+    dma1	- DMA # for WSS playback (0,1,3)
+    dma2	- DMA # for WSS capture (0,1), -1 = disabled (default)
+    mpu_port	- port # for MPU-401 UART (0x300,0x330), -1 = disabled (default)
+    mpu_irq	- IRQ # for MPU-401 UART (5,7,9,10), -1 = disabled (default)
+    fm_port	- port # for OPL3 (0x388), -1 = disabled (default)
+
+    This module supports multiple cards. It does not support autoprobe: port,
+    wss_port, irq and dma1 have to be specified. The other values are
+    optional.
+
+    "port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240)
+    or the value stored in the card's EEPROM for cards that have an EEPROM and
+    their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can
+    be choosen freely from the options enumerated above.
+
+    If dma2 is specified and different from dma1, the card will operate in
+    full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to
+    enable capture since only channels 0 and 1 are available for capture.
+
+    Generic settings are "port=0x220 wss_port=0x530 irq=10 dma1=1 dma2=0
+    mpu_port=0x330 mpu_irq=9 fm_port=0x388".
+
+    Whatever IRQ and DMA channels you pick, be sure to reserve them for
+    legacy ISA in your BIOS.
 
   Module snd-azt2320
   ------------------

diff -r 0687faf0e009 isa/Kconfig
@@ -76,6 +76,32 @@ config SND_ALS100
 	  To compile this driver as a module, choose M here: the module
 	  will be called snd-als100.
 
+config SND_AZT1605
+	tristate "Aztech AZT1605 Driver"
+	depends on SND
+	select SND_CS4231_LIB
+	select SND_MPU401_UART
+	select SND_OPL3_LIB
+	help
+	  Say Y here to include support for Aztech Sound Galaxy cards
+	  based on the AZT1605 chipset.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called snd-azt1605.
+
+config SND_AZT2316
+	tristate "Aztech AZT2316 Driver"
+	depends on SND
+	select SND_CS4231_LIB
+	select SND_MPU401_UART
+	select SND_OPL3_LIB
+	help
+	  Say Y here to include support for Aztech Sound Galaxy cards
+	  based on the AZT2316 chipset.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called snd-azt2316.
+
 config SND_AZT2320
 	tristate "Aztech Systems AZT2320"
 	depends on SND && PNP && ISA

diff -r 0687faf0e009 isa/Makefile
@@ -26,5 +26,5 @@ obj-$(CONFIG_SND_SGALAXY) += snd-sgalaxy
 obj-$(CONFIG_SND_SGALAXY) += snd-sgalaxy.o
 obj-$(CONFIG_SND_SSCAPE) += snd-sscape.o
 
-obj-$(CONFIG_SND) += ad1816a/ ad1848/ cs423x/ es1688/ gus/ opti9xx/ \
+obj-$(CONFIG_SND) += ad1816a/ ad1848/ cs423x/ es1688/ galaxy/ gus/ opti9xx/ \
 		     sb/ wavefront/

diff -r 0687faf0e009 isa/galaxy/Makefile
@@ -0,0 +1,10 @@
+#
+# Makefile for ALSA
+# Copyright (c) 2001 by Jaroslav Kysela <[email protected]>
+#
+
+snd-azt1605-objs := azt1605.o lib.o
+snd-azt2316-objs := azt2316.o lib.o
+
+obj-$(CONFIG_SND_AZT1605) += snd-azt1605.o
+obj-$(CONFIG_SND_AZT2316) += snd-azt2316.o

_______________________________________________
Alsa-devel mailing list
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

At Thu, 20 Sep 2007 14:20:01 +0200,

This doesn't work if both modules can be loaded at the same time in theory. You'll get symbol crashes. To avoid this, make all functions static and include from both, or make it a library module.

Also, avoid symbols like __xxx() as much as possible. These are basically for compiler internals, so this might have problems in the future version of compiler.

Otherise the code look fine, so far.

Well, I feel we can work better on this after 1.0.15. RC standas for release-candiate, after all :)

Thanks,

Takashi

Hrmmpf. Yes.

Sure. With new drivers, you can sort of by definition not be introducing regressions (well, other than of the type above, that is...) but oh well, hardly any magic to 1.0.15. I'll check what my older I38-MMSN803 needs and get that one in as well then and also redo azt2320 using some common code.

I have a question about that by the way: ALSA ISA-PnP drivers today allow to manually set resource values through specifying them as module parameters and I've always really disliked that as a rather major layering violation.

With respect to the high-level interface, ISA-PnP isn't all that different from PCI and as with PCI the expected use is not specifying parameters and just having the system pick/tell you which resources it's using. Now with ISA-PnP you _can_ actually change them but I very much believe that in the few odd cases where someone might actually want to do that, it should be done not in soundcard drivers but at the correct layer (the PnP layer allows to echo values into sysfs for this). Especially in mixed legacy/pnp drivers, I feel that the current setup is mostly just confusing and as said, a layering violation.

As such -- would you terribly mind if I not put in the pnp_resource_change() stuff in rewritten and/or cleaned up ISA-PnP drivers?

Rene.

At Sat, 22 Sep 2007 08:06:36 +0200,

I have no particular like/dislike about the parameters in the ALSA driver side. It's sometimes useful, but something beyond the concept of PnP. After all, these parameters have been mostly never used for PnP, AFAIK.

I thought Jarolsav wanted to keep this style...
So, I'd like to hear his comments before starting the clean-up works.

thanks,

Takashi

I have tested your driver on this cards and it works for me (no suprise). I have no tested full-duplex recording.

Just two minor issues below.

Thanks for testing and I've indeed been careful with testing on all cards. The end result doesn't really show it but it's been a rather long series of eliminating steps that the original DOS drivers took (with small differences between all the types -- but it turned out it seems that most all of it was only needed for the "native" SB mode, not WSS).

Should work fine on the 852.

Well, I am, but Jaroslav can have the copyright...

The makefile is wholy trivial. In fact, trivial enough to not even _be_ copyrightable in itself and only the ALSA built system as a whole could count as copyrightable, I'd say. Keeping that under one single copyright might make some things easier.

Or not. I don't care. He can have it ;-)

This is by design. I have a set_mode() function, which takes a "mode" argument and the fact that I've defined them to be the command used to switch _to_ that mode can be seen just as a convenience thing. And the SB8MODE one is retained as documentation (going back to SB8MODE gets you floating volumes and the like though -- would need to configure the thing completely to be able to do that right, so I don't).

Otherwise, since I was too late for 1.0.15 anyway, things will see a further splitup into a library module I guess. My "NX Pro 16" (I38-MMSN803) and AZT2320 cards want some of it as well.

Rene.