Channel Bleed?

Don’t know if this is firmware related, a bug or a physical issue, but noticed there is channel bleed today between outputs 1 and 2. Putting a Triangle oscillator on channel 1, monitor output of channel 2 and I can hear that oscillator despite having nothing on channel 2, same if I have nothing on channel 1 and put a triangle osc in ch 2, I can hear it from the output of ch 1.

Only bleeds between ch 1 and 2.
3 and 4 are not affected.

Anyone else experiencing this?

Yes, also nothing else connected except either output 1 or 2 to the main out.

I can confirm this issue on my fairly new 301 on the latest firmware. But it is only noticable for me when i turn up the volume and nothing else is playing :robot:

edit: also happens the other way around (oscillator on channel 2 - minimal soundbleed on channel 1). It doesn‘t occur on channel 3 and 4.

1 Like

How are you listening to the channels? Have you removed the possibility that your outboard or modular mixer is causing it?

May we assume that you have the empty channels disconnected from monitoring?

Ch 1 OCS, Ch 2 empty.

Monitor line: Ch 2 out to RIP in 1, rip out 1 to mixer in, mixer out to speakers.

Ch 1 out is not patched to anything. Nothing else is patched in the system.

More obvious with higher frequencies.

@ilias thanks for your reply, good to know I’m not the only one experiencing this and that it could possibly be firmware related.

@odevices @mopoco - this isn’t happening on both your systems with the latest 48k firmware?

1 Like

can’t check right now (at work)

please, make sure that there’s

  • only one cable between er301 and RIP (on empty channel)
  • also only one cable between RIP and mixer (on empty channel)
  • only one cable between mixer and amp/monitor (on empty channel)
  • in case of separate amp/speaker: no speaker cable between amp and speaker
    (on empty channel)

for clarification: bleeding is a common “feature” on modules and outboard hardware
(mixing consoles, audio interfaces and even stand alone or integrated amplifiers)
that are handling 2 or more channels.
this does not mean necessarily that the er301 isn’t the cause. but in order to rule out other
causes you’ll have to check your other equipment first…

keep us posted…

@mopoco - think its best if you check your system (if you want to of course) before requesting me to check mine again. As I’ve already explained quite a number of times the setup I have connected to check this and I can safely rule out any other leaks coming from anywhere else.

And sorry but this sort of leak isn’t a feature for me, especially not when as mentioned by @ilias above, it did not seem to be happening in previous firmware versions.

i will do so as soon as i find time for my studio!
(and i will take care to set up the very same physical connections
i asked you to :joy: )

i “quickly” tried to reproduce using the following steps:

  • turn on the ER-301 in a blank state, no cables in any output.
  • insert Aliased Triangle on channel 1, set frequency to ~ 550Hz and level to 1.
  • monitor outputs using a 2xTSm to TRSm cable. The TRS end is plugged into a Sony PCM-M10 recorder, the left TS is plugged into ER-301 channel 1, the right TS into channel 2
  • Headphones are plugged into the headphones out of the M10.
  • the recorder gain button is set between 2 and 3 (on a scale of 10) to have the triangle be at -3dBFS on the recorder “peak-meter”.
  • hit record on the 301 and on the internal 6 track recorder.
    During all the recording, the aliased triangle is always running on channel 1. There is:
  • section 1: 10 seconds with ch1 and 2 plugged in.
  • section 2: 10 seconds with ch1 unplugged on the ER-301 side
  • section 3: 10 seconds with ch1 replugged
  • section 4: 10 seconds with ch2 unplugged

Here is the stereo file from the M10: (Caution with monitoring levels ! It might be loud on your system.)
Here is, from the same file, only channel 2, with an additional +45dB of gain applied in Audacity:

How do i empirically interpret those results:
there is some crosstalk between channels happening on the ER-301. But it is much less than the crosstalk happening in my {adapter cable + recorder} apparatus (sections 1 & 3). It is also of the same order of magnitude than the recorder self-noise (section 2). My recorder also does weird things (section 4) when an input is floating.

The same behavior happens between channels 3 and 4 on my unit. But not between ch 2 and 3. I guess all we have here is the specs of the DACs + maybe some influence of the case power supply.
I do not feel this channel bleed is a concern.

(p.s. as expected, the 6 track internal recorder taps into signals at the digital level, so channel 2 is absolute zeros on this recording.)
edit: this was done running firmware 0.4.11 48kHz. Maybe i’ll check later if the same thing happens on 0.3 stable.


just checked my sound computer (old rev) with latest fw 0.4.20@48kHz. all output channels are
perfectly isolated.

@theelectricyouth: forgive my curiousity, but what is “RIP” and what kind of mixing console and speakers do you use?

