Find the answer to your Linux question:
Results 1 to 7 of 7
I am wondering if the method described below is feasble. I want to capture short randomly occurring events such as Sudden Interstellar Disturbances, Lightning, ion counting, etc. To do this ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux User
    Join Date
    Mar 2008
    Posts
    287

    Capturing random events


    I am wondering if the method described below is feasble.
    I want to capture short randomly occurring events such as Sudden Interstellar Disturbances, Lightning, ion counting, etc.
    To do this I wish to use the LINE-IN port. My sensor would feed a signal of less that 2 volts but could be submitted via a voltage divider.
    Since the sound card captures 44100 events per second this should capture events I am looking at, I think, but maybe not.
    I would capture the sound buffer to a string or memory buffer every second (and half second so I can prevent overwriting of its buffer, then merge the two).
    Every 60 seconds (for validation) I would run "time" and count full buffer transfers in between to time events. By effectively counting characters from the beginning of the processing buffer to the beginning of the event I could further refine the "time to event".
    I think I could then save a decent number of values or until no data received from the processing buffer to preserve the event.
    This I would output with event time (to within 1/44100 sec) along with the data points captured to a file.
    Except for the outputting of info to a file I think I can scan a buffer for events within a second (while LINE-IN continues capturing data on that port). I believe I have a way to handle the outputting.
    I am asking if any of the processing of the previous buffer would interfere with the sound cards data capture on LINE-IN? There would be no disabling of interrupts. I am presuming that system interrupts would not effect the LINE-IN data capture. Is this true?

  2. #2
    Just Joined!
    Join Date
    Jan 2006
    Posts
    6
    First, im no expert, so please understand that i am just presenting my best guess.
    Guess.

    From my understanding, as long as your code lies completely outside the kernel, System interrupts should have no effect.

    However, depending on how your code is written (I am assuming you are writing this in C, or something where memory can be allocated by hand, such that buffers can be manipulated themselves).

    That being said, running of the command "time" may have an impact, but I'm not sure. System clocks are not something I claim to know much about.

    I am interested to hear whether your system works or not, however.

    Let me know if I have cleared up any of your questions.

  3. #3
    Just Joined!
    Join Date
    Jan 2006
    Posts
    6
    I just realized this is in the scripting forum, so do you think you could paste the script? That might help.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux User
    Join Date
    Nov 2008
    Location
    Tokyo, Japan
    Posts
    260

    How can one use ALSA to precisely time stamp read events?

    As far as I know, the sound card buffers its own data, so even if the operating system interrupts during recording, the samples coming in are delivered in time to keep the sound cards buffer from overflowing. This means the accuracy of the samples is as accurate as the sound card can possibly make it, which is probably more than good enough for your purposes. I think the "sox" program can be used to gather samples from a sound card and record to disk continuously. If you can zero in on the time that recording started, you can be fairly certain that the number of samples from the start of the file is a faithful representation of the time elapsed.

    The problem is the "time" command itself. Its a real challenge to design operating systems that guarantee accurate timing of events to user-level processes. System interrupts can mess with timing results. To quote the "time" manual page:
    ACCURACY [of the "time" command]
    The elapsed time is not collected atomically with the execution of the program; as a result, in bizarre circumstances (if the time command gets stopped or swapped out in between when the program being timed exits and when time calculates how long it took to run), it could be much larger than the actual execution time.
    Although you can deduce running time from the number of samples you have, the fact that it is not atomic means there will be a gap of an indeterminate but small amount of time between the starting time recorded by the "time" command and the actual point in time the sound recording program was executed. In other words, a gap between the point in time that the "time" program recorded its time stamp, and the actual point in time the samples start coming in from the sound card. This gap might make it very difficult to zero in on the exact time of certain events.

    However, if you use the ALSA library, it might be possible to get your sound driver to record a much more precise starting-time into the kernel-ring buffer (which can be viewed with "dmesg"). If you begin reading from your sound card, and the kernel itself gets a time stamp just before reading input samples from the sound card device, you may have better luck zeroing in on a more precise starting time for the sound recording. This is because the sound card driver works in the kernel, unlike the "time" command which works in user space. Things happening in the kernel are essentially uninterrupted, so you can trust the time stamps reported by the kernel much more than the "time" command.

    So a better question to ask is, How can one use ALSA to precisely time stamp read events? I am not an ALSA expert, so I unfortunately don't know. You may find something useful at their web site.

    There is also something called "Real Time Linux" which intended to make Linux handle timing events with much greater precision. But I don't know how active or mature the project is, nor how easy it may be to install or use.

  6. #5
    Linux User
    Join Date
    Mar 2008
    Posts
    287

    Capturing random events

    Ramin.honary tnx 4 insightful comments. I have software that captures seismic data up to 50 samples/sec without using the sound card tho. So will likely use the proposed method of sampling at half second (capturing 1st half) then a full record at the end. The 1st 1/4 of 1st capture will over-write the beginning of the full buffer just in case the movement is delayed and over-writes the beginning of the 1 seconds full record.
    I gather from what you are saying that the sound card plods along without being effected by interrupts. From this I think using "time" will satisfy my needs because it will be used only every hour and will have my buffer count to verify against. I believe we are talking in millisecond delays at worst so this should be acceptable.
    I am of the belief that when an interrupt occurs, the instruction pointer is placed on the stack for the current user's time slice, then the interrupts pointer replaces it. When the interrupt is satisfied the stack is popped and becomes the pointer to the current instruction and all goes on from there.
    IRQs take very little time but do effect user space (also system space as they can become stacked). With that looming over head my concern was, as you both indicated, whether the soundcard (being part of the Mobo) would be a coincident process and be running instructions in its own space (e.g. wiht its own processor and memory) which is what I gather you both are saying. So it looks like I'm good to go. PS no code yet but have fiddled a bit with it for my gravity detector.
    Tnx again

  7. #6
    Linux User
    Join Date
    Nov 2008
    Location
    Tokyo, Japan
    Posts
    260
    Yes, everything you said is correct. But the operating system's process scheduling algorithm handles everything so there isn't too much to worry about.

    The sound card wouldn't be much use if it for some reason slowed down or halted for a period of time during recording. The captured data would be worthless.

    I know that the sound card's buffer can overflow if the system becomes too busy and the recording application is forced to wait too long to store the incoming data. Maybe the sound card's driver buffers data in the kernel to prevent this from happening? I am not sure. If the buffer does overflow, the sound card device will throw an exception signal to the sound card's driver, and the kernel will kill your recording process with an error flag set. But the scheduling algorithm used by Linux is pretty good at avoiding these situations -- I've never personally had that happen to me. You can also use sudo nice -n -10 my-script to tell the scheduler to give a higher priority to your data recorder script.

    Good luck with your project!
    Last edited by ramin.honary; 05-10-2011 at 04:30 AM.

  8. #7
    Linux User
    Join Date
    Mar 2008
    Posts
    287
    Ramin.honary, Tnx again for UR enlightening response. UR 2nd paragraph was so beautifully logical. The comment about "nice-ing" the app is appreciated because it had not thought in that direction since I used it for my gravity meter.
    A grateful and a final THANK YOU!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •