emusonacid! legacy

so, i got a e4xt ultra with some issues. trying to figure out if it is going to be worth even attempting to fix this thing. everything seems to work well except all outputs are distorted/jittery. to me it sounds more like jitter.. every sample i put in it playes back with a choppy/bitcrushed sound.

here's what the results from diagnostics reveal.. if anyone has any info that can help interpret them please let me know

wclock = word clock in or out bad [:-0]
ram = addrline test FAILED!, bit test FAILED!, Memory Line Tests BAD! and then the ram tests ends on "128MBgRAM cycle 1 verify g address = 00000002' and the unit needs to be reset :(

looks like bad sample memory is a potential problem.. i'll swap and test with some other sticks i know are good to veirfy.

i'm curious about the word clock message because this could explain the output problem. do you need to be running WC into the the ultra to test this properly?

another post mentioned that output problems could be caused by bad DACs.. anybody know how much these are to replace/source?

thanks!

update: tested new ram & it passes diagnostics.. but output problem persists

Check the power supply with a multimeter. The lines at the mainboard-connector CN7 should read +5V, +12V and -12V ... in reference to GND.
Try to use another power supply but watch for the right wiring.

Use InitEE from Diagnostics menu.
Check different clocks: Internal (44.1 and 48 kHz) or the external AES/EBU (respectivly S/P-DIF)

If all fails and the E4XT Ultra is defective, you can sell the DWAM-board (board with cable but without the CS8411 chip) to the guy who will win this auction:
http://www.ebay.com/itm/110870410329
Just contact the seller and ask for contact to the winner.
The offered E4XT Ultra is somehow without this option board but the CS8411 is still (soldered) on the mainboard of this device.

... we hope for the best but are preparing for the worst...

thanks for the info. i guess i could sell it for parts if all else fails.. i don't have a multimeter but will see if i can grab one frome a friend to check this out.

do you think a psu from an e4xt, non ultra, would work with this? are there any differneces between the e4 and e4 ultra psus? asking because i have an e4xt and it might be worthwhile to see if i can fix this by switching the psus

the one saving grace of this has been that the ultra had a 16mb flash rom and a 4 mb flash rom inside it - i'll probably never use them but i could at least try selling to recoup the cost of this thing

what a weird discovery.. this is such a mystery.

so i decided to test how it would work if clocked to the aes input. still the same problem, but i did discover something..

on the 20bg internal ied drive th unit came with (supposed to be the e4 producer set) there was only one bank. in this bank there are a bunch of piano samples and a single cycle wave called "VonStrubenPulse". All the samples i put in the machine, either via scsi or sampling through the inputs (analog and digital) have the output problem, same with all the piano samples that are on the HD, BUT one sample outputs normally! i decided to make a quick preset with a filter sweep and it sounds fine.

what the hell?! it's a faint glimmer of hope. doesn't look like a clock problem anymore.. not a memory problem cause i've swapped sample ram.. i'm starting to suspect the PSU and after checking the post on the 2.5 ide & psu update i could just install a new one. trying not to get to optimistic but can't help it. i've wanted an ultra forever!

i wonder if this may have something to do with sample length.. because all of the piano samples are longer (0.7-1.5ss) while the pulse waveform is only 0.2s

one other thing i forgot to add.. the fx work fine. so it's definitely NOT an output issue.. with the pulse patch i made everything outputs normally & fx work..
if i switch the sample to one the piano samples, or something else i put in there/sample, it sounds all distorted/bitcrushed but i can hear the fx trail perfectly & crystal clear!

since i lack a multimeter i decided to visually inspect the psu. from the looks of it there seems to be a bunch of melted plastic around what i assume is a transformer. i've attached pictures if you can confirm my diagnosis

so with all that's said and done - psu likely $%*@ed?

going to the store to grab a multi tomorrow ;D

so after checking with a multi the psu is actually outputting in normal-ish ranges... i also used a working psu from my other emu to power the ultra and the output problem is still happening ;(

back to square one - may end up having to part this thing. if anyone needs parts, let me know

No chance you have any Global FX on (GFX1, GFX2) which is causing it ? I'm assuming no RFX installed (there's a known issue with FX routing relating to how things can sound in standalone vs multi sounds simultaneously)

http://www.e-univercity.com/SynthGearDocs/

Can you MIDI dump a sample to a PC/Mac to ensure that the source is 100% right to ensure you've got a totally clean sample:

* on Disk
* in memory (save back, compare)


