600D Audio Controls?

[1%]

I think we should just add audio_something.h and C and leave audio.c the way it is. That way less ifdefs and we're not bound by the stuff in audio.c Also, our work won't have any affect on the other cameras.

[miyake]

I've made a lot of merging lately, now most of 1% code is in my fork with miyake's also.
I've added more value in audio.h and also the read registers like 1% did for audio6.h.
take a look,menu is a bit messy right now...

Ah just finished reading your marge. It's not so bad!.
I will try to modify, more clean ifdef usage.
And let me remind you that is you do not use ifNdef *... (How can I say ) minimum use is better...*.
Human brain is poor. sometime miss reading a lot of combinations of ifdef/ifNdefs.

Already audio.c had a 500D entry.  We will add 600D ifdefs. It's a really hard to read codes, I guess.
It means Alex had a difficult to manage audio.[ch] . 
I think , we need to think about this too.

[1%]

Did anyone else try the function generator? It beeps fine but when I play a tone it plays it and then gives me an error 70 in memory something.


MVR.h already exists in all of the platform folders. Alex never said we HAD to keep everything in audio.c

[miyake]

I think we should just add audio_something.h and C and leave audio.c the way it is. That way less ifdefs and we're not bound by the stuff in audio.c Also, our work won't have any affect on the other cameras.

1%:
I agree. It's one of answer for it. But now, scrax's porting is not so bad.I will try to maintenance it.
Finally, We judge , which method will we use to main repo.
OK?

One more thing.
You added a lot of unused defines and functions. It means , a lot of memoy needed.

So I think , If you simply comment out those functions(for future use)  or define ifdef CONFIG_600D_AUDIO_NEWFEATURE.
Then another user do not define CONFIG_600D_AUDIO_NEWFEATURE. don't need memory for it.
How about this? I can't understand which your function is used or not.

[1%]

I don't think we'll need the debug functions anymore. We can cut out the read registers if necessary, especially if we don't end up using them. I still have over 900k free.

[scrax]

I had no errors with beep generator.

For me we can have ifdef in audio.h and an oki.c in 600d folder for our code if we can keep there only 600D part without duplicate common code from audio.c (instead of what i did for audioki.c)

I've just tested and meters works also with audio disabled, and seems that canon don't override anymore IC setting, like 1% was supposing.

so i've removed the check for the 600D and all things works with audio disable so far, not tested a lot. but fork is updated.

[miyake]

scrax

I understood that you are ported a little old my codes. some codes are not available

Will solve it.

[miyake]

Now 1hour thinking how to marge current codes......................................
......
....
...
..ajfdsalfjdksalfjdskalfjsdkajflsdoeiwtgiosanvo

We need to think usage of repos........  Currently, need more extra work in this systems.......
 

[miyake]

1% please remove your debug code from audio.c first.
I think most your code is not production level.
Also 30 percent of my code is already implemented your debug functions(gain boost filter input select..).

It's not good to import your debug code to audio.c
debug is must put audioki.c.

So now, It's really confused, and I can't write code current repo.
Because I need a lot of  cleanup works.

It must merge production code only in audio.ch , I think.

How do you think?  Do I start my repo for creating after things?


P.S. audio.h is correct succeeded.

[1%]

Yea, now I can fix the volumes and mic selection values... there was only a few things in audio.c, most of it was in debug.c. If you look I restored the old audio.c so there is nothing in there. Everything is in audio6. We have new volumes like headphone and boost2 to add and values can be converted to db, etc. All of that stuff was written before we had a datasheet and is guesswork.

Now our reversing can be implemented into useful features and production code, etc.  But your frustration is why I think its a bad idea to keep everything in audio.c. Even if we have to copy the meters to okiaudio or audio_whatever its still better than 1 million ifdefs. Also T3 has different audio and will need its own audio.c and probably some of the new cameras too. Its one change to dryos.h to add a new .c/h file.

[miyake]

Thank you for your understanding.

1, why I need to import our code to audio.c
  I think, It's for Alex. If we add clear code in audio.c, he is only need to manage single files. Also we can get Alex's code tweak.
 
2, why I got frustration
 Now I'm main worker for 600D audio. But the repo is not mine ,  scrax's work is really good and provided a good platform to us at that time. But now, he can't understand all of codes when he marge our codes.(too much codes are confusing to him)
 The codes are back to old one . and deleted duplicate functions are revival.

So I think, we need to move my repo. I'm almost finished porting audioki.c to my repo.

Then, If you write a production code ,you fork my repo. and make a  pull request to me.
And, tragic-lantern will going for your debugging.

It's my concern. How about it?

P.S. Now my code is , agc on/off,  controlled from menu . and HighPass filter bug is solved.

[scrax]

Not sure if it could be of some help but I give you and 1% write permission on the 600Dplus fork.

In my opinion both option are good, what I think is that some code is "universal" like the audio meter and need to stay in audio.c for all the camera, other thing like audio for 600D are so camera specific that can be moved in platform.
also is audio.h has 600D registers like now, audioki.c can be used without changes in dryos.h, only the Makefile needs to be edited.

About Volume control.
Miyake's one is strange because at 7-8 I have more volume than at 11, same at 12-13 vs 15-16. But I like how analog, digital and boost are combined in one simple option.
1% submenu are more complete but slower to set and understand, and also why are they showing auto int/ext?
they need some cleanup to be usable, change the value shown, etc.
If we can have a Volume option that can go from 0 to what is max with set and play and with Q open a sub menu with all the single volume options , analog and digital it would be the best of both.

