Recording Internal and external audio simultaneously (and then maybe balanced)

84 views
Skip to first unread message

Piers

unread,
Nov 17, 2010, 6:37:36 AM11/17/10
to Magic Lantern firmware development
Thought I'd split this off.

From looking at the data sheet, it seems that simply setting one of
INL or INR to 1 and the other to 0, you'd be recording one track from
the internal input and one from the external. So I gave that a go

Setting AUDIO_IC_PM3 to 0x3 (around line 530 of audio.c) - which I
think should mean left from internal, right from ext - resulted in the
upper VU meter showing external audio and the lower being fully red at
0dB (sounded a lot like DC when I recorded a clip and played it back
externally). So I got halfway to where I wanted to be, with only one
external track ;-).

setting the value to 0x1, which I think should mean all internal,
resulted in some strange little noises at the start of a clip, but
basically no audio.

I also tried setting AUDIO_IC_PM1 to 0x41 - as per the data sheet p.71
- instead of 0x6D (this is line 515 of my audio.c) which turns on the
external speaker circuit and some stuff I don't understand, but this
had no apparent effect.

Thoughts?

PG

Morgan Look

unread,
Nov 17, 2010, 4:05:30 PM11/17/10
to ml-d...@googlegroups.com
Please forgive me if I have missed something here, but it seems to me
that a step is being missed when manipulating register values.

looking at https://bitbucket.org/hudson/magic-lantern/src/tip/audio.c
which I assume is what everyone else is referring to?

In my (somewhat limited) embedded programming experience;
If you wish to turn bits on you use a bitwise OR with the bits you want
set to 1, and all other bits set to 0.
If you wish to turn bits off then you need to use a bitwise AND with 0's
for bits you wish to clear, and 1 for all other bits.

For example, when setting the external input.

audio_ic_write( AUDIO_IC_PM3 | 0x07 ); // external input

According to my understanding this will set bit2-0 to '1', and not
affect the state of the other bits in the register. That's okay.

But when you try to enable the internal microphone input

audio_ic_write( AUDIO_IC_PM3 | 0x00 ); // internal mic

This to my understanding will have no effect on the register. If it
happens to already hold the value 0x00 then fine, but it will not
explicitly set the values to '0'. Whatever value is already in the
register will remain there.

If you wish to set b2-0 of AUDIO_IC_PM3 to '0' then you should AND the
value with '1's in the other positions.

audio_ic_write( AUDIO_IC_PM3 & 0xF8 ); //AND with b11111000 (0xF8) to
turn b2-0 off.

I would typically always use AND followed by OR in any register
manipulations, even if you are not planning to clear any bits at the
time you write the code, it allows easier modification later if both
statements are present. The AND can be a general mask for the bits
you're interested in, and the OR can be the bits you wish to set (even
if it's all the same bits you cleared with the AND statement).

So the code might look something like this...

audio_ic_write( AUDIO_IC_PM3 & 0xF8 ); // clear b2-0, set below where
required
if( mic_in )
audio_ic_write( AUDIO_IC_PM3 | 0x00 ); // internal mic
else
audio_ic_write( AUDIO_IC_PM3 | 0x07 ); // external input

Again I apologise if I have missed something here.
Regards, Morgan.

Piers

unread,
Nov 17, 2010, 5:52:35 PM11/17/10
to Magic Lantern firmware development
I actually haven't (yet) bothered to read what audio_ic_write() does,
but I'm assuming from way it's used elsewhere that it unpacks the
value passed to it, using the higher byte(s) as an address and the low
byte as the value (or if it doesn't unpack, it just inherently uses
them this way).

