ALS-007 Linux and Programming information

1. Introduction

Owing to the total lack of available documentation on the ALS-007 chip from Avance, I decided to attempt to discover how to program this beast myself. My motivation was that having inherited a soundcard equipped with this chip, I wanted to get it working under Linux. This document is a collection of notes, information and procedures gathered during this process.

1.1. Acknowledgements

Since this is the first version of this document and the nature of the contained information's availability, there are no acknowledgements.

1.2. Revision history

Version 1.0 - 21 February 1998

Version 1.1 - 18 April 1998

Version 1.2 - 16 June 1998

Version 1.3 - 25 November 1998

1.3. Feedback

If you have any comments, suggestions or additions to the information in this document, please send them to me, jwoithe at this domain.

1.4. Distribution policy

(c) Copyright 1998 Jonathan Woithe.

This document is free documentation; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This document is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

You can obtain a copy of the GNU General Public License by writing to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

2. Background

The soundcard which is the subject of this document was a PnP "Super Sound Origins Lite" card from Diamond Technologies (which is seemingly different from Diamond Sound and Diamond Multimedia). The chip on the card is a DT-0196. However, the card responds as an ALS-007 chip when interregated using the ISA PnP protocol so it seems that the underlying technology for this chip has been licensed from Avance.

3. The card under Linux - part 1

Note: OSS/Free 3s86 was used throughout this project with kernel version 2.0.30. I have no idea of how the previous version of the sound driver would cope with this treatment.

As a first attempt at getting the card to work under Linux, use the ISA PnP tools to configure the card thus:

or whatever values suit your system.

As an example, the appropriate lines from my /etc/isapnp.conf file are reproduced below. These are only a guide and you should follow the instructions which come with the isapnptools package. Also note that you must use a version > 1.6 as previous versions are known to have problems with soundcards. 

  (READPORT 0x0203)
  (ISOLATE)
  (IDENTIFY *)
  # Card 1: (serial identifier 26 01 00 00 00 07 00 93 05)
  # Vendor Id ALS0007, Serial Number 16777216, checksum 0x26.
  # Version 1.0, Vendor version 0.0
  # ANSI string -->Avance Sound Chip<--

  # This sets the DSP base port to 0x220, audio IRQ to 5 and audio DMA to 1
  (CONFIGURE ALS0007/16777216 (LD 0
  (IO 0 (BASE 0x0220))
  (INT 0 (IRQ 5 (MODE +E)))
  (DMA 0 (CHANNEL 1))
  (ACT Y)
  ))

  # This is the OPL/3 FM synthesiser.  Base port is 0x388.
  (CONFIGURE ALS0007/16777216 (LD 1
  (IO 0 (BASE 0x0388))
  (ACT Y)
  ))

  # Logical device 2 is the joystick port.  I don't have this configured.
  (CONFIGURE ALS0007/16777216 (LD 2
  # (IO 0 (BASE 0x0200))
  # (ACT Y)
  ))

  # This is the MPU-401 Midi interface.  Base port = 0x330, IRQ = 10
  (CONFIGURE ALS0007/16777216 (LD 3
  (IO 0 (BASE 0x0330))
  (INT 0 (IRQ 10 (MODE +E)))
  (ACT Y)
  ))

Compile the Linux sound driver ( OSS/Free 3.8s6 ). Configure a Soundblaster card with the same values as used to configure the card using ISA PnP (note that there is no 16 bit DMA, so set this to -1). Importantly, the sound driver should be compiled as a module since this particular card does not seem to work unless ISA PnP has been run first. Interestingly enough, an initialisation under DOS followed by a warm boot with LoadLin does not always seem to be enough.

Once the new module is installed, test your installation: 

  cat /dev/sndstat
