DV Info Net - "Headphone Jack"

DV Info Net (https://www.dvinfo.net/forum/)

- Canon EOS Full Frame for HD (https://www.dvinfo.net/forum/canon-eos-full-frame-hd/)

- - "Headphone Jack" (https://www.dvinfo.net/forum/canon-eos-full-frame-hd/236698-headphone-jack.html)

"Headphone Jack"

Yeah, "Headphone Jack" is in quotes.
I've been doing video for 12+ years and am still learning about the trade - especially audio.

Jon said (in another thread):

Quote:

Originally Posted by Jon Fairhurst (Post 1153600)

If/when you buy a recorder, keep in mind that the inexpensive ones (under $1k or so) have so-so preamps. I've got the MicroTrackII and the result with an AT815b plugged straight in was too much hiss. I've now got the juicedLink CX231 stereo preamp, and am getting much better results. It's active, so I can turn up the gain in the juicedLink and turn down the gain on the recorder.

The juicedLink is optimized for placing in front of a camcorder-type recorder with a 1/8" stereo plug and mic levels. When/if we can set the gain in the 5D MkII and monitor the audio, the juicedLink will be a nice companion.

There's a new Beachtek product that you can put upstream from the 5D, but it's passive (no gain, so you still get preamp noise downstream, if your mics aren't sensitive enough.) It has a built-in pilot tone that helps control the 5D gain, but doesn't solve the monitoring problem.

For the same price as the juicedLink, you can get a mono preamp from Sound Devices. It's active, but meant for feeding an XLR input at line level. You'd need to pad it down and use a converter cable for use with the 5D or other 1/8" mic input recorder. It could work as the front end to a Zoom H4n or MicrotrackII, but costs twice as much as the juicedLink per channel.

Anyway, whatever you get, consider a clean active preamp. If your microphone has a hot output, passive is okay, but if you use a low-sensitivity mic, or want to pick up low level or distant sounds, a clean, active preamp is the way to go. Assuming you have a decent mic, the preamp is the next most important piece of audio gear.

Now, I'm wondering: even if Tramm is able to get us these great meters and bypass the AGC, how beneficial will that be to the videographer who's really concerned about the audio.
A grand setup for my workflow would be my Senns into a 2 or 4-port JuicedLink, then that into the 5DM2.
If we can't actively monitor what the camera is hearing, does this mean we will be relegated to always using a secondary recording device for pro audio? Or is there a CHANCE that the A/V jack can indeed be re-purposed to serve as a headphone jack?
I thought I read here that this isn't a possibility.
Seeing the levels bounce is all fine and well, and if you have time to check every shot (or every few shots) you're golden.

I'm just wondering what the potential reality of headphones coming our of our much vaunted 5DM2 is.

We're hoping that Tramm can do exactly that - make the A/V output jack active for sound and video - without turning off the LCD!

This was from the JVC HD7 Forum on a similar subject

"Goto radioshack and buy part #274-368 called a Stereo-to-Mono audio adapter. Accepts 1/8" stereo phone plug. Fits 1/8" mono phone jack.
The above is what is on the package so you can identify it. It cost like $2.
Plug it into the AV port and plug your headphones into the adapter.

Simpler than any of the solutions I've seen posted on the net.

Basically how it works is, you know if you just plug your headphones in you get one ear of static and the other correct sound. The mono plugs just pulls out the one side of audio and ignore the static side. You will be getting mono sound instead of stereo, but for monitoring purposes I don't need stereo."

There's another solution by Steve Mullen which I may be able to pass on later.

Avey

Quote:

Originally Posted by Wayne Avanson (Post 1153788)

I didn't think the 5D2 put out anything (audio) during recording. Not on any of the a/v outs. If not, this won't help. Can anyone confirm?

I assume it does since they put an AV lead in the box with the usual red white and yellow leads on the end.
I haven't tested it however.

Quote:

Originally Posted by Wayne Avanson (Post 1154438)

I assume it does since they put an AV lead in the box with the usual red white and yellow leads on the end.
I haven't tested it however.

In the previous firmware, audio-out was supported on playback, but not during recording. I assume that hasn't changed in 1.1.0.

Hey Jon. I have never tested this, but before you push the record button, is there sound out through the AV jack, so at least you could pretest sound levels ? I will check it out tonight, but it could be of some help.

Quote:

Originally Posted by Chris Barcellos (Post 1154488)

Hey Jon. I have never tested this, but before you push the record button, is there sound out through the AV jack, so at least you could pretest sound levels ?

As I recall, it only worked during playback.

Please prove me wrong. :)

Quote:

Originally Posted by Jon Fairhurst (Post 1154534)

As I recall, it only worked during playback.
Please prove me wrong. :)

I haven't been able to test it yet, but I believe I have found the functions that turn the audio IC on and off, and the code that calls to turn it off after playback. Once I have the "Err 70" bugs worked out while recording, I plan to explore this bit of the code some more to see if it works in a "loopback" mode to drive the A/V output while recording. There may be some hardware required to convert the line level output to headphone level, but that's pretty simple.

If we can get it all to work with the AGC off, while displaying onscreen meters, driving a headphone output and using a high-quality preamp like the CX231 for XLR mics, the 5D will really be ideal.

Quote:

Originally Posted by Tramm Hudson (Post 1154616)

If we can get it all to work with the AGC off, while displaying onscreen meters, driving a headphone output and using a high-quality preamp like the CX231 for XLR mics, the 5D will really be ideal.

Let me add one more requirement: "and if the recorded sound is relatively clean."

I'm hoping that by turning down AGC, we'll be able to reduce the hiss, and that the crosstalk from internal circuitry won't be too bad. So far, the results with the pilot tone approach are a bit dirty. There's no telling if a proper AGC reduction will clean things up or not.

We will see...

Tramm, You're awesome!

Quote:

Originally Posted by Jon Fairhurst (Post 1154534)

As I recall, it only worked during playback.

Please prove me wrong. :)

Sorry, can't. No sound to my monitor that has sound input, before or during recording. Only on playback..

Tramm: As you work on av out, note that I and others have detected noise interfering with mic input, when we are hooked into AV out with a monitor. A constant tone is fed back to mic line for some reason..

Quote:

Originally Posted by Chris Barcellos (Post 1154651)

Sorry, can't. No sound to my monitor that has sound input, before or during recording. Only on playback.

Dang. Every once in a while, I *want* to be wrong. :)

