in reply to mysterious hardware/OSS/Gtk interaction?

Although it runs on the development machine, it has failed on three out of three other machines I tried it on. There doesn't seem to be any common denominator, e.g., the version of the OSS doesn't predict whether it will work or not.

Your code runs fine here. From my accumulated zen wisdom in how this stuff goes down, whenever there seems to be odd issues where the very same code runs differently on other machines, it usually is some hardware difference.... maybe the io from the /dev/dsp is better from the /dev/dsp on some machines, and on others, the oss io is flawed and creates a bottleneck. Who knows? But the code you posted is valid, runs here fine, and what else can I say except check those differences in the kernel and software updates from Ubuntu 10.04 to 10.10, and see how they may affect your particular hardware. You don't even mention if the 2 machines have the same hardware... ie processor speed, ram, and soundcard.


I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh
  • Comment on Re: mysterious hardware/OSS/Gtk interaction?

Replies are listed 'Best First'.
Re^2: mysterious hardware/OSS/Gtk interaction?
by bcrowell2 (Friar) on Mar 11, 2011 at 16:07 UTC
    Thanks for the reply, zentara. I posted a list of hardware above. What hardware and OS are you running? Since the problem only occurs when I'm using sound, I guess the best option I can think of is something like this. Have the program fork itself. Fork A is responsible for reading sound input and storing the results in a circular buffer on disk. Fork B runs the GUI and only reads from the buffer file when needed. Does this seem like a reasonable plan?
      Does this seem like a reasonable plan?

      Yeah, forking is good, probably better than threads. The only time you really need threads is for "realtime" sharing of cross-thread data. Also depending on your buffer design, you may need some sort of file locking.

      But in that regards of timing, especially with sound, you may want to go with the fastest IPC possible, thru shared memory segments. Search for examples of IPC::SysV


      I'm not really a human, but I play one on earth.
      Old Perl Programmer Haiku ................... flash japh