[miyake]

check up my repo
https://bitbucket.org/miyake_t/magic-lantern-miyake

really a lot of time need to merge.

A little bit more ifdefs. But it's not so bad, I think.


----
1%
config val to dB value is not implemented. Because Dryos has no %f. only %d. So we can not understand the difference of 1 and 1.5. So I used integer value.

[scrax]

check up my repo
https://bitbucket.org/miyake_t/magic-lantern-miyake

really a lot of time need to merge.

A little bit more ifdefs. But it's not so bad, I think.

trying to merge now.

[miyake]

forget everything! just copy is easy

[miyake]

Ah, just remember that current my repo had a movieAF testing.
I think new repo is better for porting back to main repository.
I will do that.



hg clone https://miyake_t@bitbucket.org/miyake_t/magic-lantern600daudio

[scrax]

yes, af give me problems, thanks

[1%]

Hehe, keeping the AF (almost done pulling functions so hopefully I can help you with what the numbers mean). Meters could stay in audio.c but we don't need all of the other registers in audio.h. For simplicities sake I was going to copy them into the platform file and forgo audio.c/h completely... Its honestly a few kb of text, even if its duped it won't make a difference on compile. The compiler will just ignore it. Alex is really good, I don't think he will have a problem maintaining 2 files vs one.

also why are they showing auto int/ext?

I never set the last option. Auto int/ext is basically none. I have to get rid of that and now that I have the datasheet and the right values I can.

Miyake's one is strange because at 7-8 I have more volume than at 11, same at 12-13 vs 15-16.

I have to compare what was done to the datasheet. If you look over that you'll see what values are supposed to mean what dB value. I've just had this whole week taken up... just got home now, left at 6am so thats like 13+ hours of stuff.

Also have to figure out if audio gets written to the video files when sound is off. We could theoretically leave sound off in canon and have our own on/off (has to work without crashing the MVR). Rec/Play/Run also has an auto mode that is supposed to do something, that may help.

We're much much further along than even a couple of days ago.

[miyake]

-Af func will keep my MagicLanter-miyake repo.

-Now we have merged audio.c and audioki.c So I think, Alex judge which one he want to use.

-AutoInt/Ext is actually not set audio input in our codes. so cannon firmware will set correct value, I think.

-analog gain is mic vol and mic boost combination. Just simply added analog gain framework. I don't know it has bug or not.The framework is important and and It's easy to solve bug when we already using a framework.  So please find bug , and solve it.

---my concern
-we need to start using issue tracker?
 -current functions are almost implemented which is in menus.(basic funcs)
 -Just writing framework, and I know that It has a lot of bugs yet.
    - reg value combination when we  change config from menu.
 -test volunteer offer using autoexec.bin must not be start before Aug, 13 . It means a ML2.3 is out to public.

-why we need to stabilization now and only implemented basic funcs?
  -The difference of main repo is really big. I think alex can't(or hard to understand) handle a lot of codes. I think , we push current basic funcs now. and then If we found extra funcs and implemented. I will push again. The difference is a little. easy to undestand it.
  -We need to merge work when main repo is updated.  So I hope basic funcs will be import to main repo when we finish solving a bugs. it's easy to maintain code difference.

[scrax]

Also have to figure out if audio gets written to the video files when sound is off. We could theoretically leave sound off in canon and have our own on/off (has to work without crashing the MVR). Rec/Play/Run also has an auto mode that is supposed to do something, that may help.

 

I'm testing with miyake's code, removed check for audio enabled and I can record, change audio and filter when in rec. Not tested changing input or monitor mode. It gives some pop and clips when audio starts rec (we probably need to wake up the ic more "gently") or when changing some volume values.

So I think too that if your idea is correct we can force with ML audio off when Audio Override is On and manage audioIC with ML.

False report, I was supposing it was off in canon manu, instead it was on, when off audio is not recorded...

note: rec digital gain is "inverted" value go down when pressing right arrow. (fixed)



If don't rember wrong Alex told me audio.c is is still code from Trammel, maybe it's time to update it for the various audio IC there are around considering future ports also...

[miyake]

600D audio current status.

[miyake]

So I think too that if your idea is correct we can force with ML audio off when Audio Override is On and manage audioIC with ML.

ah, I think so. So we need mute menu? now "override off" is do the all register off.
So we can mute when recording.But re-override is not working now. (I found just now).

note: rec digital gain is "inverted" value go down when pressing right arrow.

Solved it.

If don't rember wrong Alex told me audio.c is is still code from Trammel, maybe it's time to update it for the various audio IC there are around considering future ports also...

Really? It's time to talk architecture with Alex.

[scrax]

I was wrong, when audio in canon menu is off , also if enabled with ML it's not recorded, so there will need more test.

found another little typo in

audio_filters_toggle( void * priv, int delta )
{
    menu_numeric_toggle(priv, 1, 0, 1);
    audio_ic_set_filters();
}

it has
 priv, -1,0, 1);  in yours

[scrax]

ah, I think so. So we need mute menu? now "override off" is do the all register off.
So we can mute when recording.But re-override is not working now. (I found just now).

I don't know if with override off was working with code from 1% maybe?

[miyake]

I don't know if with override off was working with code from 1% maybe?

No, It's my code. which 1%'s function are you talking?