Loading ...
Sorry, an error occurred while loading the content.

Programming Question: Audio from delta 44

Expand Messages
  • Albert Gerheim
    I hate to impose, but you may be the only source of enlightenment, and I ve been beating myself senseless for a month on this now. I need to look at the code
    Message 1 of 9 , Jul 18 10:44 AM
    • 0 Attachment
      I hate to impose, but you may be the only source of enlightenment, and I've been beating myself senseless for a month on this now.  

      I need to look at the code PowerSDR uses to read the audio data line from the Softrock40 (or other fine SDR).  

      Here's my problem:

      I'm writing a Java SDR program (I know:  only 16 bits per sample), and when I read the audio from the Delta 44, I get 2 or 3 bits of non-zero data per sample, and 13-14 zeros.  The quantization noise washes out everything but my own test signals, which are extremely loud.  When I copy the same line (1/2) on Audacity, or Mathematica, I get, essentially, the same result.  

      Apparently, PowerSDR is getting more 1's ( :-)  ) per sample.  (because it "works" :-)   )  How?  

      I've tried 2 different drivers for the Delta 44. I'm unable to control the input level from the M-Audio software.  

      Please help!  


      --
      Al Gerheim
      Adopt a Homeless Pet
      http://www.petfinder.com
    • Roger Critchlow
      Speaking from no recent experience with Java sound and no experience at all with Delta 44 s, I d look at the endian-ness specification of the samples, and
      Message 2 of 9 , Jul 18 11:49 AM
      • 0 Attachment
        Speaking from no recent experience with Java sound and no experience at all with Delta 44's, I'd look at the endian-ness specification of the samples, and whether a 24 bit sample is being passed in a 32 bit word.  If you're getting 24 or 32 bit samples in the wrong byte order and chopping the wrong bytes to make a 16 bit sample, then you could end up with a lot of zeroes.  

        The bytes in the incoming sample could be ordered 4321, 1234, 2143, or 3412 without being unusual.  But the order is usually converted to the native byte order by the driver.

        And if there's a 24 bit sample in a 32 bit word, then left and right alignment of the 24 bits inside the 32 bits are also possibilities.  There may be a way to tell the driver to fix this, too.  The driver should know what the hardware is delivering and should be able to deliver any reasonable sample format.

        So, supposing you have a 24 bit unsigned sample right aligned inside a 32 bit word, and the byte order is correct, then you would want the middle 16 bits as your sample value.  If you just take the high 16 bits, you'd get a byte of zeroes and the most significant byte of the 24 bit sample, which is what it sounds like you're getting.

        Though Java was originally intended for set top boxes, its audio and multimedia capabilities have always been an underfunded afterthought that never lived up to the promises.  So I wouldn't be too surprised if I went digging for days in the documentation and source code only to discover a comment in place of the required code.  Then again, some audio obsessed volunteer might have finished the work.
         
        -- rec --

        On Wed, Jul 18, 2012 at 11:44 AM, Albert Gerheim <alpg49@...> wrote:
         

        I hate to impose, but you may be the only source of enlightenment, and I've been beating myself senseless for a month on this now.  

        I need to look at the code PowerSDR uses to read the audio data line from the Softrock40 (or other fine SDR).  

        Here's my problem:

        I'm writing a Java SDR program (I know:  only 16 bits per sample), and when I read the audio from the Delta 44, I get 2 or 3 bits of non-zero data per sample, and 13-14 zeros.  The quantization noise washes out everything but my own test signals, which are extremely loud.  When I copy the same line (1/2) on Audacity, or Mathematica, I get, essentially, the same result.  

        Apparently, PowerSDR is getting more 1's ( :-)  ) per sample.  (because it "works" :-)   )  How?  

        I've tried 2 different drivers for the Delta 44. I'm unable to control the input level from the M-Audio software.  

        Please help!  


        --
        Al Gerheim
        Adopt a Homeless Pet
        http://www.petfinder.com


      • Albert Gerheim
        Thanks for getting back. The alignment of the 16 bits is OK. I can capture and release audio from a walkman and it sounds OK (sort of - with all the
        Message 3 of 9 , Jul 18 12:39 PM
        • 0 Attachment
          Thanks for getting back.  The alignment of the 16 bits is OK.  I can "capture and release" audio from a walkman and it sounds OK (sort of - with all the processing, it's like SSB gone wild).  


          On Wed, Jul 18, 2012 at 2:49 PM, Roger Critchlow <rec@...> wrote:
           

          Speaking from no recent experience with Java sound and no experience at all with Delta 44's, I'd look at the endian-ness specification of the samples, and whether a 24 bit sample is being passed in a 32 bit word.  If you're getting 24 or 32 bit samples in the wrong byte order and chopping the wrong bytes to make a 16 bit sample, then you could end up with a lot of zeroes.  


          The bytes in the incoming sample could be ordered 4321, 1234, 2143, or 3412 without being unusual.  But the order is usually converted to the native byte order by the driver.

          And if there's a 24 bit sample in a 32 bit word, then left and right alignment of the 24 bits inside the 32 bits are also possibilities.  There may be a way to tell the driver to fix this, too.  The driver should know what the hardware is delivering and should be able to deliver any reasonable sample format.

          So, supposing you have a 24 bit unsigned sample right aligned inside a 32 bit word, and the byte order is correct, then you would want the middle 16 bits as your sample value.  If you just take the high 16 bits, you'd get a byte of zeroes and the most significant byte of the 24 bit sample, which is what it sounds like you're getting.

          Though Java was originally intended for set top boxes, its audio and multimedia capabilities have always been an underfunded afterthought that never lived up to the promises.  So I wouldn't be too surprised if I went digging for days in the documentation and source code only to discover a comment in place of the required code.  Then again, some audio obsessed volunteer might have finished the work.
           
          -- rec --

          On Wed, Jul 18, 2012 at 11:44 AM, Albert Gerheim <alpg49@...> wrote:
           

          I hate to impose, but you may be the only source of enlightenment, and I've been beating myself senseless for a month on this now.  

          I need to look at the code PowerSDR uses to read the audio data line from the Softrock40 (or other fine SDR).  

          Here's my problem:

          I'm writing a Java SDR program (I know:  only 16 bits per sample), and when I read the audio from the Delta 44, I get 2 or 3 bits of non-zero data per sample, and 13-14 zeros.  The quantization noise washes out everything but my own test signals, which are extremely loud.  When I copy the same line (1/2) on Audacity, or Mathematica, I get, essentially, the same result.  

          Apparently, PowerSDR is getting more 1's ( :-)  ) per sample.  (because it "works" :-)   )  How?  

          I've tried 2 different drivers for the Delta 44. I'm unable to control the input level from the M-Audio software.  

          Please help!  


          --
          Al Gerheim
          Adopt a Homeless Pet
          http://www.petfinder.com





          --
          Al Gerheim
          Adopt a Homeless Pet
          http://www.petfinder.com
        • Roger Critchlow
          Well, maybe you re seeing the true levels then. An audio source is usually mastered to be audible. But the signals from the softrock are -73dBm at S9 and
          Message 4 of 9 , Jul 18 1:29 PM
          • 0 Attachment
            Well, maybe you're seeing the true levels then.  

            An audio source is usually mastered to be audible.  But the signals from the softrock are -73dBm at S9 and -121dBm at S1, so at 3dB per bit -- and assuming that the sound card most significant bit was 0dBm, but it isn't -- an S9 signal would be 24 bits down, an S1 signal would be 40 bits down.  The softrock output op-amps provide gain tailored to a 16 bit sound card, so things get shifted around, and the sensitivities of audio cards vary, too.  And I probably screwed up the power to linear decibel transition, too, again.  The bits in the ADC are measuring voltages, and the dBm levels are measuring power, so the dBm values are ratios of squared voltages, where the ADC bits are responding to ratios of voltages.

            But you will usually need audio gain in the SDR chain, either manually applied or from an AGC component, to hear signals from a softrock that aren't blasting in.  The simplest SDR software is just an audio gain block connecting audio in from the softrock to audio out to speakers or headphones, but be careful how you abuse your ears.  AGC won't work until you restrict the AGC input to the audio bandwidth you're trying to hear.

            -- rec --

            On Wed, Jul 18, 2012 at 1:39 PM, Albert Gerheim <alpg49@...> wrote:
             

            Thanks for getting back.  The alignment of the 16 bits is OK.  I can "capture and release" audio from a walkman and it sounds OK (sort of - with all the processing, it's like SSB gone wild).  



            On Wed, Jul 18, 2012 at 2:49 PM, Roger Critchlow <rec@...> wrote:
             

            Speaking from no recent experience with Java sound and no experience at all with Delta 44's, I'd look at the endian-ness specification of the samples, and whether a 24 bit sample is being passed in a 32 bit word.  If you're getting 24 or 32 bit samples in the wrong byte order and chopping the wrong bytes to make a 16 bit sample, then you could end up with a lot of zeroes.  


            The bytes in the incoming sample could be ordered 4321, 1234, 2143, or 3412 without being unusual.  But the order is usually converted to the native byte order by the driver.

            And if there's a 24 bit sample in a 32 bit word, then left and right alignment of the 24 bits inside the 32 bits are also possibilities.  There may be a way to tell the driver to fix this, too.  The driver should know what the hardware is delivering and should be able to deliver any reasonable sample format.

            So, supposing you have a 24 bit unsigned sample right aligned inside a 32 bit word, and the byte order is correct, then you would want the middle 16 bits as your sample value.  If you just take the high 16 bits, you'd get a byte of zeroes and the most significant byte of the 24 bit sample, which is what it sounds like you're getting.

            Though Java was originally intended for set top boxes, its audio and multimedia capabilities have always been an underfunded afterthought that never lived up to the promises.  So I wouldn't be too surprised if I went digging for days in the documentation and source code only to discover a comment in place of the required code.  Then again, some audio obsessed volunteer might have finished the work.
             
            -- rec --

            On Wed, Jul 18, 2012 at 11:44 AM, Albert Gerheim <alpg49@...> wrote:
             

            I hate to impose, but you may be the only source of enlightenment, and I've been beating myself senseless for a month on this now.  

            I need to look at the code PowerSDR uses to read the audio data line from the Softrock40 (or other fine SDR).  

            Here's my problem:

            I'm writing a Java SDR program (I know:  only 16 bits per sample), and when I read the audio from the Delta 44, I get 2 or 3 bits of non-zero data per sample, and 13-14 zeros.  The quantization noise washes out everything but my own test signals, which are extremely loud.  When I copy the same line (1/2) on Audacity, or Mathematica, I get, essentially, the same result.  

            Apparently, PowerSDR is getting more 1's ( :-)  ) per sample.  (because it "works" :-)   )  How?  

            I've tried 2 different drivers for the Delta 44. I'm unable to control the input level from the M-Audio software.  

            Please help!  


            --
            Al Gerheim
            Adopt a Homeless Pet
            http://www.petfinder.com





            --
            Al Gerheim
            Adopt a Homeless Pet
            http://www.petfinder.com


          • Albert Gerheim
            I agree that audio gain would fix the problem, but then, how does PowerSDR get a good signal?! Also, adding more power at the software end (multiplying by a
            Message 5 of 9 , Jul 18 1:41 PM
            • 0 Attachment
              I agree that audio gain would fix the problem, but then, how does PowerSDR get a good signal?!  

              Also, adding more power at the software end (multiplying by a bigger number) only increases the quantization noise.  



              On Wed, Jul 18, 2012 at 4:29 PM, Roger Critchlow <rec@...> wrote:
               

              Well, maybe you're seeing the true levels then.  


              An audio source is usually mastered to be audible.  But the signals from the softrock are -73dBm at S9 and -121dBm at S1, so at 3dB per bit -- and assuming that the sound card most significant bit was 0dBm, but it isn't -- an S9 signal would be 24 bits down, an S1 signal would be 40 bits down.  The softrock output op-amps provide gain tailored to a 16 bit sound card, so things get shifted around, and the sensitivities of audio cards vary, too.  And I probably screwed up the power to linear decibel transition, too, again.  The bits in the ADC are measuring voltages, and the dBm levels are measuring power, so the dBm values are ratios of squared voltages, where the ADC bits are responding to ratios of voltages.

              But you will usually need audio gain in the SDR chain, either manually applied or from an AGC component, to hear signals from a softrock that aren't blasting in.  The simplest SDR software is just an audio gain block connecting audio in from the softrock to audio out to speakers or headphones, but be careful how you abuse your ears.  AGC won't work until you restrict the AGC input to the audio bandwidth you're trying to hear.

              -- rec --


              On Wed, Jul 18, 2012 at 1:39 PM, Albert Gerheim <alpg49@...> wrote:
               

              Thanks for getting back.  The alignment of the 16 bits is OK.  I can "capture and release" audio from a walkman and it sounds OK (sort of - with all the processing, it's like SSB gone wild).  



              On Wed, Jul 18, 2012 at 2:49 PM, Roger Critchlow <rec@...> wrote:
               

              Speaking from no recent experience with Java sound and no experience at all with Delta 44's, I'd look at the endian-ness specification of the samples, and whether a 24 bit sample is being passed in a 32 bit word.  If you're getting 24 or 32 bit samples in the wrong byte order and chopping the wrong bytes to make a 16 bit sample, then you could end up with a lot of zeroes.  


              The bytes in the incoming sample could be ordered 4321, 1234, 2143, or 3412 without being unusual.  But the order is usually converted to the native byte order by the driver.

              And if there's a 24 bit sample in a 32 bit word, then left and right alignment of the 24 bits inside the 32 bits are also possibilities.  There may be a way to tell the driver to fix this, too.  The driver should know what the hardware is delivering and should be able to deliver any reasonable sample format.

              So, supposing you have a 24 bit unsigned sample right aligned inside a 32 bit word, and the byte order is correct, then you would want the middle 16 bits as your sample value.  If you just take the high 16 bits, you'd get a byte of zeroes and the most significant byte of the 24 bit sample, which is what it sounds like you're getting.

              Though Java was originally intended for set top boxes, its audio and multimedia capabilities have always been an underfunded afterthought that never lived up to the promises.  So I wouldn't be too surprised if I went digging for days in the documentation and source code only to discover a comment in place of the required code.  Then again, some audio obsessed volunteer might have finished the work.
               
              -- rec --

              On Wed, Jul 18, 2012 at 11:44 AM, Albert Gerheim <alpg49@...> wrote:
               

              I hate to impose, but you may be the only source of enlightenment, and I've been beating myself senseless for a month on this now.  

              I need to look at the code PowerSDR uses to read the audio data line from the Softrock40 (or other fine SDR).  

              Here's my problem:

              I'm writing a Java SDR program (I know:  only 16 bits per sample), and when I read the audio from the Delta 44, I get 2 or 3 bits of non-zero data per sample, and 13-14 zeros.  The quantization noise washes out everything but my own test signals, which are extremely loud.  When I copy the same line (1/2) on Audacity, or Mathematica, I get, essentially, the same result.  

              Apparently, PowerSDR is getting more 1's ( :-)  ) per sample.  (because it "works" :-)   )  How?  

              I've tried 2 different drivers for the Delta 44. I'm unable to control the input level from the M-Audio software.  

              Please help!  


              --
              Al Gerheim
              Adopt a Homeless Pet
              http://www.petfinder.com





              --
              Al Gerheim
              Adopt a Homeless Pet
              http://www.petfinder.com





              --
              Al Gerheim
              Adopt a Homeless Pet
              http://www.petfinder.com
            • Roger Critchlow
              ... I don t know. How are you gauging the signal quality that PowerSDR gets? It started as the same code as DTTSP, so it s using a 32 bit float for all its
              Message 6 of 9 , Jul 18 2:49 PM
              • 0 Attachment
                On Wed, Jul 18, 2012 at 2:41 PM, Albert Gerheim <alpg49@...> wrote:
                 

                I agree that audio gain would fix the problem, but then, how does PowerSDR get a good signal?!  

                I don't know.  How are you gauging the signal quality that PowerSDR gets?  It started as the same code as DTTSP, so it's using a 32 bit float for all its internal sample processing.  If you convert a fixed point sample into a floating point sample by dividing by a power of two, then you get a floating point number with the same bit pattern as the numerator and the denominator ends up in the exponent.  So if you could see the raw samples in PowerSDR, and they were converted as a fraction of a power of two, then you could see how many bits were in the original fixed point sample.  But any subsequent processing will tend to overwhelmingly produce floating point samples with the full 24 bits of precision.  So, if the samples were converted by dividing by (2^n - 1) instead of 2^n, or they were multiplied by an RF gain, or they were corrected for IQ balance, or they mixed in a local oscillator, or anything else, you'll see the number of bits in the subsequent processing mixed with the original number of bits.  So how are you measuring the quality of PowerSDR's signal?

                Also, adding more power at the software end (multiplying by a bigger number) only increases the quantization noise.  

                You work with the samples you get, you can't make them better but you can make them tell what they know.

                -- rec --



              • Albert Gerheim
                I m not sure I follow. The processing isn t the problem. The problem is 1) I m getting 16 bit data (2 bytes) from the card. This is the actual format the
                Message 7 of 9 , Jul 19 5:11 AM
                • 0 Attachment
                  I'm not sure I follow.  The processing isn't the problem.  The problem is

                  1) I'm getting 16 bit data (2 bytes) from the card.  This is the actual format the card delivers to the software.  
                  2) It is being converted to integer (or float) properly.  I determined this by putting analog sine waves to the input, and observing analog sine waves (clean) at the output.  
                  3) The only states I see are -3, -2, -1, 0, 1, 2, and 3.  (except for extremely strong test signals)  
                  4) Therefore, quantization noise dominates the signals unless they're extremely large (my own rig, or test signals).  These signals are being processed properly by the signal processing chain.  

                  5) When I record data using Mathematica or Audacity, I see the same thing:  extremely low signal level with quantization noise dominating.  

                  6) "original floating point"   By the time the signals get to this stage, quantization noise is pretty much all I see.  



                  I'm very close to giving up.  The next step will be to attempt the same thing in C/C++ and see if there's a different outcome.  

                  If I could look at a few lines of PowerSDR code, it would be a big help.  



                  On Wed, Jul 18, 2012 at 5:49 PM, Roger Critchlow <rec@...> wrote:
                   



                  On Wed, Jul 18, 2012 at 2:41 PM, Albert Gerheim <alpg49@...> wrote:
                   

                  I agree that audio gain would fix the problem, but then, how does PowerSDR get a good signal?!  

                  I don't know.  How are you gauging the signal quality that PowerSDR gets?

                  It works well enough to work QSO's.  
                   
                   It started as the same code as DTTSP, so it's using a 32 bit float for all its internal sample processing.  If you convert a fixed point sample into a floating point sample by dividing by a power of two, then you get a floating point number with the same bit pattern as the numerator and the denominator ends up in the exponent.  So if you could see the raw samples in PowerSDR, and they were converted as a fraction of a power of two, then you could see how many bits were in the original fixed point sample.  But any subsequent processing will tend to overwhelmingly produce floating point samples with the full 24 bits of precision.  So, if the samples were converted by dividing by (2^n - 1) instead of 2^n, or they were multiplied by an RF gain, or they were corrected for IQ balance, or they mixed in a local oscillator, or anything else, you'll see the number of bits in the subsequent processing mixed with the original number of bits.  So how are you measuring the quality of PowerSDR's signal?

                  Also, adding more power at the software end (multiplying by a bigger number) only increases the quantization noise.  

                  You work with the samples you get, you can't make them better but you can make them tell what they know.

                  -- rec --






                  --
                  Al Gerheim
                  Adopt a Homeless Pet
                  http://www.petfinder.com
                • John Williams
                  Al, Why not take a look at the audio handling on SDRSharp? It is written in C# which is similar to Java, runs on Windows also. May be helpful, may not. It is
                  Message 8 of 9 , Jul 19 5:32 AM
                  • 0 Attachment
                    Al,

                    Why not take a look at the audio handling on SDRSharp? It is written in
                    C# which is similar to Java, runs on Windows also. May be helpful, may
                    not. It is avail here. Or perhaps take this code, and add your digital
                    backend to it?

                    https://www.assembla.com/code/sdrsharp/subversion/nodes

                    John

                    On 7/19/2012 7:11 AM, Albert Gerheim wrote:
                    > If I could look at a few lines of PowerSDR code, it would be a big help.

                    --

                    John Williams

                    KE5SSH - ham since 2007
                    WQKA523 - GMRS for family use on the farm
                  • Albert Gerheim
                    good idea. thanks! ... -- Al Gerheim Adopt a Homeless Pet http://www.petfinder.com
                    Message 9 of 9 , Jul 19 5:49 AM
                    • 0 Attachment
                      good idea.  thanks!  

                      On Thu, Jul 19, 2012 at 8:32 AM, John Williams <KE5SSH@...> wrote:
                      Al,

                      Why not take a look at the audio handling on SDRSharp? It is written in
                      C# which is similar to Java, runs on Windows also. May be helpful, may
                      not. It is avail here. Or perhaps take this code, and add your digital
                      backend to it?

                      https://www.assembla.com/code/sdrsharp/subversion/nodes

                      John

                      On 7/19/2012 7:11 AM, Albert Gerheim wrote:
                      > If I could look at a few lines of PowerSDR code, it would be a big help.

                      --

                      John Williams

                      KE5SSH - ham since 2007
                      WQKA523 - GMRS for family use on the farm





                      ------------------------------------

                      Yahoo! Groups Links

                      <*> To visit your group on the web, go to:
                          http://groups.yahoo.com/group/softrock40/

                      <*> Your email settings:
                          Individual Email | Traditional

                      <*> To change settings online go to:
                          http://groups.yahoo.com/group/softrock40/join
                          (Yahoo! ID required)

                      <*> To change settings via email:
                          softrock40-digest@yahoogroups.com
                          softrock40-fullfeatured@yahoogroups.com

                      <*> To unsubscribe from this group, send an email to:
                          softrock40-unsubscribe@yahoogroups.com

                      <*> Your use of Yahoo! Groups is subject to:
                          http://docs.yahoo.com/info/terms/




                      --
                      Al Gerheim
                      Adopt a Homeless Pet
                      http://www.petfinder.com
                    Your message has been successfully submitted and would be delivered to recipients shortly.