The constants (e.g. AUDIO_IC_PM3) are defined in audio.h as four digit
hex numbers with 00 on the end - they're a constant address, not a
dynamic current value. (I'm learning too, but I know CAPS is a
convention to indicate something's a constant)

So my understanding of

audio_ic_write( AUDIO_IC_PM3 | 0x00 )

is "put 00 into the PM3 register".

If you DID need to get the value of a register, there is
audio_ic_read()

But keep thinking! Be good to know if anyone's ever got the internal
mic to work with ML 500D

PG

On Nov 18, 8:05 am, Morgan Look <morgan.l...@gmail.com> wrote:
> Please forgive me if I have missed something here, but it seems to me
> that a step is being missed when manipulating register values.
>
> looking athttps://bitbucket.org/hudson/magic-lantern/src/tip/audio.c

Piers

unread,
Nov 22, 2010, 8:08:21 AM11/22/10
to Magic Lantern firmware development
Well, I don't know what I was doing wrong the first time I tried, but
with mic power on (via the .cfg file) and this replacing the
conditional at line 527ish of audio.c:

audio_ic_write( AUDIO_IC_PM3 | 0x05 )

I was able to record from both an external mic and the internal one.

I think the int mic is connected to the L channel only and requires
mic power to work. Must've just not managed that combination before.

So I'm thinking a flag like "audio.split" and a note in the .cfg
comments that audio.mic-power is required might be the way to go. Or
maybe just a note that it will force mic power on.

(Or, we could do more coding and have something like "audio.source=int|
mixed|ext"?)

As for balanced audio: it should be simple, but I have no balanced
gear, no special 3.5mm plug and even if I did, no real way to confirm
that the balanced audio was working.

Anyway, I'm a bit pleased for the night!

PG

Piers

unread,
Nov 23, 2010, 6:28:22 AM11/23/10
to Magic Lantern firmware development
OK, I have a release which I've added a new audio parameter to, it's
documented in magic.cfg as follows:

# input_source (new). Lets you mix between internal and
# external sources. Where the int mic is used, mic-power
# will be forced on
# 0 == internal mic (dual mono)
# 1 == Int mic L, ext mic R
# 2 == Ext mic, stereo (default)
# 3 == Int mic L, ext L+R input as balanced
audio.input_source = 2

Seems to work, It's based on Alex's fork (I think). The balanced I
haven't really tested properly, but there's sound coming thru. I've
also modified the gain values in magic.cfg to use maximum mgain, based
on the "5DFilmSchool" films on YouTube (which Trammel is in some of) -
specifically this http://youtu.be/cwpDLo0NVps in short, you get least
noise by doing as much analogue gain as you can before resorting to
digital.

But ... hey, how do you attach files?? Maybe I have to send a "real"
email ...

PG

Piers Goodhew

unread,
Nov 23, 2010, 6:29:35 AM11/23/10
to ml-d...@googlegroups.com
Here's my build for folks to try:
ML0.1.9 550D selectable audio.zip

Alex

unread,
Nov 23, 2010, 7:14:08 AM11/23/10
to Magic Lantern firmware development
Very nice, thanks.

You just gave me an idea: I'll test my disassembly scripts on this
build, since it's much faster :)

On Nov 23, 1:29 pm, Piers Goodhew <pi...@u-h-p.com> wrote:
> Here's my build for folks to try:
>
>  ML0.1.9 550D selectable audio.zip
> 36KViewDownload
>
>
>
> PG

Morgan Look

unread,
Nov 23, 2010, 7:46:16 AM11/23/10
to ml-d...@googlegroups.com
Nice work Piers.

You may want to add one more option to audio.input_source for external
balanced only, I guess some people may not wish to record the internal
mic for whatever reason.

It will be interesting to see how the noise compares on the balanced input.


With respect to analogue and digital gain...

If you have an external microphone amplifier (or mixer). You may get
lower noise by having the mgain turned down on the camera (assuming the
external amplifier is quieter than the internal one).

In general you will want each stage to be turned up as high as possible,
without over driving the next stage.
So in accordance with your comments; if mgain is your first analogue
amplifier stage, then turn it up as much as possible without over
driving the ADC. But don't turn it up all the way if you have to turn
your mic down externally to stop it peaking out.

As for digital gain. I can't see any reason to use digital gain on the
camera (or any digital filters for that matter), since there is nothing
they can do which cannot be done on a computer. Any distortion
introduced on camera cannot be removed later (whereas some computer
software allows non-destructive editing so you can add and remove gain
or filters at will).

Morgan.

Piers

unread,
Nov 23, 2010, 6:27:29 PM11/23/10
to Magic Lantern firmware development
I'm thinking I'll leave the int + balanced option as-is .. there's no
penalty for having int (apart from the work of removing it later) and
it gives you that redundant mic for when your big mic dies during the
crucial unrepeatable shot.

Re don't-mess-with-the-digital, yes I'm certainly planning on adding a
"no_filters" flag, probably as early as tonight. (that would be the
HPF, LPF and the stereo emphasis, all off)

PG
> > specifically thishttp://youtu.be/cwpDLo0NVpsin short, you get least

Alex

unread,
Dec 6, 2010, 4:41:27 AM12/6/10
to Magic Lantern firmware development
I've just run your build and found a bug:

While ML is running, I can't download any more the photos via USB
cable (the camera does not react when connecting it with the computer,
and no new messages appear in dmesg log).

With Trammell's RC1 build, it works well.

I'll try to run my own builds to see what happens.
> > > specifically thishttp://youtu.be/cwpDLo0NVpsinshort, you get least

Alex

unread,
Dec 6, 2010, 5:19:51 AM12/6/10
to Magic Lantern firmware development
My build has the same bug, so the problem should be somewhere in the
changes made after RC1.

Alex

unread,
Dec 6, 2010, 6:30:35 AM12/6/10
to Magic Lantern firmware development
I've tried to comment the last line in hotplug.c:

//TASK_OVERRIDE( hotplug_task, my_hotplug_task );

Result:
First time, camera rebooted when connecting it to USB.
Subsequent times, camera just hangs and does not respond to user
input. I took the battery out and now it's alive :)

Alex

unread,
Dec 6, 2010, 7:15:09 AM12/6/10
to Magic Lantern firmware development
Solved by upgrading to GCC 4.4.2 (the same version used by Arm.Indy).
USB downloading works with the last line in hotplug.c commented.

=> don't use GCC 4.3.2 to build ML!
Reply all
Reply to author
Forward
0 new messages