Oh, that rip might be those rare cinemag transformers from mannequins, i guess. I am by no means an expert on those…
But given that your er301 would only give you the kind of crosstalk
That @ermina had measured on her/his unit I would expect that the rip would drop its level to a point where it wouldn‘t bother you.
And again, out of curiosity, but also out of worry your unit might be damaged after all: and given your mixer provides enough headroom,
What do you experience if you leave the rip out of your setup?
(For i‘d Expect the crosstalk to be worse…)

RIP no RIP, is in my view a bit irrelevant in the whole equation as the output of the channel with the actual oscillator isn’t connected to anything and RIP isn’t even connected to the power supply, which erases any crosstalk that could come from the power board. Thus, my sentiments are strongly leaning towards cross talk happening within the 301.

On top of this crosstalk issue, there is a tiny offset on each of my A-D inputs, very small but with nothing patched into them, when I assign them to any parameter, v/oct for example, it doesn’t read 0 but -1c, -2c or something fluctuating between.

Don’t know of course if the issues are related or if this is a non-issue.

It does bother me hence the post. I can hear the crosstalk without having to boost it by 45db as per @ermina.

I’m on the latest rev, wondering if this could be the issue, waiting to hear from @odevices regarding these issues (or non-issues).

The following tests were conducted with a revision 7 and a revision 10 ER-301 powered by Intellijel’s TPS30W. Firmware was v0.4.20.

Test 1

  1. I inserted a Saw Osc (1kHz) on OUT1.
  2. I patched OUT1 to Intellijel’s Headphone 1U tile in the same case and made sure I could hear the saw loud and clear with headphones. Headphone volume set to 25% resulted in ear-splitting saw wave.
  3. Then I moved the patch cable from OUT1 to OUT2. Auditioned with headphones again, moving headphone volume up from 0% to 100%. No sound.
  4. Then I moved the patch cable from OUT2 to OUT3. Auditioned with headphones again, moving headphone volume up from 0% to 100%. No sound.
  5. Then I moved the patch cable from OUT3 to OUT4. Auditioned with headphones again, moving headphone volume up from 0% to 100%. No sound.

Test 2

  1. In System Settings, “Displayed value for unit control readouts.” is set to ‘bias’ (edit: Oops. I mean ‘actual’.). Nothing is plugged into the ER-301.
  2. Using the same Saw Osc from Test 1, I set the V/oct sub-chain source to A1 and check the V/oct readout below the V/oct fader on the oscillator. Stayed at 0 cents with no fluctuations.
  3. I repeated step 2 for all ABCD inputs. No fluctuations in the readout were observed.

The fact that you are getting fluctuations when nothing is plugged in might imply that your case’s ground is carrying a lot of noise for some reason. Unplugged jacks are connected to ground. I would try to isolate the problem by powering the ER-301 in another way and repeating the tests. Of course, you are always welcome to send your ER-301 to me for analysis but whatever isolated testing you can do on your end will help.

Definitely check the ribbon cable too. Perhaps swap it out with another one.

1 Like

Thank you @odevices for checking. Will answer first regarding test 2 as I see the variation between our settings.

My settings were set to Actual and not Bias. Now that I did the test with Bias, the readout is 0. Wondering what that means.

For Test 1 - I have removed the unit and inserted it into a different case with a different cable. Still bleed when monitoring directly to headphone amp module.

Could this be something with the last Rev of the board? As that looks like the only variable I can see between your tests and mine.

Let me know and I could make both a recording and/or a video if necessary.

Oops. I meant to say ‘actual’.

I did the tests with both revisions. There are only two in circulation.

Ok so the problem remains.

I unfortunately do not have any other power supplies to test the unit with.
If it is ground noise as you suspect, should I disconnect the ground temporarily to make a test?

How should we proceed with these issues?

Disconnecting ground will make things worse, so don’t do that.

You could try removing all other modules to at least make sure it is not some other module dumping noise on the ground line. Did you try another ribbon cable like I said?

And still have the same offsets on the ABCD inputs.

I can look into this, though when I inserted the unit into a different case with a different set of modules, it produced the exact same results in terms of the percentage of offset per input (to clarify: some inputs are 0, some are -1c, some are -2c, some are fluctuating between 0 and -1c, and some are fluctuating between -1c and -2c.).

And the channel bleed issue, is it a separate issue or could it be related?

To clarify again the channel bleed issue on my unit. It is only happening between Ch 1 and 2. Meaning when there is an Osc in 1, I can hear it from output 2, and vice versa. Ch 3 and 4 are isolated and unaffected.

But trying it in a different case does imply you tried a different ribbon cable.

It is possible that the two problems are related.

Yes, I know but I tested all of them for completeness of the test.