in reply to Re: mysterious hardware/OSS/Gtk interaction?
in thread mysterious hardware/OSS/Gtk interaction?

Thanks for the replies, Khen1950fx and zentara!

Khen1950fx, I think I didn't explain the problem clearly enough. The example I gave is truly a minimal example, in the sense that the sound I/O stuff is necessary in order to produce the buggy behavior. The problem is not that the "foo" button is small and hard to see, it's that it actually isn't rendered at all. If I take your code and put the sound I/O back in, I get this:

#!/usr/bin/perl use strict; use warnings; use Gtk2 '-init'; use IO::File; my $mw = Gtk2::Window->new('toplevel'); my $t = Gtk2::Table->new(1, 2, 0); $mw->add($t); my $label = Gtk2::Label->new('Example'); $t->attach_defaults($label, 0, 1, 0, 1); $label->show; my $button = Gtk2::Button->new('foo'); $t->attach_defaults($button, 0, 1, 1, 2); $button->signal_connect( 'clicked' => sub { exit } ); $button->show; $mw->show_all; my $dsp = new IO::File("</dev/dsp"); my $event_source_tag = Glib::IO->add_watch( fileno($dsp), 'in', sub { my $buff = " " x 1024; my $nread = read($dsp,$buff,1024); return 1; } ); Gtk2->main; 0;

This works on the same machine where my original example works, and fails on the same machine where my original example fails.

Here is a rundown on which machines it works on and which it fails on:

AMD Athlon 64 X2 4200+, Gigabyte GA-M61P-S3, onboard sound, Ubuntu 10.10 -- works

Dell Optiplex GX260, 1.8 GHz P4, 512 Mb, 40 Gb, onboard sound, Ubuntu 10.04 -- fails

Dell Optiplex GX260, 1.8 GHz P4, 512 Mb, 40 Gb, onboard sound, Ubuntu 10.10 -- fails

Core 2 Duo E8400, 3 GHz, Gigabyte EP45-UD3P mobo, onboard sound, Ubuntu 10.04 -- fails

HP, Ubuntu 10.10 -- fails

I suspect that the problem has something to do with event handling in Gtk. Maybe the program gets overloaded with events and never gets a chance to draw the widget? But I don't understand why it's hardware-dependent, and I don't understand how to fix it :-(

Replies are listed 'Best First'.
Re^3: mysterious hardware/OSS/Gtk interaction?
by zentara (Cardinal) on Mar 11, 2011 at 16:17 UTC
    I suspect that the problem has something to do with event handling in Gtk. Maybe the program gets overloaded with events and never gets a chance to draw the widget? But I don't understand why it's hardware-dependent,

    You are thinking corectly. I notice it works on a newer 64 bit machine and fails on older, slower, 32 bit machines with minimum ram for Ubuntu ( 512 Mb).

    Also, you are going to find that io operations will block anything if they are hung. So the solution for you, is to put the /dev/dsp read io watch into a separate thread. See Threads-w-Perl/Gtk2 demo for a simplistic example.


    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh
Re^3: mysterious hardware/OSS/Gtk interaction?
by Khen1950fx (Canon) on Mar 11, 2011 at 23:20 UTC
    Good! I added Audio::DSP, and it works, provided that you give it a specfic file to read.
    #!/usr/bin/perl use strict; use warnings; use Gtk2 '-init'; use IO::File; use Audio::DSP; $|=1; my $mw = Gtk2::Window->new('toplevel'); my $t = Gtk2::Table->new(1, 2, 0); $mw->add($t); my $label = Gtk2::Label->new('Example'); $t->attach_defaults($label, 0, 1, 0, 1); $label->show; my $button = Gtk2::Button->new('foo'); $t->attach_defaults($button, 0, 1, 1, 2); $button->signal_connect( 'clicked' => sub { exit } ); $button->show; $mw->show_all; my $dsp = new IO::File("</dev/dsp"); my $event_source_tag = Glib::IO->add_watch( fileno($dsp), 'in', sub { my ($buf, $chan, $fmt, $rate) = (4096, 1, 8, 8192); $dsp = new Audio::DSP(buffer => $buf, channels => $chan, format => $fmt, rate => $rate); my $seconds = 5; my $length = ($chan * $fmt * $rate * $seconds) / 8; $dsp->init() || die $dsp->errstr(); for (my $i = 0; $i < $length; $i += $buf) { #records $dsp->read() || die $dsp->errstr(); for (;;) { #playback $dsp->write() || last; } $dsp->close(); } }); Gtk2->main; 0;

      Ah, thanks for showing me how to do it with Audio::DSP. OSS emulation is getting to be a pain on linux.

      I switched to the fork-and-disk-buffer design, and it seems to work fine on two test machines. Performance was fine with locks and semaphores, so I didn't need to learn Sys V IPC. For anyone who's interested, the code is here: http://www.lightandmatter.com/scope/scope.html (Actually, if you could test it for me on your hardware, that could be helpful!)

      Thanks, folks, for the help!!!

      -Ben