EMU 1212m/1616m on Windows 7 - The Thread to End All Other EMU Threads!

[Bad Robot]

I was glad when I saw that there was a solution to the problem with Windows 10. However, my joy was short-lived. I recently switched to a new PC with Windows 10, but the problem is that my 1616m pcie does not work with the new ASUS X570 mobo.
I have tested in all 3 pcie x1 slots and even in x16. Changing the PCIE settings in the bios to GEN1 and GEN2 also did not solve the problem. With the 1010 pcie card installed, boot up takes much longer than usual and card is not visible in device manager.
It's sad because I love my 1616m, I've had it since 2008 (first with 1010 pci).

[rawl747]

Unread post Tue Feb 25, 2020 4:18 pm

I was glad when I saw that there was a solution to the problem with Windows 10. However, my joy was short-lived. I recently switched to a new PC with Windows 10, but the problem is that my 1616m pcie does not work with the new ASUS X570 mobo.
I have tested in all 3 pcie x1 slots and even in x16. Changing the PCIE settings in the bios to GEN1 and GEN2 also did not solve the problem. With the 1010 pcie card installed, boot up takes much longer than usual and card is not visible in device manager.
It's sad because I love my 1616m, I've had it since 2008 (first with 1010 pci).

Bad Robot,

Did you try removing all other PCIe cards from you system, rebooting and then trying to install the drivers? I had issues with my PCI based Emu 1010 card for my 1820m where IRQ sharing caused some issues preventing the 1010 PCI card from being "seen" by the system and by the drivers.

I know PCI and PCIe are not the same bus but still, are there any BIOS settings in your mobo that would allow you to reserve any IRQ's that your 1616m's PCIe card needs?

I know IRQ conflicts can cause your symptoms especially the long bootup. something to look at before you give up on the interface.

Rawl

[Bad Robot]

@rawl747 thanks for reply. Today I solved the problem and I am very happy, my 1616m is still on duty.
The problem is related to the new AGESA 1.0.0.4 BIOS and affects various pcie cards, not only audio.
If someone would have a similar problem, boot into your BIOS > Advanced > AMD CBS and set "PCIe Ten Bit Tag Support" to Disabled. It may look different for different mobo manufacturers, my mobo is ASUS TUF GAMING X570-PLUS.

[rawl747]

Bad,

Glad to hear it is solved for you! These are actually quite good interfaces even by today's standards. It is truly a pity that Creative has pretty much abandoned them but terrific that the X-Fi drivers are breathing new life into them courtesy folks like ClubHouseKey.

Rawl

[l_maseroni]

Hi everyone. I have a 1212m version 1, the one that has a fireware port and is compatible with the 1820. It is working wonders, but on the other hand I got an 1820, connect it and it works badly. He walked 1 time in 44,100 but made noise like fried when I wanted to record with a microphone. The strange thing is that it made noise only when it received an impulse, but it was silent. then the second time the system started up it did not work, all the inputs in the patchmix were intermittently lit in red at any sampling frequency. The audiodock power cable did not originally come so I ordered to build one, will this work badly? in the manual it says that one end of the cable goes to 1212m, another to the power supply and another to a disk drive. I don't know where I would go, if this connection is really necessary. Will it be driver problem? use the process explained on page 13 of this thread.

[rawl747]

Hi everyone. I have a 1212m version 1, the one that has a fireware port and is compatible with the 1820. It is working wonders, but on the other hand I got an 1820, connect it and it works badly. He walked 1 time in 44,100 but made noise like fried when I wanted to record with a microphone. The strange thing is that it made noise only when it received an impulse, but it was silent. then the second time the system started up it did not work, all the inputs in the patchmix were intermittently lit in red at any sampling frequency. The audiodock power cable did not originally come so I ordered to build one, will this work badly? in the manual it says that one end of the cable goes to 1212m, another to the power supply and another to a disk drive. I don't know where I would go, if this connection is really necessary. Will it be driver problem? use the process explained on page 13 of this thread.

Well, to be honest, I have never tried what you are attempting. My 1820m came with a 1010 PCI card. It has a firewire port like yours. I also have a 1212 card in another machine but never tried to mix and match. The 1616 interfaces have a separate DC power source for the AudioDock. It is a "wall wart" that plugs into a DC socket on the from of the 1616 AudioDock.

