Announcement

Collapse
No announcement yet.

AMX Audio

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMX Audio

    There is a very important part of the detector that has been barely mentioned. The audio.
    I know that you have a lot of experience with audio. How about you start with the audio design of this detector?
    Based on your experience, how do you think the best audio should be?
    Carl mentioned some very basic criteria. Could you take it from there?
    And it should still be very power efficient.

    Bring your proposal to the table.
    Let other members of the team give their opinion and input.

    Do you think you could lead the "audio team?

  • #2
    Originally posted by Tinkerer View Post
    There is a very important part of the detector that has been barely mentioned. The audio.
    I know that you have a lot of experience with audio. How about you start with the audio design of this detector?
    Based on your experience, how do you think the best audio should be?
    Carl mentioned some very basic criteria. Could you take it from there?
    And it should still be very power efficient.

    Bring your proposal to the table.
    Let other members of the team give their opinion and input.

    Do you think you could lead the "audio team?
    Question for me?
    Ok.
    I've been advocating for years the truth you wrote in your first sentence.
    Though, all my posts about that were related to audio at VLF I/B, but for sure it applies to PI too.
    This will need a bit of history to tell, before the final conclusions.
    First time I saw and fully understood the great (if not crucial) importance of the audio at detector; was a while back ago when I had ML Musketeer for the first time in my life.
    It was "Colt" version, pretty simple, very few commands on front panel, kinda "turn On and go" type. But with splendid peformances for the time.
    Audio at it is so "simple" and uniform... only on the first glance!
    Several months later I familiarized with it to that extent; that I was able to tell the nature of detected target with more than 80% accuracy, beleive me or not.
    Single "pitch" audio. No amplitude rise. What to say; looks like worst possible design ever.
    Yet! Actually it is behaving so differently on different target... I am afraid my English is too bad to be able to explain. Even on Serbian I would struggle to explain.
    Anyone who ever used it seriously at least for couple of weeks; knows what I am talkng about.
    ML actually did a great job with minimalist approach. As simple as possible but with wide span behavior over different targets.
    Up from those times I am more like "audio" guy than "VDI" guy.
    Today with the Deus; I have extreme good comfort of very rich audio as well as with very good and accurate VDI.
    But despite that; during the day on a site; I barely look few times on LCD, mostly I make decisions relying on what i hear from the speaker.
    ...
    At the same time, and this is important to mention; I don't like ML kinda PI "meow meow" style of audio. It works good ONLY at ML machines.
    All the copycats that I saw later is just bad imitiations of the ML cat meowing!
    ML introduced first "meowing" with their SD series and I started to dislike it at once. But at least it worked good.
    Today, seems to me, such "meowing" audios are MUST in heads of those who ever try to desing the PI detectors.

    Comment


    • #3
      If you ask me what is the best audio I ever heard at detector; of course the answer will be the Deus audio.
      Just for a reminder, minute ago I searched and watched some White's TDI demo on Youtube, to remind my self.
      It is also of "meow" type... but somewhat better than I thought, more concrete and less anoying than at ML.
      I understand why it is done that way. at ML and later at all copycats too.
      To reach top performances with such PI; one must adjust to audible threshold on a very edge of audio saturation and than carefully listen the slightest variations in sound.
      This directly shows that if one adjust treshold to acceptable and bearable low level; it will loose significant percentage of performances.
      And that's bad. That's too bad!
      What I might propose is two or several channels audio.
      Without constant annoying "meowing".
      And without intense attention at user to constantly listen for the slightest barely audible changes in overall "cat orchestra musical", coming from the speaker.
      Dig that.



      Comment


      • #4
        I haven't a very broad exposure to a lot of different detectors with which to make an assessment. Of the detectors with which I have experience with, the detector with the least offensive audio is my Fisher 1265... which actually is quite pleasant. Which reminds me... the last time I had my 1265 fired up, I noticed that I needed to replace the speaker!

        Comment


        • #5
          Originally posted by ivconic View Post
          ...To reach top performances with such PI; one must adjust to audible threshold on a very edge of audio saturation and than carefully listen the slightest variations in sound.
          This directly shows that if one adjust treshold to acceptable and bearable low level; it will loose significant percentage of performances...
          This is bad for many reasons.
          -It draws battery faster = last and least important reason.
          -it destroys the user's hearing and nervous system, even though the user is not aware of it = most important reason
          - It actually shows how average a machine it really is, overpaid... because any machine that you "wind up" so that the threshold squeals constantly and you search for targets as barely audible and immediate changes... will give you more or less similar performance. ..
          (Ok, it's fair to mention the difference, not every machine will find subgram gold flake... but on dime sized targets the performance will be roughly the same...)
          So I would suggest right at the start to give up "meowing"; i.e. performances directly dependent on too high a threshold...

          Comment


          • #6
            Originally posted by KingJL View Post
            I haven't a very broad exposure to a lot of different detectors with which to make an assessment. Of the detectors with which I have experience with, the detector with the least offensive audio is my Fisher 1265... which actually is quite pleasant. Which reminds me... the last time I had my 1265 fired up, I noticed that I needed to replace the speaker!
            You and me, we are on the same track, relating to this.
            I mentiond ML Colt and also was tempted to mention exactly the 1265 along.
            But I skipped it to keep the post shorter.
            Yes, of course; 1265 is next to ML Colt as a bright example of the ingenuity of the minimalist approach.
            Totally agree.


            Comment


            • #7
              Originally posted by ivconic View Post

              Question for me?
              Ok.
              I've been advocating for years the truth you wrote in your first sentence.
              Though, all my posts about that were related to audio at VLF I/B, but for sure it applies to PI too.
              This will need a bit of history to tell, before the final conclusions.
              First time I saw and fully understood the great (if not crucial) importance of the audio at detector; was a while back ago when I had ML Musketeer for the first time in my life.
              It was "Colt" version, pretty simple, very few commands on front panel, kinda "turn On and go" type. But with splendid peformances for the time.
              Audio at it is so "simple" and uniform... only on the first glance!
              Several months later I familiarized with it to that extent; that I was able to tell the nature of detected target with more than 80% accuracy, beleive me or not.
              Single "pitch" audio. No amplitude rise. What to say; looks like worst possible design ever.
              Yet! Actually it is behaving so differently on different target... I am afraid my English is too bad to be able to explain. Even on Serbian I would struggle to explain.
              Anyone who ever used it seriously at least for couple of weeks; knows what I am talkng about.
              ML actually did a great job with minimalist approach. As simple as possible but with wide span behavior over different targets.
              Up from those times I am more like "audio" guy than "VDI" guy.
              Today with the Deus; I have extreme good comfort of very rich audio as well as with very good and accurate VDI.
              But despite that; during the day on a site; I barely look few times on LCD, mostly I make decisions relying on what i hear from the speaker.
              ...
              At the same time, and this is important to mention; I don't like ML kinda PI "meow meow" style of audio. It works good ONLY at ML machines.
              All the copycats that I saw later is just bad imitiations of the ML cat meowing!
              ML introduced first "meowing" with their SD series and I started to dislike it at once. But at least it worked good.
              Today, seems to me, such "meowing" audios are MUST in heads of those who ever try to desing the PI detectors.
              I dont know how the "colt" and the "deus" sound, but everything else you say, I fully agree.

              Comment


              • #8
                Originally posted by ivconic View Post

                This is bad for many reasons.
                -It draws battery faster = last and least important reason.
                -it destroys the user's hearing and nervous system, even though the user is not aware of it = most important reason
                - It actually shows how average a machine it really is, overpaid... because any machine that you "wind up" so that the threshold squeals constantly and you search for targets as barely audible and immediate changes... will give you more or less similar performance. ..
                (Ok, it's fair to mention the difference, not every machine will find subgram gold flake... but on dime sized targets the performance will be roughly the same...)
                So I would suggest right at the start to give up "meowing"; i.e. performances directly dependent on too high a threshold...

                I would agree with that

                Comment


                • #9
                  Originally posted by ivconic View Post

                  You and me, we are on the same track, relating to this.
                  I mentiond ML Colt and also was tempted to mention exactly the 1265 along.
                  But I skipped it to keep the post shorter.
                  Yes, of course; 1265 is next to ML Colt as a bright example of the ingenuity of the minimalist approach.
                  Totally agree.


                  I strongly believe in "playing by ear" audio. "Listen for the gold" Minimalistic maybe, but power efficient and easy on the ear while still being laud. For the AMX we do not want earphones.

                  Comment


                  • #10
                    Carl plans to handle everything in code anyway.
                    And in this case, I also agree with that.
                    The selected MCU will certainly have a DAC and then only the "power amp" stage is left outside the MCU.
                    And it can be solved in a "minimalist" way with only one mosfet.
                    Ok, that's been the principle story so far. What about the essence of the solution?
                    How to solve it, either in code or out of code?
                    I briefly mentioned it and did not elaborate.
                    Two or more "channels" for audio. Independent.
                    When I say "channel"; I don't mean classic audio channels, but groups of data, grouped by certain characteristics.
                    And then as a group assigned with a certain audio behavior.
                    What do we need to hear in the speaker?
                    Definitely "soil" sound. Separated, not mixed with other sounds. That would be one "channel".
                    When the GEB is done; that sound is reduced to a barely audible and further, by user adjustable threshold.
                    Who has ever worked with ML Explorer; knows what I'm talking about.
                    The Explorer has perhaps the best threshold I've seen on detectors so far.
                    There is only one problem; there is no "other side" ie no "iron".
                    It goes completely silent when a small piece of iron is encountered.
                    In this case, it is desirable to hear the iron as well, so it is the second "channel".
                    And as at Deus; user to be able to increase or decrease the sound of the iron. By personal affinities.
                    And the third "channel" would be all other metals, this time divided into 2 or 3 subgroups and each subgroup assigned with a separate audio pitch range.
                    Except for the soil "channel", all others should be in direct correlation with the behavior of VDI.
                    This concept is a almost copied concept from Deus.
                    But we cannot reinvent the wheel.
                    What is done well and can hardly be better; should not be avoided.
                    It is very important that the soil "channel" and the "iron" channel" have special SEPARATE controls for muting to zero and amplifying to approximately 80% of the third "channel",
                    i.e. the channel of all other metals.
                    It is also very important to note that these "channels" should not be mixed at any cost!
                    But they go separately into the audio amp.
                    Well, that would be roughly the "descriptive" algorithm for audio.
                    You will notice that it is equally the same and equally good not only for the PI but also for the VLF I/B detector.
                    How to do all this?
                    Well... once a good direct sampling is solved and once a good method of storing samples in temporary/working memory is written;
                    using a various digital filters & math; will easily lead to exactly this situation.
                    Now it's up to the programmer to translate all that into code.


                    Comment


                    • #11
                      Originally posted by ivconic View Post
                      Carl plans to handle everything in code anyway.
                      And in this case, I also agree with that.
                      The selected MCU will certainly have a DAC and then only the "power amp" stage is left outside the MCU.
                      And it can be solved in a "minimalist" way with only one mosfet.
                      Ok, that's been the principle story so far. What about the essence of the solution?
                      How to solve it, either in code or out of code?
                      I briefly mentioned it and did not elaborate.
                      Two or more "channels" for audio. Independent.
                      When I say "channel"; I don't mean classic audio channels, but groups of data, grouped by certain characteristics.
                      And then as a group assigned with a certain audio behavior.
                      What do we need to hear in the speaker?
                      Definitely "soil" sound. Separated, not mixed with other sounds. That would be one "channel".
                      When the GEB is done; that sound is reduced to a barely audible and further, by user adjustable threshold.
                      Who has ever worked with ML Explorer; knows what I'm talking about.
                      The Explorer has perhaps the best threshold I've seen on detectors so far.
                      There is only one problem; there is no "other side" ie no "iron".
                      It goes completely silent when a small piece of iron is encountered.
                      In this case, it is desirable to hear the iron as well, so it is the second "channel".
                      And as at Deus; user to be able to increase or decrease the sound of the iron. By personal affinities.
                      And the third "channel" would be all other metals, this time divided into 2 or 3 subgroups and each subgroup assigned with a separate audio pitch range.
                      Except for the soil "channel", all others should be in direct correlation with the behavior of VDI.
                      This concept is a almost copied concept from Deus.
                      But we cannot reinvent the wheel.
                      What is done well and can hardly be better; should not be avoided.
                      It is very important that the soil "channel" and the "iron" channel" have special SEPARATE controls for muting to zero and amplifying to approximately 80% of the third "channel",
                      i.e. the channel of all other metals.
                      It is also very important to note that these "channels" should not be mixed at any cost!
                      But they go separately into the audio amp.
                      Well, that would be roughly the "descriptive" algorithm for audio.
                      You will notice that it is equally the same and equally good not only for the PI but also for the VLF I/B detector.
                      How to do all this?
                      Well... once a good direct sampling is solved and once a good method of storing samples in temporary/working memory is written;
                      using a various digital filters & math; will easily lead to exactly this situation.
                      Now it's up to the programmer to translate all that into code.


                      There are a few things that need to be sorted out:
                      What kind of speaker?
                      How many db at 1 meter distance?
                      What frequency? 400Hz? variable 300 to 500Hz? or what?
                      How do we make the audio output rainproof and dustproof? The AMX is designed to work under very harsh conditions: streaming rain, mud, 40 C degrees heat, blowing dust. The speaker is the most vulnerable part.

                      Could you post a few audio files from the "Deus" and other detectors that you consider having a good audio?
                      So that we all can understand the difference between a good audio and a bad one?

                      Comment


                      • #12
                        Originally posted by Tinkerer View Post

                        There are a few things that need to be sorted out:
                        What kind of speaker?
                        How many db at 1 meter distance?
                        What frequency? 400Hz? variable 300 to 500Hz? or what?
                        How do we make the audio output rainproof and dustproof? The AMX is designed to work under very harsh conditions: streaming rain, mud, 40 C degrees heat, blowing dust. The speaker is the most vulnerable part.

                        Could you post a few audio files from the "Deus" and other detectors that you consider having a good audio?
                        So that we all can understand the difference between a good audio and a bad one?

                        Comment


                        • #13
                          ....maybe the audio needs its own thread. This is TX. If you are looking for gold the audio scheme is very simple

                          Comment


                          • #14
                            Thank you for the interesting Youtube. Now I understand what you mean with the "tones".

                            Comment


                            • #15
                              Originally posted by moodz View Post
                              ....maybe the audio needs its own thread. This is TX. If you are looking for gold the audio scheme is very simple
                              Right, the audio needs its own thread.

                              How do you see the gold audio scheme? What would your preference be?

                              Comment

                              Working...
                              X