No issues with IDE drive munging data as its being read ?

hey, thanks for your post. good ideas to try out for sure yep, no rfx

spoke to EPR & they quoted somewhere between $3-400 for a repair.. they're awesome but i just ended up getting a new e4xt which i was lucky enough to find in my area for the same price. anyway, still wanting to try to figure this one out i have kept on troubleshooting ;D

having fx enabled or disabled doesn't seem to affect anything. that was one of the interesting things: even with the sample sounding corrupted the fx trails all sound fine.

i loaded a few sounds on a disk from my other emu and tried them on the ultra. and made a cool discovery: all of the single cycle samples sound & playback fine, (yeah ONLY single cycles) but any 'long" sounds (litterally anything longer than a single cycle) sound all messed up. once i realized that was the case i did the test you suggested, sending back and forth via smdi

as you can see in the image, the single cycle i tested sent and received from the ultra just fine. but if i duplicated the length of the sample by 2x (just copy and pasting the original cycle) it comes back from the ultra corrupted.

since i've replaced the ram and it passes all diagnostics, this made me think it was maybe a software problem.. perhaps with the os or something with flash memory.. so i swapped that out and the same problem was occurring

anyway, at this point i've managed to test all components i can and narrowed it down to something on the motherboard. which still means no fix! (for me at least).

if i knew what 'path' audio took when being sampled and transferred to ram i may be able to isolate it to a module.... but that seems unlikely

You might try pressing down on the G-chip pins with the eraser side of a pencil while playing to see if the problem disappears. Sometimes the legs of the surface-mount chips are not soldered properly. The G-chips are the small (about 1 inch) square chips on the daughter board. A looping problem is almost certainly going to be related to the G-chip, which handles all memory fetches, pitch shifting and looping.

The G-Chip is labeled IC402 and provides 64 voices.
The H-Chip is labeled IC413 and provides 32 filters.

In a 128 Voice system like the E4XT Ultra you have two IC402 and four IC413.
In a 64 Voice system like e6400 Ultra and e5000 Ultra you have just one IC402 and two IC413.

Looking at the waveform here it appears that the DAC output is going to zero periodically.

this could be due to several causes:

* the source data feed is stopped - a memory controller or bus controller is getting arbitration wrong - a whole range of possible issue
* the DAC's resetting itself periodically - e.g. has an unstable power supply *to the chip* - could be a tiny SMD cap thats dead or similar
* a memory component of the internal RAM of the CPU itself is messed up (but this would likely cause a whole array of other issues like crashing
* another control signal e.g. chip select is marginal during data feed cycles
* or, another processor that shares the same resource is grabbing the bus incorrectly every now and then due to similar issues.
* or - less likely as it would result in a boot checksum failure - the software is getting corrupted during use and execution is failing during longer loop routines...long shot...

To me, this looks like something difficult to fix unless you really want to get into the weeds of the motherboard.

Or, turn it right around and circuit bend the beast - most likely blowing it up, but maybe some fun in the process ;-)

M

thanks so much for your replies.

certaintly has narrowed things down as much as possible i think! funny thing about circuit bending is that it SOUNDS like that anyway haha

i do believe you're correct tho, likely not fixable unless the motherboard is serviced. i think you're on to it with the notion that it is internal ram or a module which accesses that..

anyway, this whole experience has definitely expanded my knowledge about emu's & for that I thank all of you :D

the one saving grace of this has been that this sampler had the esynth & orbit/phat roms installed, and they're printed on 32mb flash SIMMs :D

cool but i have no use for them. anyone wanna buy them & help me offset the loss on this piece?

One other possible issue: im not sure but if the DACS are triggered by an independent clock signal that is actually off spec then this could also be the result.

It might be worth checking if you can locate the crystal oscillators and check them for stability. Easy fix to replace them. Would need a scope to do this though.....and the service manual.

Just a last resort....

Another way to diagnose is to inject digital control signals into the board to see if you can reproduce this in different ways under your control or to remove other sources of interference eg remove memory, roms, hard drive, floppy from being powered up and then focus on the specific circuit if it can be narrowed in on. Ie "known bad" situations vs "known good but failing" . That way you can narrow down to the signal path involves and the parts in it which might lead you to conclusions. It's a different way to diagnose and requires a signal injector probe for CMOS/or 3.3v high impedance signals.

You have tried it without the two ROMS in it right? The emu has issues if two ROMS are installed certain slots at e same time.....

M

Again, messy work, only for the dedicated.