The 1820 series AudioDocks are supplied power via the Cat 5e cable only. There is no separate DC source. Years ago Creative tech support infomed me that the Cat 5e cable they used had additional shielding added to keep out stray digital "noise" from interfering with the digital audio and MIDI signals. Otherwise it should be the same.

Also, there were at least 2 versions of the 1010 PCI cards. The first was used with the 1820 series AudioDocks. A later version supported the 1616 series AudioDocks and is reportedly NOT compatible with the 1820 AudioDocks. I have never owned a 1616 series so my knowledge about them is strictly second hand. But this issue has been mentioned elsewhere on this site.

Finally, I believe that a 1212 interface's 1010 PCI card could be of either version but again, that opinion is not based on first-hand knowledge. You said that your 1212 interfaces 1010 card was compatible. Are you sure?

Also, the Windows version of the Emu driver supports 2 input and 2 output audio ports. Your 1212 card may work fine with this Windows supplied driver. An 1820 Audiodock will not work properly with the Windows Emu driver and the PatchMixDSP application will give you indications of issues and a message about insufficient hardware.

So, your driver may also be an issue. If it is the Creative signed one, you should be able to see that in the Driver details. The Windows driver will have a Microsoft version NOT a Creative version under driver details.

Best of luck,
Rawl

[Easy_Does_It]

Here's an update on my system's status.

Day 1:
- Start up computer, everything fires up with no problems.
- Run computer all day, including multi-track recording in my DAW without a single hitch. Everything completely normal and stable.

Day 2:
- Start up computer, no audio device loaded, like E-MU isn't there. Seems Windows couldn't 'see' the hardware.
- Restart, everything comes on as normal. Run computer another full day with zero problems or abnormalities.

Day 3:
- Start up computer, no audio device loaded. (Here we go again.)
- Restart computer, freezes in the middle of Windows starting up. (This is not a good sign!)
- Hard restart, everything loads up completely normally again.
- Just for the fun of it, run CCleaner and clean up registry. Looks like there are some Creative Professional files there that needed fixing. Restart once more, everything normal.

So currently this issue seems to be consistently inconsistent. Stevee may be onto something, and I second his question (from a related thread):

It seems as though the Windows installation eventually undos the work of the script and it reverts back to not working.

Has anyone managed to get the fix to be more reliable?

Unless/until I post again, assume that it's going to be this intermittent with my system. I will keep checking these threads for people's ideas, and I will be sure to update if anything changes on my end.

Edit:
I've implemented one extra step (Step 4) as suggested by Freddie Stjerna in the third post down on this page:
https://answers.microsoft.com/en-us/win ... 13a?page=3

He says that after implementing sherwoodsound's procedure, do the following:

Step 4.

While you are inside in registry editor. Go to following new location.
1. Go to \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ASIO\E-MU ASIO
2. Go to ---> “E-MU ASIO”. \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ASIO\E-MU ASIO
3. As you can see another error inside the E-MU ASIO. In (Default) type “REG_SZ” has the wrong DATA-string “CTASIO”.
4. Right-click on "(Default) " and choose Modify
5. Modify and change to only: CTASIO64

Step 5.

1. Close registry editor and shut down your computer again and re-boot a “cold start”.

(End quote)

After doing this, everything started up normally for me. Will report with an update again after running for some time.

[l_maseroni]

Hi everyone. I have a 1212m version 1, the one that has a fireware port and is compatible with the 1820. It is working wonders, but on the other hand I got an 1820, connect it and it works badly. He walked 1 time in 44,100 but made noise like fried when I wanted to record with a microphone. The strange thing is that it made noise only when it received an impulse, but it was silent. then the second time the system started up it did not work, all the inputs in the patchmix were intermittently lit in red at any sampling frequency. The audiodock power cable did not originally come so I ordered to build one, will this work badly? in the manual it says that one end of the cable goes to 1212m, another to the power supply and another to a disk drive. I don't know where I would go, if this connection is really necessary. Will it be driver problem? use the process explained on page 13 of this thread.

