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

Re: [SpectrumLab] Using SpecLab with an NI DAQ card (e.g. PCI-4462)

Expand Messages
  • wolf_dl4yhf
    Hi there, If there was an ASIO driver for the NI card, it would definitely help because you wouldn t need anything else. AFAIK, Asio4All only emulates a
    Message 1 of 5 , Feb 6 1:06 PM
    • 0 Attachment
      Hi there,

      If there was an ASIO driver for the NI card, it would definitely help
      because you wouldn't need anything else. AFAIK, Asio4All only emulates
      a "real" ASIO driver, using a standard multimedia driver. So to use
      asio4all with the NI DAQ card, you would need a driver *from them* to
      support your card. And if that was a standard multimedia driver,
      Spectrum Lab could also use that.

      BTW There's a bug in the Audio-via-UDP part in Spectrum Lab. It only
      works properly if the processing loop is "slowed down" by sending the
      audio to the soundcard (which causes the processing thread to wait),
      even if you only want to analyse the input stream with the spectrum
      analyser. Otherwise, the processing task detects a timeout while waiting
      for the next UDP reception.
      This may be another chance to support "any" exotic input hardware, if
      you can write a little program which can 'packetize' (does this word
      exist in english..?) the uncompressed sample stream into UDP packets.
      Each UDP packet should ideally have a header which describes the block,
      sample rate, timestamp, etc. I will publish more details as soon as I
      have uploaded a new beta version with the bug fixed.


      All the best,
      Wolf .

      Am 06.02.2011 02:54, schrieb popdeye88:
      > Looking for ideas/ guidance/ experience here.
      >
      > Anybody ever try to use SpecLab with an NI DAQ card (e.g. PCI-4462, see http://sine.ni.com/nips/cds/view/p/lang/en/nid/202237 )? Might ASIO (e.g. http://www.asio4all.com/ ) be of any use perhaps?
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
    • ehydra
      Hello all! Interesting! So I can build myself a ADC card with just an ADC, Microcontroller and Wizlink-EthernetChip or something. Wolf, mentioned that there is
      Message 2 of 5 , Feb 7 3:49 PM
      • 0 Attachment
        Hello all!

        Interesting! So I can build myself a ADC card with just an ADC,
        Microcontroller and Wizlink-EthernetChip or something.

        Wolf, mentioned that there is a special UDP packet structure. Hm. Is it
        not the standard streaming way, like in VLC mediaplayer or any other
        stream client?

        I would strongly suggest to use a standard packet structure.

        Maybe I build a ADC card in the near future.


        - Henry


        wolf_dl4yhf schrieb:
        > Hi there,
        >
        > If there was an ASIO driver for the NI card, it would definitely help
        > because you wouldn't need anything else. AFAIK, Asio4All only emulates
        > a "real" ASIO driver, using a standard multimedia driver. So to use
        > asio4all with the NI DAQ card, you would need a driver *from them* to
        > support your card. And if that was a standard multimedia driver,
        > Spectrum Lab could also use that.
        >
        > BTW There's a bug in the Audio-via-UDP part in Spectrum Lab. It only
        > works properly if the processing loop is "slowed down" by sending the
        > audio to the soundcard (which causes the processing thread to wait),
        > even if you only want to analyse the input stream with the spectrum
        > analyser. Otherwise, the processing task detects a timeout while waiting
        > for the next UDP reception.
        > This may be another chance to support "any" exotic input hardware, if
        > you can write a little program which can 'packetize' (does this word
        > exist in english..?) the uncompressed sample stream into UDP packets.
        > Each UDP packet should ideally have a header which describes the block,
        > sample rate, timestamp, etc. I will publish more details as soon as I
        > have uploaded a new beta version with the bug fixed.
        >
        >
        > All the best,
        > Wolf .
        >
        > Am 06.02.2011 02:54, schrieb popdeye88:
        >> Looking for ideas/ guidance/ experience here.
        >>
        >> Anybody ever try to use SpecLab with an NI DAQ card (e.g. PCI-4462, see http://sine.ni.com/nips/cds/view/p/lang/en/nid/202237 )? Might ASIO (e.g. http://www.asio4all.com/ ) be of any use perhaps?
      • Magnus
        ... How about RTP? https://secure.wikimedia.org/wikipedia/en/wiki/Real-time_Transport_Protocol It could be used in combination with open source Speex voice
        Message 3 of 5 , Feb 7 5:05 PM
        • 0 Attachment
          On 2011-02-08 00:49, ehydra wrote:
          > I would strongly suggest to use a standard packet structure.

          How about RTP?

          https://secure.wikimedia.org/wikipedia/en/wiki/Real-time_Transport_Protocol

          It could be used in combination with open source Speex voice codec
          which, by the way, I also guess could be used to replace the proprietary
          AMBE voice codec in the Icom D-Star system.

          http://speex.org/

          73's

          /SM6XMA, Magnus
        • wolf_dl4yhf
          Hello Henry, Just wading through 120 emails (spam already removed) after a 3 day business trip, so sorry for the delay, and not responding to others. ... Yes,
          Message 4 of 5 , Feb 10 9:46 AM
          • 0 Attachment
            Hello Henry,

            Just wading through 120 emails (spam already removed) after a 3 day business trip, so sorry for the delay, and not responding to others.

            You wrote:



            Wolf, mentioned that there is a special UDP packet structure. Hm. Is it
            not the standard streaming way, like in VLC mediaplayer or any other
            stream client?


            Yes, it's proprietary, but simple to implement. Standard protocols do not satisfy the needs for some planned experiments: Very high-res timestamps (for radio direction finding using time-of-arrival principles), very precise momentary sampling rate embedded in the stream, current GPS date, time, and location also embedded in the stream, etc etc.
            Banging all this info into a simple "C" struct is much easier than wading through a monster protocol overhead (as used over the internet). Unfortunately there is no such thing as a standard stream format: They use dozens of different codecs. And most of them are way too complicated, use compression (which is totally unsuitable for most of my weak-signal applications), or there are other reasons why to avoid them). For example, there are streams with only play in VLC. There are other streams which don't play in VLC but in some other player only (don't ask me which..... winamp, windoze media player, etc). All of them use compression which is a very bad idea if you "only" want to connect some kind of ADC / data acquisition unit / other signal source to a signal sink.

            Better keep it simple and stupid. A firmware for microcontroller to copy audio samples into UDP frames, fill out a few bytes in the header (or, in the most simple form, use a header with constant contents) is relatively easy.

            Implementing something like RTSP, RTP, etc is low on my priority list.

            All the best,
              Wolf .

            I would strongly suggest to use a standard packet structure.

            Maybe I build a ADC card in the near future.

            - Henry

            wolf_dl4yhf schrieb:
            > Hi there,
            >
            > If there was an ASIO driver for the NI card, it would definitely help
            > because you wouldn't need anything else. AFAIK, Asio4All only emulates
            > a "real" ASIO driver, using a standard multimedia driver. So to use
            > asio4all with the NI DAQ card, you would need a driver *from them* to
            > support your card. And if that was a standard multimedia driver,
            > Spectrum Lab could also use that.
            >
            > BTW There's a bug in the Audio-via-UDP part in Spectrum Lab. It only
            > works properly if the processing loop is "slowed down" by sending the
            > audio to the soundcard (which causes the processing thread to wait),
            > even if you only want to analyse the input stream with the spectrum
            > analyser. Otherwise, the processing task detects a timeout while waiting
            > for the next UDP reception.
            > This may be another chance to support "any" exotic input hardware, if
            > you can write a little program which can 'packetize' (does this word
            > exist in english..?) the uncompressed sample stream into UDP packets.
            > Each UDP packet should ideally have a header which describes the block,
            > sample rate, timestamp, etc. I will publish more details as soon as I
            > have uploaded a new beta version with the bug fixed.
            >
            >
            > All the best,
            > Wolf .
            >
            > Am 06.02.2011 02:54, schrieb popdeye88:
            >> Looking for ideas/ guidance/ experience here.
            >>
            >> Anybody ever try to use SpecLab with an NI DAQ card (e.g. PCI-4462, see http://sine.ni.com/nips/cds/view/p/lang/en/nid/202237 )? Might ASIO (e.g. http://www.asio4all.com/ ) be of any use perhaps?


          • ehydra
            Hi Wolf - Yes, I understand. Is uncompressed wav-format not all you need? Maybe a slight added header for specials like GPS hard-time. I think I will go the
            Message 5 of 5 , Feb 10 8:52 PM
            • 0 Attachment
              Hi Wolf -

              Yes, I understand. Is uncompressed wav-format not all you need? Maybe a
              slight added header for specials like GPS hard-time.

              I think I will go the way mentioned with a microcontroller. Hopefully
              I'm still interested in a couple of months ;-)

              regards -
              Henry


              wolf_dl4yhf schrieb:
              > Hello Henry,
              >
              > Just wading through 120 emails (spam already removed) after a 3 day
              > business trip, so sorry for the delay, and not responding to others.
              >
              > You wrote:
              >
              >
              >
              >> Wolf, mentioned that there is a special UDP packet structure. Hm. Is it
              >> not the standard streaming way, like in VLC mediaplayer or any other
              >> stream client?
              >>
              >
              > Yes, it's proprietary, but simple to implement. Standard protocols do
              > not satisfy the needs for some planned experiments: Very high-res
              > timestamps (for radio direction finding using time-of-arrival
              > principles), very precise momentary sampling rate embedded in the
              > stream, current GPS date, time, and location also embedded in the
              > stream, etc etc.
              > Banging all this info into a simple "C" struct is much easier than
              > wading through a monster protocol overhead (as used over the internet).
              > Unfortunately there is no such thing as a standard stream format: They
              > use dozens of different codecs. And most of them are way too
              > complicated, use compression (which is totally unsuitable for most of my
              > weak-signal applications), or there are other reasons why to avoid
              > them). For example, there are streams with only play in VLC. There are
              > other streams which don't play in VLC but in some other player only
              > (don't ask me which..... winamp, windoze media player, etc). All of them
              > use compression which is a very bad idea if you "only" want to connect
              > some kind of ADC / data acquisition unit / other signal source to a
              > signal sink.
              >
              > Better keep it simple and stupid. A firmware for microcontroller to copy
              > audio samples into UDP frames, fill out a few bytes in the header (or,
              > in the most simple form, use a header with constant contents) is
              > relatively easy.
              >
              > Implementing something like RTSP, RTP, etc is low on my priority list.
              >
              > All the best,
              > Wolf .
              >>
              >> I would strongly suggest to use a standard packet structure.
              >>
              >> Maybe I build a ADC card in the near future.
              >>
              >> - Henry
              >>
              >> wolf_dl4yhf schrieb:
              >> > Hi there,
              >> >
              >> > If there was an ASIO driver for the NI card, it would definitely help
              >> > because you wouldn't need anything else. AFAIK, Asio4All only emulates
              >> > a "real" ASIO driver, using a standard multimedia driver. So to use
              >> > asio4all with the NI DAQ card, you would need a driver *from them* to
              >> > support your card. And if that was a standard multimedia driver,
              >> > Spectrum Lab could also use that.
              >> >
              >> > BTW There's a bug in the Audio-via-UDP part in Spectrum Lab. It only
              >> > works properly if the processing loop is "slowed down" by sending the
              >> > audio to the soundcard (which causes the processing thread to wait),
              >> > even if you only want to analyse the input stream with the spectrum
              >> > analyser. Otherwise, the processing task detects a timeout while
              >> waiting
              >> > for the next UDP reception.
              >> > This may be another chance to support "any" exotic input hardware, if
              >> > you can write a little program which can 'packetize' (does this word
              >> > exist in english..?) the uncompressed sample stream into UDP packets.
              >> > Each UDP packet should ideally have a header which describes the block,
              >> > sample rate, timestamp, etc. I will publish more details as soon as I
              >> > have uploaded a new beta version with the bug fixed.
              >> >
              >> >
              >> > All the best,
              >> > Wolf .
              >> >
              >> > Am 06.02.2011 02:54, schrieb popdeye88:
              >> >> Looking for ideas/ guidance/ experience here.
              >> >>
              >> >> Anybody ever try to use SpecLab with an NI DAQ card (e.g. PCI-4462,
              >> see http://sine.ni.com/nips/cds/view/p/lang/en/nid/202237 )? Might
              >> ASIO (e.g. http://www.asio4all.com/ ) be of any use perhaps?
              >>
              >>
              >
              >

              --
              ehydra.dyndns.info
            Your message has been successfully submitted and would be delivered to recipients shortly.