Sound Blaster G3 Firmware Update

[Siri]

Hminteresting. I was browsing stuff today and it looks like someone has decapped a DSP v4.05 already and there are high-resolution pictures of it available. It uses mask ROM so theoretically you can extract the microcode just by visually decoding the bit pattern from the file.

I may give it a go... though the high-rez image of the ROM array seems to be a bit truncated towards the left (or bottom, as it appears it's rotated 90 degrees clockwise) so I may not get a full readout.

AFAICS the main issues are

1) image quality for rompar:

- uneven lighting and some very blurry areas where the stitching didn't work well? (lighting can probably be fixed in gimp/photoshop)

- rompar seems to need very straight lines, there seems to be some warping in the image where the rompar grid then doesn't match well anymore (could maybe just cut it up into sections and rompar those individually)

See also the attached annotated image, I think its easy to see the row/column select lines (annotated red/blue) and the data path for reading a byte, which all go onto a single bus (also nicely visible in the lowres full-chip image, which has 8 data lines coming out of the rom in that area). I think the bit order is flipped in alternating slices.

There's also a common ababbaba pattern for the row select.

Lets call these two mirrored 8x8 bit blocks. (4 column and 2 row selects per block, 8 bit read at a time). Overall I see 24x24 of these in the upper half and another 24x24 in the lower half, thus the 9216 bytes mentioned above.

Also, going to the opposite end of the rom image, there are 4x2 of the 8x8 blocks that are mostly all 0xff or 0x00. These can give a clue about the block read order I think, I suspect these are the end of either the normal rom or the manufacturing rom (which would be mostly 0xff or 0x00 followed by some final data bytes). These 4x2 blocks are interspersed with 4 of the in the top area and another 4 in the bottom area.

Has anyone ever tried flat-out asking Creative Labs to release the sources to these DSP firmwares? It would be a nice gesture for historic preservation, similar to Microsoft's recent release of the source code to early versions of MS-DOS, GWBASIC and the Windows 3.x file manager. It's not like they're making money off of the sales of their ISA sound cards anymore.

If they don't care for people releasing a replica of their product, why would they care for a vlogger?

I thought to approach them on some expo event, but with all this covid shit I don't know if/when that can be done.

Unless you are in Singapore, it's not likely that you will ever get in touch with anyone from Creative Labs and be able to open a dialogue about older products they no longer sell. They are still working on DSPs and software, but I don't think they give a damn about any of their older products, as the ones they still sell are without support anymore and they have exited the internal soundcard market completely, in favor of external DAC/USB sound-chip products that don't have the functionality any of us want or need.

Excellent!! Next step is to document the binary fully and fix it right and donate this to creative with a creative pun on their bugs and make sure the binary is online so creative cannot stop that, I was waiting for long time till now.

Besides the sound device drivers, ALSA also bundles a user space driven library for application developers. They can then use those ALSA drivers for high level API development. This enables direct (kernel) interaction with sound devices through ALSA libraries.

udev will automatically detect your hardware and select needed drivers at boot time, therefore, your sound should already be working. However, your sound may be initially muted. If it is, see #Unmuting the channels.

Install the alsa-utils package. This contains (among other utilities) the alsamixer(1) and amixer(1) utilities. amixer is a shell command to change audio settings, while alsamixer provides a more intuitive ncurses based interface for audio device configuration.

ALSA has some ability to intercept OSS calls and re-route them through ALSA instead. This emulation layer is useful e.g. for legacy applications which try to open /dev/dsp and write sound data to them directly. Without OSS or the emulation library, /dev/dsp will be missing, and the application will not produce any sound.

Evidently, both methods are mutually exclusive. You can decide for one of the two approaches depending on your requirements. To edit these units, see systemd#Editing provided units. You can check their status using systemctl.