Well, to be honest, I have never tried what you are attempting. My 1820m came with a 1010 PCI card. It has a firewire port like yours. I also have a 1212 card in another machine but never tried to mix and match. The 1616 interfaces have a separate DC power source for the AudioDock. It is a "wall wart" that plugs into a DC socket on the from of the 1616 AudioDock.

The 1820 series AudioDocks are supplied power via the Cat 5e cable only. There is no separate DC source. Years ago Creative tech support infomed me that the Cat 5e cable they used had additional shielding added to keep out stray digital "noise" from interfering with the digital audio and MIDI signals. Otherwise it should be the same.

Also, there were at least 2 versions of the 1010 PCI cards. The first was used with the 1820 series AudioDocks. A later version supported the 1616 series AudioDocks and is reportedly NOT compatible with the 1820 AudioDocks. I have never owned a 1616 series so my knowledge about them is strictly second hand. But this issue has been mentioned elsewhere on this site.

Finally, I believe that a 1212 interface's 1010 PCI card could be of either version but again, that opinion is not based on first-hand knowledge. You said that your 1212 interfaces 1010 card was compatible. Are you sure?

Also, the Windows version of the Emu driver supports 2 input and 2 output audio ports. Your 1212 card may work fine with this Windows supplied driver. An 1820 Audiodock will not work properly with the Windows Emu driver and the PatchMixDSP application will give you indications of issues and a message about insufficient hardware.

So, your driver may also be an issue. If it is the Creative signed one, you should be able to see that in the Driver details. The Windows driver will have a Microsoft version NOT a Creative version under driver details.

Best of luck,
Rawl

Yes, the 1212 card I have is compatible with the 1820, only that you buy them separately and both are used. In fact, the 1820 was the first time I connected it to 1212, just making some noises. The drivers you install are the ones you left here, they are creative. In the device manager they appear like this. I also have a 1616 sound board with its corresponding 1010, but this one that brought me problems is another one. I'm going to install it on windows 7 or see if I get a PC with 32-bit operating system and install it with the original drivers of the cd.

[l_maseroni]

What I don't understand is if the 1212m (1010 + 0202) works on my pc (win 10 64bit) and I am sure that this board is compatible with the 1820 (in fact the patchmix recognizes it) why there would be driver problems. The drivers version 2.30 beta for 64 bit that you download from here are supposed to be for both 1212, 1616, 1820 right?

[rawl747]

What I don't understand is if the 1212m (1010 + 0202) works on my pc (win 10 64bit) and I am sure that this board is compatible with the 1820 (in fact the patchmix recognizes it) why there would be driver problems. The drivers version 2.30 beta for 64 bit that you download from here are supposed to be for both 1212, 1616, 1820 right?

These problems are indeed complicated. I will try to explain what I understand about how we got here. To understand my explanation you need to first understand how Microsoft handles "built-in" device drivers in their Windows system and in updates.

Windows includes drivers for popular hardware that are typically signed as Microsoft Drivers. These are often called "built-in" drivers because they are built in to the Windows installation (or update) files If your hardware device doesn't have a "built-in" Microsoft driver then you have to install drivers from the hardware manufacturer. These drivers are called "third-party" drivers. This is where we were with Windows 7 and the initial version of Windows 10. Microsoft did not include any built-in driver support for any of the Emu interfaces. So, we installed the third party drivers from Creative. The last version of these drivers was 2.30. Creative released this originally labeled as beta. Later they provided a driver download labeled v2.30 without the "beta" in the download file name. And there was a PatchMixDSP application download file. the latest of which was v2.20.

Not too long ago but apparently in time for the 1903 Windows 10 update, Microsoft obtained driver files from Creative for some of the Emu interface cards and started including these as built-in drivers. So, when folks with previously working Emu interfaces that worked by using the Creative third party drivers, had their Windows 10 update to build 1903, it seems that the update replaced the Creative third party drivers with ones labeled as a Microsoft signed "built-in" drivers. Prior to this update, the Emu device would show up in the Windows "Device Manager" list as "E-MU E-DSP Audio Processor (WDM)" and after this update it was listed as only "Emu E-DSP".

