New Aztech Sound Galaxy driver.

Good day.

This is not being submitted yet...

This is a new driver for Aztech Sound Galaxy soundcards. At the moment, it supports all AZT2316A/R based cards which make up the bulk of SG cards. It's been tested and found to be working with:

1. FCC-ID I38-MMSN824: Aztech Sound Galaxy Pro 16 AB
2. FCC-ID I38-MMSN826: Aztech Sound Galaxy Waverider 32+
3. FCC-ID I38-MMSN830: Trust Sound Expert DeLuxe 16+
4. FCC-ID I38-MMSN847: Trust Sound Expert DeLuxe Wave 32-3D
5. FCC-ID I38-MMSN852: Aztech Sound Galaxy Waverider Pro 32-3D

where:

1. I38-MMSN824 = AZT2316A + CS4248-KL, without EEPROM
2. I38-MMSN826 = AZT2316A + AD1845XP, with EEPROM
3. I38-MMSN830 = AZT2316A + CS4248-KL, without EEPROM, and some cards:

                 AZT2316A + AD1845-XP, without EEPROM

4. I38-MMSN847 = AZT2316R + CS4231A-KL, with EEPROM
5. I38-MMSN852 = AZT2316R + CS4231A-KL, with EEPROM

All cards with a settings EEPROM have been tested with their JMPCFG jumper set to both EEPROM and SOFTWARE, and work correctly in both situations.

All cards support full-duplex. The ones with AD1845XP codecs seem to be a little flakey, where starting a capture _sometimes_ hangs a concurrent playback, and sometimes not.

Except the ones with a CS4248-KL codec, all cards experience a "cs4231_mce_down - auto calibration time out (1)" upon loading which does not seem to have any further consequences. Both this and the previous point may be cause for debugging cs4231_lib. Later...

Ram -- included you in the CC because you had a:

FCC-ID: I38-MMSN846: Aztech Sound Galaxy Nova 16 Extra II-3D, AZT2316R + CS4231A-KL, without EEPROM

The attached patch is against 2.6.22.x and if you're setup to test, feel free and I'll add your card to the "was tested on" list. If you're not, don't bother too much though -- it'll work (and sorry for the long delay by the way...).

As to the AZT2316A/R chipset series, this driver seems complete and correct. I also have a couple of Aztech Sound Galaxy cards with an AZT1605 chipset (and one even older Sound Galaxy) though and those don't quite/fully work yet as their EEPROMs are layed out slightly different -- they also store default volumes in the EEPROM for example. Got about half of it mapped out already but can't work on it tomorrow so thought I'd post now.

Finally I have a bunch of AZT2320 based cards, which are PnP based, and which I'll merge in as well.

Krzysztof -- you won't be surprised to learn that this driver doesn't do auto-probing. It needs all parameters passed in; normally:

options snd-galaxy port=0x220 wss_port=0x530 irq=10 dma1=1 dma2=0

If you don't specify dma2 (or set it equal to dma1) the card's setup in half-duplex mode. I'll document it all upon driver submission. Your (expected) Waverider should also work fine with it. If/when you test it, could you provide the information such as given in the tables above?

You have an EEPROM if you have "X24C00" chip sitting on a spot marked "UX2" on the board, close to a crystal (silver shiny thing). If that spot is empty, you have an EEPROM-less variant.

Mapping out the rest of AZT1605 (there may also be a duplex diference there) will be sunday or next week.

Rene.

index cf3803c..02a0f55 100644
@@ -177,6 +177,19 @@ config SND_ES18XX
 	  To compile this driver as a module, choose M here: the module
 	  will be called snd-es18xx.
 
+config SND_GALAXY
+	tristate "Aztech Sound Galaxy Driver"
+	depends on SND
+	select SND_CS4231_LIB
+	select SND_MPU401_UART
+	select SND_OPL3_LIB
+	select SND_PCM
+	help
+	  Say Y here to include support for Aztech Sound Galaxy cards.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called snd-galaxy.
+
 config SND_GUS_SYNTH
 	tristate
 

index bb317cc..28bf545 100644
@@ -12,6 +12,7 @@ snd-es18xx-objs := es18xx.o
 snd-opl3sa2-objs := opl3sa2.o
 snd-sgalaxy-objs := sgalaxy.o
 snd-sscape-objs := sscape.o
+snd-galaxy-objs := galaxy.o
 
 # Toplevel Module Dependency
 obj-$(CONFIG_SND_ADLIB) += snd-adlib.o

