Getting E-MU 1820 running under Linux
I did not think this was possible but there is actually support for the E-MU line of sound interfaces in ALSA. It's been there for quite a while actually. The E-MU 1010, 1212, 1820 and 0404 share the same DSP chip as the Audigy line, the emu10k2 (wich is supported by the emu10k1 ALSA driver). What differs from Audigy is that these E-MU interfaces has an extra FPGA chip for signal routing. The FPGA is a Xilinx Spartan IIE XC2S50E. This requires extra firmware. This firmware is free and available from www.alsa-project.org but as far as I know it is not open source. This is no major bummer though because all is working without the need of changing this. The first step is to get basic ALSA up and running. # apt-get install alsa-base alsa-utils Next step is to obtain the firmware. At the time of my installation the latest ALSA available was 1.0.25. The firmware is available in alsa-firmware-1.0.25.tar.bz2 from www.alsa-project.org. The firmware files used by the emu10k1 ALSA driver is located in /lib/firmware/emu/. Fore some reason the firmware is distributed in C header files that needs to be converted to binary *.fw files. My guess is that these firmwares was initially meant to be compiled into the ALSA driver but for licensing reasons the had to be kept out. This is easy to fix though because the ALSA team has included a simple tool to convert these files for us. The source for the tool is in a single C file that has to be compiled. Below is the set of commands from my installation. # tar -xvjf alsa-firmware-1.0.25.tar.bz2 # cd alsa-firmware-1.0.25/ # cd emu/ # gcc fw_writer.c # ./a.out # ls -1 *.fw audio_dock.fw emu0404.fw emu1010b.fw emu1010_notebook.fw hana.fw micro_dock.fw # sudo mkdir /lib/firmware/emu # sudo cp *.fw /lib/firmware/emu When the firmware files are installed, reboot to make sure the driver and hardware is initialized correctly. If everything is working the boot messages should look something like this: # dmesg | grep emu10k1 [ 1.948526] snd_emu10k1 0000:04:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 1.948558] ALSA emu10k1_main.c:823: emu1010: Special config. [ 1.948705] ALSA emu10k1_main.c:862: emu1010: EMU_HANA_ID = 0x7f [ 1.948706] ALSA emu10k1_main.c:881: emu1010: filename emu/hana.fw testing [ 1.948708] snd_emu10k1 0000:04:00.0: firmware: requesting emu/hana.fw [ 1.951552] ALSA emu10k1_main.c:686: firmware size = 0x133a4 [ 9.860345] ALSA emu10k1_main.c:898: emu1010: Hana Firmware loaded [ 9.860425] ALSA emu10k1_main.c:901: emu1010: Hana version: 3.4 [ 9.860492] ALSA emu10k1_main.c:906: emu1010: Card options = 0x0 [ 9.860521] ALSA emu10k1_main.c:908: emu1010: Card options = 0x0 [ 9.861096] ALSA emu10k1_main.c:947: emu1010: Card options3 = 0x0 [ 10.873763] ALSA emu10k1_main.c:739: emu1010: Loading Audio Dock Firmware [ 10.873806] snd_emu10k1 0000:04:00.0: firmware: requesting emu/audio_dock.fw [ 10.876304] ALSA emu10k1_main.c:686: firmware size = 0x133a4 [ 16.076509] ALSA emu10k1_main.c:760: emu1010: EMU_HANA+DOCK_IRQ_STATUS = 0x36 [ 16.076538] ALSA emu10k1_main.c:763: emu1010: EMU_HANA+DOCK_ID = 0x55 [ 16.076540] ALSA emu10k1_main.c:769: emu1010: Audio Dock Firmware loaded [ 16.076596] ALSA emu10k1_main.c:773: Audio Dock ver: 3.4 It looks like my card (E-MU 1820) only require the files hana.fw and audio_dock.fw to load. The E-MU 1820 is no usual sound interface in the regards that one PCM output is directly connected to one other physical output. The signals have to be routed internally. The usual alsamixer can be used for this purpose. For basic PCM playback 32 virtual outputs are available, DSB 0 to DSP 31. Normal stereo playback is sent to DSP 0-1. Looking in alsamixer under the playback (F3) category reveals quite a lot of outputs. The following physical outputs are available on the 1820 and are represented as separate mixer channels in alsamixer. 1010 ADAT 0 1010 ADAT 1 1010 ADAT 2 1010 ADAT 3 1010 ADAT 4 1010 ADAT 5 1010 ADAT 6 1010 ADAT 7 1010 SPDIF Left 1010 SPDIF Right Dock Mic A Dock Mic B Dock ADC1 Left Dock ADC1 Right Dock ADC2 Left Dock ADC2 Right Dock ADC3 Left Dock ADC3 Right Dock Phones Left Dock Phones Right Dock SPDIF Left Dock SPDIF Right These have to be assigned to DSP 0-31 by changing the value of the playback channels listed above. By default the driver connect DSP 0-1 to ADC1, Phones and SPDIF so basic stereo playback should work right away. The interface can operate at 44.1kHz or 48kHz sample rate. For correct playback this must match the sample rate of the material being played. The mixer channel "Clock Internal Rate" defines the sample rate. The sample rate can also be set to "ADAT" or "SPDIF" for external sync. Below are two single line commands to set either 44.4kHz or 48kHz. # amixer set 'Clock Internal Rate' '44100' # amixer set 'Clock Internal Rate' '48000' The optical I/O on the 1010 card is set to ADAT and can only be changed from source in emu10k1_main.c. /* Optical -> ADAT I/O */ /* 0 : SPDIF * 1 : ADAT */ emu->emu1010.optical_in = 1; /* IN_ADAT */ emu->emu1010.optical_out = 1; /* IN_ADAT */ The current driver is limited to 16bit playback (S16_LE) if I have understood everything correctly, This is because the DSP only has 16bit wide I/O so that a 24bit sample need to be split up into two 16bit parts and then assembled on the other side. This has been done on the capture part of the driver so that device 2 of the interface (Multichannel Capture/PT Playback) is actually operating at 24bit (S32_LE) which is great! If only the same can be done on device 3 (Multichannel Playback). This would mean that 24bit capture AND playback would be available when using Jack! I really wish someone who knows the emu10k1 driver and chip would take on this task so that we can enjoy 24bit playback. If this is fixed then 24bit playback would be possible on Audigy interfaces as well since they use the same emu10k1 driver. I have tried to do this myself but my lack of knowledge regarding the emu10k1 and the inner workings of the E-MU and Audigy is holding me back. Simply allowing S32_LE samples by setting "runtime->hw.formats = SNDRV_PCM_FMTBIT_S32_LE;" in emupcm.c is not enough... The current driver status can be found here: https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=emu
by Daniel 2012-11-06 14:38 UTC
It looks like bugtrack.alsa-project.org is down and has been so for quite while now. I don't know why.


by JBerg 2022-08-26 07:42 UTC
Just interested to know if there's some possible use for these in 2022. I have one installed in a system atm, but I'm having a heck of a time getting it started


Write a comment

Name or handle

E-mail (optional and not visible to others)

Comment


Code from above