If all is working as expected, the system should respond with: 
  OSS/Free3.8s5-971223 (Fri Jan 30 21:18:36 CST 1998 root,
  Linux marble 2.0.30 #2 Fri Jan 30 20:45:26 CST 1998 i586 unknown)
  Load type: Driver loaded as a module.
  Kernel: Linux marble 2.0.30 #5 Sun Feb 1 20:56:38 CST 1998 i586
  Config options: 0

  Installed drivers:
  Type 1: OPL-2/OPL-3 FM
  Type 26: MPU-401 (UART)
  Type 2: Sound Blaster
  Type 29: Sound Blaster PnP
  Type 7: SB MPU-401

  Card config:
  Sound Blaster at 0x220 irq 5 drq 1
  SB MPU-401 at 0x330 irq 10 drq 0
  OPL-2/OPL-3 FM at 0x388 drq 0

  Audio devices:
  0: Sound Blaster 16 (4.2)

  Synth devices:
  0: Yamaha OPL-3

  Midi devices:
  0: Sound Blaster

  Timers:
  0: System clock

  Mixers:
  0: Sound Blaster
Surprisingly, even though the ALS-007 isn't known as a "Soundblaster" card, the system seems to identify it as such. Even better is that most of the card appears to work as expected. Using wavplay 1.0 it is possible to play both 8 and 16 bit samples and the MPU-401 interface also works satisfactorily using playmidi 2.2 to play a .mid file. The FM interface also responds to Playmidi in the expected way.

However, it seems from a cursory test using mixer-1.0 that all is not well with the mixer part of the card, even though OSS identifies it as a Soundblaster mixer. In a way this is not surprising, since the documentation for this soundcard warns that the (Diamond Sound System) mixer is not compatible with the Soundblaster mixer.

4. Driving the ALS-007 mixer

This turns out not to be too difficult. It appears that the basic mechanism for programming the mixer is not that much different from the Soundblaster, with the major difference being the use of a different Mixer Index Register format. Like the Soundblaster however, the ALS-007 places its Mixer Index Register (MIR) at [Base] + 04 and the Mixer Data Register (MDR) at [Base] + 05 (where [base] is the base audio IO port - 220h in the above example).

MIR Register referenced using MDR
62h Master volume
64h DSP (audio) volume
66h FM synthesiser volume
68h CD audio volume
6Ah Mic/PC speaker volume
6Eh Line input volume
3Ch Output control register #1
4Ch Output control register #2
6Ch Record source select

To read or write to any of these registers, first do an write the appropriate number to the MIR at [base]+04h. The existing values can then be read by reading the MDR at [base]+05h, and a new value can be set by writing to the MDR.

4.1. Mixer volume controls

All mixer channels except the Mic/PC speaker channel have 16 levels of adjustment; the Mic/PC speaker channel has only 8 levels. The left channel volume is held in the high nibble of the MDR and the right channel in the low nibble. In the case of the Mic/PC speaker channel, the Mic level is in the low nibble. (If supported by the respective card, the PC speaker level is in the high nibble. The ALS-007 chip has provision for such an input; however, the Super Sound Origins Lite does not appear to use it).

4.2. Output Control Registers (3Ch and 4Ch)

These control the switching of various channels to the mixer's output. These 2 registers are bitmapped as follows: 

   bit ->   7    6    5    4    3    2    1    0
            \_________/    |    |    |    |    |____Mic on (3Ch)
   Reserved______|         |    |    |    |
                           |    |    |    |_________CD on R (3Ch)                      
   Line On L (3Ch)_________|    |    |              DSP on R (4Ch)
   Midi (FM) On L (4Ch)         |    |
                                |    |______________CD on L (3Ch)
   Line On R (3Ch)              |                   DSP on R (4Ch)
   Midi (FM) On R (4Ch)_________|

4.3. Record source select (6Ch) and recording

This register is used to select the input source for recording. It appears not to be a bitmapped register. Values for the different option are:
CD audio out = 2
microphone input = 4
line in = 6
FM synth = 7
Mixer output = 7

Oddly enough it seems that a value of "7" is used to select both the FM synth AND the "mixer output" with no other values being used to differentiate them. Experiments have shown that a value of 7 seems to select the mixer output rather than just the FM device. To record the FM synthesiser it would therefore seem necessary to fade out all inputs expect the FM synth prior to recording.

It is important to note that in order for recording (sampling) to take place correctly, the DSP must be removed from the output of the soundcard. This is easily done by zeroing bits 1 and 2 of mixer register 4ch. After recording, these 2 bits may be set back to 1 to re-enable DSP output. There also seems to be a tendancy for the DSP volume to be faded down before switching these bits (and fading back up after the switch); this is not necessary though, and appears to be done to prevent clicks in the output.

5. The card under Linux - part 2

Based on the information described above, the OSS/Free 3.8s6 SoundBlaster driver has been extended to include support for the ALS007 soundcard. Support is achieved by defining the ALS-007 to be a "submodel" of the SoundBlaster16 card. These extensions are present in kernels >= 2.1.105; this patch against OSS/Free version 3.8s6 (and probably later versions) gives ALS-007 support in the 2.0.xx series kernels. For those who don't want to patch their kernel, here is a pre-patched version of OSS/Free 3.8s9.

The driver behaves exactly as for a SB16 with the following exceptions.

  1. The mixer layout is set to one correctly describing the ALS007 mixer register usage. Selection of the recording source is also slightly different since the corresponding register isn't bitmapped. In addition, sb_audio_open() turns off the DSP output when recording is started. (Note that sb_audio_open assumes that these bits are *always* on *except* during recording. If the sound driver is ever extended to allow programming of the Output Control Register, this code will have to be extended to restore the DSP bits to their original settings after recording is complete).
  2. The mixer devices are set to reflect only the devices actually present on the ALS007. (For example, the ALS007 doesn't seem to have bass, treble, input gain or output gain controls).
  3. A few text strings (used mainly for responding to "cat /dev/sndstat") are different to reflect the fact that an ALS007 has been detected.
Configuration and compilation should be identical to the methods previously described. Once installed, the output of "cat /dev/sndstat" should look similar to: 
  OSS/Free3.8s5-971223 (Sun Feb 1 20:53:28 CST 1998 root,
  Linux marble 2.0.30 #4 Sun Feb 1 20:39:53 CST 1998 i586 unknown)
  Load type: Driver loaded as a module.
  Kernel: Linux marble 2.0.30 #5 Sun Feb 1 20:56:38 CST 1998 i586
  Config options: 0

  Installed drivers:
  Type 1: OPL-2/OPL-3 FM
  Type 26: MPU-401 (UART)
  Type 2: Sound Blaster
  Type 29: Sound Blaster PnP
  Type 7: SB MPU-401

  Card config:
  Sound Blaster at 0x220 irq 5 drq 1
  SB MPU-401 at 0x330 irq 10 drq 0
  OPL-2/OPL-3 FM at 0x388 drq 0

  Audio devices:
  0: Sound Blaster (ALS-007) (4.2)

  Synth devices:
  0: Yamaha OPL-3

  Midi devices:
  0: Sound Blaster

  Timers:
  0: System clock

  Mixers:
  0: Avance ALS-007

With this configuration:

6. Other Avance soundcards

Besides the ALS-007 chip, Avance manufactures a number of other audio chips which have been integrated into soundcards by various companies. These include the ALS-100, ALS-100+ and the ALS-200. The ALS-100 does work with OSS/Free 3.8s6 and later. Given the above experiences with the ALS-007 and what little documentation exists on the ALS-xxx chips, it seems plausible that the other chips will also work to a certain extent with the Sound Blaster 16 kernel drivers.

However, the ALS-007 mixer patches will not drive the mixers of these other chips. Whereas the ALS-007 has only a 16 level mixer, these other cards have 32 levels; from the mixer register discussions above it should be clear that the 32 level chips could not possibly use the same register format. Given that the SB16 is also a 32 level mixer it is possible that the standard drivers will successfully drive the other ALS-xxx chips. Since I do not have access to any other ALS-xxx based cards I am not in a position to confirm this theory either way. The best way is to try it and see.