Quote:

Originally Posted by Chris Barcellos (Post 1154651)

Tramm: As you work on av out, note that I and others have detected noise interfering with mic input, when we are hooked into AV out with a monitor. A constant tone is fed back to mic line for some reason..

I won't be able to test that until I'm back at my lab. For triggering the video events while on the road I am plugging my iPod headphones into the jack to cause it to produce the events. Here is the debug manager log when it is plugged in:

1086: 7586.248 [HPD] Video Connect ->->->-> O
1087: 7586.783 [MC] DisplaySensor : 1(1)
1088: 7587.381 [GUI] MainEventHandler VIDEO_CONNECT
1089: 7587.458 [DISP] SetDisplayType (PUB) 0->1, fDisplayTurnOn=1
1090: 7587.728 [DISP] RequestNotifyBlank img=0 bmp=ff860864
1091: 7602.153 [DISP] VdInterruptHandler img=0 bmp=ff860864
1092: 7602.215 [DISP] BackLightOff fInitialized=1

The bummer is that this is triggered by an interrupt and calls the code to directly output the property change. This means that my code will need to re-register the interrupt handlers and perhaps re-write the entire hotplug_task() function. Luckily it isn't too long and since I don't use video, HDMI or TOE (?) it might work just fine to disable the hot plug function.

Quote:

Originally Posted by Tramm Hudson (Post 1154808)

The bummer is that this is triggered by an interrupt and calls the code to directly output the property change. This means that my code will need to re-register the interrupt handlers and perhaps re-write the entire hotplug_task() function. Luckily it isn't too long and since I don't use video, HDMI or TOE (?) it might work just fine to disable the hot plug function.

As long as I don't want to use the USB interface*, this works fine. I can plug my headphones into the jack and it does not trigger the switch to the external interface. That's great news; I can now write my own task to detect when it is plugged in and try to enable to audio device at that point.

*: USB support might be re-enabled later.