2 Jun
2008
2 Jun
'08
2:13 p.m.
hello ")
Ok, I am writing a remote and SysEx-editor for e-mu
synthesizers (http://ppcontrol.sf.net). I am asking for
help on how to use the alsa sequencer the way it was
intended to be used for this kind of application. You know,
there are so many options and flags and stuff to be used
and I feel a little lost.
Basically I send a lot of SysEx messages and need to make
sure to catch all the answers. My current implementation is
as following:
I have a single sequencer (duplex, nonblocking), a queue
and two ports: one with read and one with write caps. To
send a SysEx command I just queue an event with that
message. (So far so good?).
Now I just wait for an constant time (usleep) before I
check the input queue. Problem: if the time is too short, i
would have missed the answer, if I wait to long I waste
time.
My question is: how would I make sure to catch all answers
from the device without using a thread and without just
waiting for an constant time before I check if there is an
answer( which is alo not very fail save, a message might
take a little longer if there is traffic on the midibus)?
Thank you.
Jan
2 Jun
2 Jun
2:42 p.m.
On Mon, Jun 02, 2008 at 06:13:26PM +0200, rdxesy(a)yahoo.de wrote:
My question is: how would I make sure to catch all
answers
from the device without using a thread and without just
waiting for an constant time before I check if there is an
answer( which is alo not very fail save, a message might
take a little longer if there is traffic on the midibus)?
There seem to be two ways: either you make the read blocking
(which will prevent you from doing anything until a reply
arrives), or use a separate thread to read (again blocking).
For apps handling async events using threads is really the
'natural' thing to do. If multithreading is new to you, now
is the time to jump into it !
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
4:54 p.m.
On Mon, Jun 02, 2008 at 18:33:08 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Mon, Jun 02, 2008 at 06:13:26PM +0200,
rdxesy(a)yahoo.de wrote:
Ciao,
thank you for that info. The problem with that thread
approach is that i cannot call gtk_* stuff from it (which
is needed, as most answers are values that will be used to
set sliders, comboboxes and spinbuttons).
I could use g_idle_add or g_timeout_add for that thread but
that adds another async layer, and questions like "what
would be the timeout"?
Is there a way to call a function in the main loop from a
thread "now and once" (i mean, without using
g_idle/timeout_add, something thats just like a call to a
"normal" function but calls it in the main loop)?
Thank you.
Jan
My question is: how would I make sure to catch
all answers
from the device without using a thread and without just
waiting for an constant time before I check if there is an
answer( which is alo not very fail save, a message might
take a little longer if there is traffic on the midibus)?
There seem to be two ways: either you make the read blocking
(which will prevent you from doing anything until a reply
arrives), or use a separate thread to read (again blocking).
For apps handling async events using threads is really the
'natural' thing to do. If multithreading is new to you, now
is the time to jump into it !
6:05 p.m.
On Mon, Jun 02, 2008 at 07:32:16PM +0200, rdxesy(a)yahoo.de wrote:
thank you for that info. The problem with that thread
approach is that i cannot call gtk_* stuff from it (which
is needed, as most answers are values that will be used to
set sliders, comboboxes and spinbuttons).
I could use g_idle_add or g_timeout_add for that thread but
that adds another async layer, and questions like "what
would be the timeout"?
Is there a way to call a function in the main loop from a
thread "now and once" (i mean, without using
g_idle/timeout_add, something thats just like a call to a
"normal" function but calls it in the main loop)?
"In the main loop" and "from a(nother) thread" are contradictory
- these *are* different threads and nothing can change that.
I don't know the details of GTK, but this is a classic problem
with high-level GUI toolsets: they don't allow you to wait
for X events (which trigger the loop, behind the scenes) and
anyhting else at the same time in the same thread. They don't
even separate _waiting_ for an X event, and _handling_ it into
two separate user calls (which would allow the user to add the
missing multiple wait functionality). This is one of the
reasons why I wrote my own GUI toolkit.
Now if the messages you receive are for display only, there
is no need to be faster than the display update rate, or a
human reader. If the GTK loop times out every say 50ms,
checks the midi input, and if there is any, displays it,
then things should just work. There's no problem if you
are too late as the midi data is buffered. There's no
problem if you're to early, you will get the message next
time.
Other solutions are:
- Use a separate thread to read the midi data, then send
it as an X event (you can make 'user' event types) to your
main window. Doing this will trigger the GTK loop.
- Use a separate thread, and a mutex used by this thread
and the GTK loop to avoid concurrent access to data and
mixed-up X-calls.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
11:04 p.m.
On Mon, Jun 02, 2008 at 21:55:30 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Mon, Jun 02, 2008 at 07:32:16PM +0200,
rdxesy(a)yahoo.de wrote:
Other solutions are:
- Use a separate thread to read the midi data, then send
it as an X event (you can make 'user' event types) to your
main window. Doing this will trigger the GTK loop.
- Use a separate thread, and a mutex used by this thread
and the GTK loop to avoid concurrent access to data and
mixed-up X-calls.
Ciao,
i use the mutex solution since tha fits well into the
existing code "). So, I have a thread that polls the
incoming queue in an endless loop:
while(1)
...
midi_callback()
}
and this function:
midi_callback(void)
{ ...
gdk_threads_enter ();
/* do the slider dance */
gdk_threads_leave ();
...
}
works and i am happy as the gui feedback is almost instant
now. ")
Cheers,
Jan
3 Jun
3 Jun
10:32 a.m.
[Fons Adriaensen]
I don't know the details of GTK, but this is a
classic problem
with high-level GUI toolsets: they don't allow you to wait
for X events (which trigger the loop, behind the scenes) and
anyhting else at the same time in the same thread. They don't
even separate _waiting_ for an X event, and _handling_ it into
two separate user calls (which would allow the user to add the
missing multiple wait functionality). This is one of the
reasons why I wrote my own GUI toolkit.
You should check out g_main_context_set_poll_func() sometime. I admit
it took me longer than it should have to find it myself. In short, it
does what you want. In a gtk way, sure, but it does it.
Cheers, Tim
10:50 a.m.
On Tue, 2008-06-03 at 14:15 +0200, Tim Goetze wrote:
[Fons Adriaensen]
and as an example, the Quartz (OS X) backend for GTK uses this because
it has to wait for events on file descriptors and from Cocoa/Quartz
(equivalent to X11).
sadly, it still ends up using one thread to wait on file descriptors and
this thread "injects" a Cocoa-level event into the other "main" event
thread. this is because OS X, like almost all Unix systems, fails to
provide a single system call to "wait till something happens". you
cannot wait for a file descriptor, semaphore, msgqueue, X event and/or
whatever else with a single blocking system call, and IMHO this is still
one the biggest weaknesses of the POSIX API.
I don't know the details of GTK, but this is a
classic problem
with high-level GUI toolsets: they don't allow you to wait
for X events (which trigger the loop, behind the scenes) and
anyhting else at the same time in the same thread. They don't
even separate _waiting_ for an X event, and _handling_ it into
two separate user calls (which would allow the user to add the
missing multiple wait functionality). This is one of the
reasons why I wrote my own GUI toolkit.
You should check out g_main_context_set_poll_func() sometime. I admit
it took me longer than it should have to find it myself. In short, it
does what you want. In a gtk way, sure, but it does it. 
2 Jun
2 Jun
4:21 p.m.
On Mon, 2008-06-02 at 18:13 +0200, rdxesy(a)yahoo.de wrote:
Now I just wait for an constant time (usleep) before I
check the input queue. Problem: if the time is too short, i
would have missed the answer, if I wait to long I waste
time.
My question is: how would I make sure to catch all answers
from the device without using a thread and without just
waiting for an constant time before I check if there is an
answer( which is alo not very fail save, a message might
take a little longer if there is traffic on the midibus)?
You /could/ use poll:
#include <poll.h>
int poll(struct pollfd *fds, nfds_t nfds, int timeout);
.. which will block, but at most untill timeout, after which you can
notify the user to check his wirings.
Thank you.
Jan
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
6014
days inactive
6015
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
5 participants
participants (5)
-
Fons Adriaensen -
Jens M Andreasen -
Paul Davis -
rdxesy＠yahoo.de -
Tim Goetze