denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] portaudio + fluidsynth


From: Richard Shann
Subject: Re: [Denemo-devel] portaudio + fluidsynth
Date: Sat, 18 Feb 2012 11:08:28 +0000

On Fri, 2012-02-17 at 01:17 +0100, Dominic Sacré wrote:
> Hi Jeremiah, hi Richard,
> 
> Sorry for not getting back to you earlier. A couple of things have come 
> up lately that left virtually no time to really follow this list or the 
> changes in git, and it looks like I have quite a lot of catching up to 
> do...
> 
> On Thursday 16 February 2012 21:47:20 Jeremiah Benham wrote:
> > I don't know if there is a need. It seems to crash all the time no
> > matter what file. I am using the portaudio backend and alsa midi
> > backend. For some reason with the portmidi backend it does not seem
> > to crash as easily. I am also getting many underruns but denemo is
> > not crashing on them. Here is the bt full: No symbol table info
> > available.
> > #10 0x080dba9a in set_playbutton (pause=0) at view.c:8522
> > No locals.
> > #11 0x0812465e in stop_playing () at midi.c:114
> > No locals.
> > #12 0x08128688 in midi_stop () at audiointerface.c:447
> > No locals.
> > #13 0x08128199 in read_event_from_queue (backend=MIDI_BACKEND,
> >     event_buffer=0xb7c6c171 "\220\"\177\n", event_length=0xb7c6c160,
> >     event_time=0xb7c6c128, until_time=8.0942570018768318)
> >     at audiointerface.c:308
> >         playback_time = 8.0053333333333327
> > #14 0x0812b3d6 in process_thread_func (data=0x0) at alsabackend.c:92
> >         pev = 0x0
> >         tv = {tv_sec = 1329423635, tv_usec = 636145}
> >         playback_time = 8.0892570018768311
> >         event_time = 7.5010199999999996
> >         until_time = 8.0942570018768318
> >         timeval = {tv_sec = 1329423635, tv_usec = 635971}
> >         now = 1329423635.6361451
> >         event_data = "\220\"\177"
> >         event_length = 3
> >         mutex = 0x86a1e50
> 
> So far I only took a quick glance at the current state of the master 
> branch, but it looks like this crash is caused by calling GTK code from 
> the ALSA backend's own thread. At the very least these calls would need 
> to be protected by gtk_threads_enter(), but since the same code is also 
> used by the JACK backend, g_idle_add() should be the way to go.

I wonder if my understanding of this is correct? The g_idle_add() if
called in one of the threads adds to a list of things to do when the
main loop finds no event waiting for processing. The main loop is
executing in the main thread, so making a call to g_idle_add() from a
thread is a way of telling the main thread to do something when it next
iterates the main loop (and nothing else needs doing).
Is this correct?

Richard






reply via email to

[Prev in Thread] Current Thread [Next in Thread]