The Microsoft built-in "Emu E-DSP" drivers allow an Emu interface to provide only the most basic audio functions like most any simple audio interface. It support 2 input audio channels and 2 output audio channels. When you run the PatchMixDSP application for an Emu interface such as an 1820 using these built-in drivers, you get an insufficient hardware message because the Microsoft built-in driver does not support all the additional hardware capabilities of the interface. AND, it has essentially replaced the third party drivers that did support all these extras.

To make things worse, I am positive that the Windows update does not replace just one Emu driver file. There are actually dozens and dozens of supporting driver files that get replaced. There has to be other supporting files that were part of the Windows system files themselves that get updated and that "breaks" some of the original driver files from Creative.

Since the X-Fi interfaces are still being supported by Creative, they (Creative) have provided updates for these X-Fi interfaces probably to fix what these Windows updates keep breaking.

Because these X-Fi interfaces share internal hardware chips with the Emu interfaces, drivers included in the X-Fi driver updates from Creative for these shared chips also seem to work for the Emu interfaces. That is why running a powershell script that replaces specific driver files in your updated Windows installation with ones with the same names from the X-Fi driver updates seems to solve (most of) our problems getting our Emu interfaces working again.

So it is a combination of the driver files from the Creative v2.30 third party drivers AND a bunch of the driver files from the X-Fi drivers that seem to restore the functionality of our Emu interfaces at least those with extended capabilities that the 1820 and 1616 series AudioDocks provide.

This is not a great solution or even one that most end users would put up with but it seems to be all we have.

I still use my 1820m interface on my old DAW PC but my current main DAW PC (a laptop) has a Focusrite Scarlett 18i20 USB interface. With its corresponding mixing control application it was the closest solution I could find to replace the functionality of my 1820m when I moved to a laptop for my DAW PC.

I hope this gives you some context for your situation and helps you to understand some of the complexities.

Rawl

[l_maseroni]

What I don't understand is if the 1212m (1010 + 0202) works on my pc (win 10 64bit) and I am sure that this board is compatible with the 1820 (in fact the patchmix recognizes it) why there would be driver problems. The drivers version 2.30 beta for 64 bit that you download from here are supposed to be for both 1212, 1616, 1820 right?

These problems are indeed complicated. I will try to explain what I understand about how we got here. To understand my explanation you need to first understand how Microsoft handles "built-in" device drivers in their Windows system and in updates.

Windows includes drivers for popular hardware that are typically signed as Microsoft Drivers. These are often called "built-in" drivers because they are built in to the Windows installation (or update) files If your hardware device doesn't have a "built-in" Microsoft driver then you have to install drivers from the hardware manufacturer. These drivers are called "third-party" drivers. This is where we were with Windows 7 and the initial version of Windows 10. Microsoft did not include any built-in driver support for any of the Emu interfaces. So, we installed the third party drivers from Creative. The last version of these drivers was 2.30. Creative released this originally labeled as beta. Later they provided a driver download labeled v2.30 without the "beta" in the download file name. And there was a PatchMixDSP application download file. the latest of which was v2.20.

Not too long ago but apparently in time for the 1903 Windows 10 update, Microsoft obtained driver files from Creative for some of the Emu interface cards and started including these as built-in drivers. So, when folks with previously working Emu interfaces that worked by using the Creative third party drivers, had their Windows 10 update to build 1903, it seems that the update replaced the Creative third party drivers with ones labeled as a Microsoft signed "built-in" drivers. Prior to this update, the Emu device would show up in the Windows "Device Manager" list as "E-MU E-DSP Audio Processor (WDM)" and after this update it was listed as only "Emu E-DSP".

The Microsoft built-in "Emu E-DSP" drivers allow an Emu interface to provide only the most basic audio functions like most any simple audio interface. It support 2 input audio channels and 2 output audio channels. When you run the PatchMixDSP application for an Emu interface such as an 1820 using these built-in drivers, you get an insufficient hardware message because the Microsoft built-in driver does not support all the additional hardware capabilities of the interface. AND, it has essentially replaced the third party drivers that did support all these extras.

To make things worse, I am positive that the Windows update does not replace just one Emu driver file. There are actually dozens and dozens of supporting driver files that get replaced. There has to be other supporting files that were part of the Windows system files themselves that get updated and that "breaks" some of the original driver files from Creative.