sof-firmware is required for some laptop models (mainly since 2019) because they implement their drivers with firmware provided by the Sound Open Firmware project. Checking the journal will provide messages about the missing firmware (see BBS#275577).

To get full 5.1 or 7.1 surround sound, you will likely need to unmute other channels such as Front, Surround, Center, LFE (subwoofer) and Side. (Those are channel names with Intel HD Audio; they may vary with different hardware)

Everything depends on user preferences when it comes to different styles of configuration; however, one should avoid mixing different styles. Further information on basic configuration can be found in [3].

ALSA uses different data types for parameter values, which must be set in the users respective configuration file. Some keys accept multiple data types, while most do not. A list of configuration options and their respective type requirements for PCM plugins can be found in [4].

There are different operation modes for parsing nodes, the default mode is merge and create. If operation mode is either merge/create or merge, type checking is done. Only same type assignments can be merged, so strings cannot be merged with integers. Trying to define a simple assignment in default operation mode to a compound (and vice versa) will also not work.

Assuming that "defaults" node is set in /usr/share/alsa/alsa.conf, where "defaults.pcm.card" and its "ctl" counterpart have assignment values "0" (type integer), user wants to set default pcm and control device to (third) sound card "2" or "SB" for an Azalia sound card.

Using double quotes here automatically sets values data type to string, so in the above example, setting defaults.pcm.!card "2" would result in retaining last default device, in this case card 0. Using double quotes for strings is not mandatory as long as no special characters are used, which ideally should never be the case. This may be irrelevant in other assignments.

Use $ cat /proc/asound/modules to get the loaded sound modules and their order. This list is usually all that is needed for the loading order. Use $ lsmod grep snd to get a devices & modules list. This configuration assumes you have one mia sound card using snd_mia and one (e.g. onboard) card using snd_hda_intel.

You can also provide an index of -2 to instruct ALSA to never use a card as the primary one. Distributions such as Linux Mint and Ubuntu use the following settings to avoid USB and other "abnormal" drivers from getting index 0:

Probably, it is enough to set ALSA_CARD to the name of the device. First, get the names with aplay -l, then set ALSA_CARD to the name which comes after the colon and before the bracket; e.g. if you have

In this case as well, replace Audigy2 with the name of your device. You can get the names with aplay -l or you can also use PCMs like surround51. But if you need to use the microphone, it is a good idea to select full-duplex PCM as default.

Now, you can select the sound card when starting programs by just changing the environment variable ALSAPCM. It works fine for all program that do not allow to select the card; for the others, ensure you keep the default card.For example, assuming you wrote a downmix PCM called mix51to20, you can use it with mplayer using the commandline ALSAPCM=mix51to20 mplayer example_6_channel.wav

In most cases, it is recommended to use sound card names instead of number references. Card names are easier to grasp, and also overcomes the boot order problem. Therefore, the following would be correct for the above example.

If you wish to apply an equalizer to a specific output device only (for example your speakers connected to the S/PDIF output, but not your headphones connected to the headphone jack), but also want be able to output from multiple applications and to both output devices simultaneously, you need to create two dmix devices that feed into their respective devices (slave.pcm) directly. The following works for stereo output and maintains a regular stereo input, applying the equalizer to the S/PDIF output only.

When software mixing is enabled, ALSA is forced to resample everything to the same frequency (48 kHz by default when supported). By default, it will try to use the speexrate converter to do so, and fallback to low-quality linear interpolation if it is not available[7].Thus, if you are getting poor sound quality due to bad resampling, the problem can be solved by simply installing the alsa-plugins package.

For even higher quality resampling, you can change the default rate converter to speexrate_medium or speexrate_best. Both perform well enough that in practice it does not matter which one you choose, so using the best converter is usually not worth the extra CPU cycles it requires.

In order for stereo sources like music to be able to saturate a 5.1 or 7.1 sound system, you need to use upmixing. In darker days, this used to be tricky and error prone, but nowadays, plugins exist to easily take care of this task. We will use the upmix plugin, included in the alsa-plugins package.

The plugin automatically allows multiple sources to play through it without problems so setting is as a default is actually a safe choice.If this is not working, you have to setup your own dmixer for the upmixing PCM like this:

Mixing enables multiple applications to output sound at the same time. Most discrete sound cards support hardware mixing, which is enabled by default if available. Integrated motherboard sound cards (such as Intel HD Audio), usually do not support hardware mixing. On such cards, software mixing is done by an ALSA plugin called dmix. This feature is enabled automatically if hardware mixing is unavailable.

3a8082e126