Now that perl has some measure of thread support (based on pthreads it seems), I might be able to use that.

* Is it possible to share perl objects between threads?

* If so, how efficient is that?

* Does it also work with XS backed objects?

* If I can't share perl objects, would it be possible to create a 100% C thread that directly calls into the C code/data in another thread?

* Are there any pitfalls I should look out for?

However, if you use Object::InsideOut, all these details are taken care of for you.

Regardless of your approach, you need to be conversant with the threads and threads::shared PODs.

If you can get SDL::Mixer to work for you, you should be able to incorporate it with Gtk2. You may be able to use the "do 1 loop" trick of Gtk2

Gtk2->main_iteration while Gtk2->events_pending;
[download]

#!/usr/bin/perl -w
use strict;
use Gtk2;
use Tk;

my $mw = MainWindow->new(-title=>'Tk Window');

Gtk2->init;

my $window = Gtk2::Window->new('toplevel');
$window->set_title('Gtk2 Window');
my $glabel = Gtk2::Label->new("This is a  Gtk2 Label");
$window->add($glabel);
$window->show_all;

my $tktimer = $mw->repeat(10, sub{
   Gtk2->main_iteration while Gtk2->events_pending;
  });


$mw->Button(-text=>'     Quit     ',
       -command => sub{exit}
        )->pack();

MainLoop;
__END__
[download]

As far as threads go, the recent versions of Gtk2 have a way to share Gtk2 objects across threads, but it is tricky and not generally gauranteed to always work. It has an enter and leave method, to tell Gtk2 to enter and leave the thread.

use Gtk2 qw/-init -threads-init/;

die "Glib::Object thread safetly failed"
        unless Glib::Object->set_threadsafe (TRUE);

.....
.....

sub thread_work{
     
      Gtk2::Gdk::Threads->enter;
        .........  
        .........
      Gtk2::Gdk::Threads->leave;
        
}
[download]

Actually, the mixing part of the program is more or less done already - it's all handled by compiled C plugins. I discarded SDL from consideration because it doesn't seem to give me enough low level access: I need to be able to generate audio streams quickly and dump them on the sound device (something like 40 samples at a time, that's once every ~0.001 second).

SDL has a lot of nice routines for playing & mixing long samples & streams, but nothing that gives me that kind of response. Or so it seems to me reading the docs. If you or anyone else have tried something like this with SDL, I'd be happy to hear your stories :-)

"What should it profit a man, if he should win a flame war, yet lose his cool?"

I use SDL_mixer, and I would echo your conclusion: it doesn't give enough low level access. It's fine for playing one background music track and doing fire & forget sound effects, but that's it. For my project, that's just barely kinda mostly sorta good enough for now, but the next time I revisit audio I'll be switching to either OpenAL or the raw ALSA API. I want to be able to change the volume of a triggered sound effect while it's playing. I want an immediate notification of when a sound has completed so I can sequence something else (non-audio) after it. I want to get feedback about how far through a sound I am. I want to do pitch bending. I wouldn't mind some 3D sound processing (although I think SDL_mixer can do some of that.)

One alternative to generic perl that is great for processing vector data (like audio streams) is the Perl Data Language, or PDL. The vector and matrix operations are implemented in highly optimized C code and are programmed in a Matlab-like dialect that makes it easy to express DSP algorithms.

I am aware of PDL :-) I don't actually do any audio processing in perl itself (though the API allows it) - the plugins written in C take care of all the audio data (except for a few conversions to Audio::Play, but even that is mostly C code).

The perl based plugins only do "control channels", that is - they generate only 1 float per channel each "tick" (with ticks once every 40 .. 200 samples). PDL can't really help with the control data, I think, since you're not acting on arrays of numbers, only single values.

I do see there's now a PDL::Audio module on CPAN. That wasn't there when I started this (2 years ago). I'll have to check it out.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

For my C++ generation code, the perl functions specify a signal-processing netlist. I used the graph modules to solve the dependencies in the netlist, so that the C++ code came out in the correct order. It works great, and the generated code is clean. It looks like it was typed in by a very patient programmer! A typical example is a 51 line perl program that turned into a 9102 line Jack application.

That sounds very interesting. Do you have any code lying around that I can take a look at? :-)

At the moment, the graph I'm dealing with is a net of connected plugins that are mostly written in C (LADSPA plugins). I just calculate the right order once it's needed (in perl, using the Graph modules) and cache that until the the network is changed. After that the speed is acceptable - not great, but good enough for small experiments at least - since all I do is call one method for each plugin to generate a partial stream of X samples. The rest is normally handled in C.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

I don't have anything that I can post right now.

I used HTML::Template on the C++ code, and I was in the process of switching to Text::Fillin when I stopped working on it. My code is from the early days of Jack when it was a moving target. I hope to get back to it someday and publish it in an updated form.

Our approaches are somewhat similar, and they are also similar to the PD (Pure Data) approach. The difference is that we like perl code, and PD uses a GUI instead.

I don't know if you are using the low-latency linux patches, etc, but if you are not, you should visit Planet CCRMA at home. The PlanetCCRMA web site and mailing list is a great place to find help and advice on linux audio development!

It should work perfectly the first time! - toma

I've got a working core - all the functionality to connect plugins and produce sound are there (that's Audio::LADSPA::Network plus a few additional plugins), and there's a functional GUI for it, including loading & saving networks.

Currently I'm working on the sequencing part, which still needs a lot of GUI work. I don't know when that'll be done, since I'm also pretty busy doing paid work.

By the way, I've just uploaded the latest version (0.018) of Audio::LADSPA to CPAN. This doesn't include the GUI but at least it allows you to play around with any ladspa plugins you might have installed.

"What should it profit a man, if he should win a flame war, yet lose his cool?"