Since the X-Fi interfaces are still being supported by Creative, they (Creative) have provided updates for these X-Fi interfaces probably to fix what these Windows updates keep breaking.

Because these X-Fi interfaces share internal hardware chips with the Emu interfaces, drivers included in the X-Fi driver updates from Creative for these shared chips also seem to work for the Emu interfaces. That is why running a powershell script that replaces specific driver files in your updated Windows installation with ones with the same names from the X-Fi driver updates seems to solve (most of) our problems getting our Emu interfaces working again.

So it is a combination of the driver files from the Creative v2.30 third party drivers AND a bunch of the driver files from the X-Fi drivers that seem to restore the functionality of our Emu interfaces at least those with extended capabilities that the 1820 and 1616 series AudioDocks provide.

This is not a great solution or even one that most end users would put up with but it seems to be all we have.

I still use my 1820m interface on my old DAW PC but my current main DAW PC (a laptop) has a Focusrite Scarlett 18i20 USB interface. With its corresponding mixing control application it was the closest solution I could find to replace the functionality of my 1820m when I moved to a laptop for my DAW PC.

I hope this gives you some context for your situation and helps you to understand some of the complexities.

Rawl

Thank you very much for your explanation, you have really done it very clearly. I also read here that run the script but with the XFTI version PCDRV L11 2 40 0019 it worked for some. The E-MU E-DSP audio processor (wdm) driver appears as a hidden device in my device manager. I don't know how to proceed to reverse this

[l_maseroni]

Many thanks to ClubHouseKey and all other posters for the instructions! After upgrading to Win10Pro release1903, EM-U 1212 wouldn't function. I used XFTI_PCDRV_L11_2_40_0019 drivers and modified the .csv file, changed the friendly name of the sound card on the .ps1 file, changing the SetExecution policy to Bypass, and ran the script. Worked flawlessly! Audio back in service...

Hello! How have you edited the filestoreplace file? I don't know how to use Excel. Could you pass me your edited file?

[l_maseroni]

Yesterday I saw the post of rawl747 with the update of the scripts. The work they do here is really wonderful.
I followed all the steps and tried the version xfti pcdrv l11 240 0019 and the 1820 still has problems. I got a pc with windows 7 32 bit, install the 1820 there with the EmuPMX_PCDrv_L6_2_10_00 drivers, since I think they were the most suitable for this environment and the problems are the same. The 1820 throws the message of insufficient hardware, then flashes there in the patchmix where it informs you that devices have connected, in this case the audiodock, all the channels are disabled and in the vumetros it sends a signal, some type of noise. Then I pass it to 44,100 and it stabilizes but it doesn't work anyway. In wiondows 7 to 44100 does not play sound or anything. In windows 10 play the best, record but with noise to fried.
I am thinking if it will be something electronic from 1820, could something that causes these problems be failing?

[l_maseroni]

aclaro que la pc de windows 7 32 bits no es mia, yo tengo windows 10 64 bit (1909). Repito que la 1212m con la que funciona la 1820 anda bien, digamos la 1010 mas la 0202 funcionan correctamente.

[pandashake]

Hi everyone. I have a 1212m version 1, the one that has a fireware port and is compatible with the 1820. It is working wonders, but on the other hand I got an 1820, connect it and it works badly. He walked 1 time in 44,100 but made noise like fried when I wanted to record with a microphone. The strange thing is that it made noise only when it received an impulse, but it was silent. then the second time the system started up it did not work, all the inputs in the patchmix were intermittently lit in red at any sampling frequency. The audiodock power cable did not originally come so I ordered to build one, will this work badly? in the manual it says that one end of the cable goes to 1212m, another to the power supply and another to a disk drive. I don't know where I would go, if this connection is really necessary. Will it be driver problem? use the process explained on page 13 of this thread.

Couple things could be going on. Does your 1212m card have the 4-pin power connector on it, and if so, do you have it hooked up? The 1820 will need this hooked up to get the proper power supply to the dock. If you have done this, then I would suggest replacing the power caps in the dock itself as they notoriously go bad.