@@ -23,6 +24,7 @@ obj-$(CONFIG_SND_ES18XX) += snd-es18xx.o
 obj-$(CONFIG_SND_OPL3SA2) += snd-opl3sa2.o
 obj-$(CONFIG_SND_SGALAXY) += snd-sgalaxy.o
 obj-$(CONFIG_SND_SSCAPE) += snd-sscape.o
+obj-$(CONFIG_SND_GALAXY) += snd-galaxy.o
 
 obj-$(CONFIG_SND) += ad1816a/ ad1848/ cs423x/ es1688/ gus/ opti9xx/ \
 		     sb/ wavefront/

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

This is an issue I spotted in the ad1848-lib yesterday. The cs4231-lib seems little better in this respect. The driver waits for the busy bit to be set than wait until it is cleared. The first waiting is wrong because if you have a card set to no calibration (or fast calibration) code you may experience that bit is already cleared and it won't be set any more. Then the message is complete misleading. IMO, a correct solution is to wait some time. An auto-calibration takes about 348 sample periods for AD1848, so at 48KHz (fastest) it is about 7ms. Just wait that in the msleep then wait for bit to be cleared (it could be already). The code is shorter and does not rely on CPU speed (like the current ad1848-lib because it has no delay inside the loop). The 7ms may need to be changed for CS4231 (it may be faster or slower).

I think we agreed that we did not agree on this issue. It is your driver so have it your way. It is nice to have some diversity.

I have not received the card yet. I'll test it when I have the hardware. I am afraid it is one of cards you have already tested.

Great work - new features like waiting by cpu_relax() + jiffies and ioport_map/ioport_unmap I haven't seen in the ISA drivers.

The only thing I do not understand is that there are 4 possible addresses for the SB port base, but user can supply only the first 2.

I got your email how to set up full-duplex but it conflicts with MPU irq settings for the SC-6000 card. Another difference.

Regards,
Krzysztof

I got this one. It has also AZT3320 chip.

The JMPCFG was set to software.

I run into these problems:

1. There is a problem with freeing resources in the probe function. If the probe ends with error, removal of the driver does not release requested regions, so the driver cannot be reloaded again (and cat /proc/iports crashes). It is easy to
reproduce: give irq number which is already acquired by another driver then unload driver.

2. After a while I found the free irq (it took quite long with this manual settings). The driver loaded, the /proc/asound/* files showed GALAXY something
but the alsamixer ended with message that there was no mixer device.

I look forward to next version of your driver to test, Krzysztof

Yep -- hardware midi, hooked up to the onboard MPU-401. Sounds really thin, but it's okay to play with.

Yes, dumb cut & paste error from when it was split off into its own function; please change the four "return err;" exits in (that version of) snd_galaxy_probe() with "goto error;"

It took quite long for you to look at /proc/interrupts and see which ones of four possible IRQs was unclaimed (the only thing autoprobing does)? Strange.

I don't see the mixer problem here, with the same card. Might it be a testing fluke caused by the unloading bug above?

Rene.

I fixed this as you wrote and now the driver works ok. I haven't tested recording.

If you care the mixer controls I found that: "Line" is CD line and "Aux1" is FM/wavetable.

This card returns DSP version 3.1 which is something better than SB Pro. Maybe these AZT-1605 cards return earlier DSP version (but I do not expect anything less than 3.0)

Regards,
Krzysztof

Thanks. I have been testing recording here, so that should be fine.

Yes, I know, and plain "Aux" is the Line In. In this case I admit it's a little clumsy since you'd expect the mixer control "Line" to be that but generally I don't much care.

Or better said, I do, and generally am not very fond of the control-renaming in the drivers since I believe ALSA should be providing for it in userspace such that the user can not only rename things to whatever the driver author and/or datasheet considered applicable, but also to things like "TV", or "Bedroom" or whatever.

This is most applicable to generic drivers -- I for example have an ES1968 card sitting in this machine with an FM Tuner connected to its "Video" input. I'd love to call that "Radio" instead...

But well, sure, maybe I'll rename them in this case. Or maybe not.

They do, DSP version 2.1 and all AZT2316s I've tested are 3.1. Unfortunately though, an even older Aztech chip returns 3.1 again, meaning it's at least not going to help for integrating that as well.

Haven't had time to look at it for a few days, but will be poking again.

Rene.