6 Jun
2008
6 Jun
'08
3:30 p.m.
hey,
when i request a lot of parameters in one function:
get_channel_setup_settings(void)
{
pmesg(100, "midi get_channel_setup_settings()\n");
int i;
for (i = 367; i <= 415; i++)
{
param_request(i);
}
for (i = 512; i <= 639; i++)
{
param_request(i);
usleep(100000);
}
}
(param_request just sends a sysex message for the requested
parameter)
then i discover some weirdness:
midi get_channel_setup_settings()
midi param_request()
midi nibble(367, 1)
midi sysex_delivery()
midi midi_callback() ENTERING
midi unibble(111, 2)
midi unibble(4, 0)
midi midi_callback() got param: 367, value: 4
midi param_request()
midi nibble(368, 1)
midi sysex_delivery()
midi param_request()
midi nibble(369, 1)
midi sysex_delivery()
midi param_request()
....
parameter requests only, until the last parameter:
...
midi param_request()
midi nibble(639, 1)
midi sysex_delivery()
midi set_spinbutton() <- rest of midi_callback() from above
midi midi_callback() ENTERING
midi unibble(112, 2)
midi unibble(0, 0)
midi midi_callback() got param: 368, value: 0
...
(midi_callback is catching the received answers. its
running in another thread)
...
midi unibble(51, 4)
midi unibble(51, 0)
midi midi_callback() got param: 563, value: 51
midi set_spinbutton()
.
now there are two things i dont understand:
first: why is the midi_callback() thread being called once
at the beginning, right after the very first parameter
request and then never again until the very last request?
second: why does the midi_callback() thread only receive
the parameters up to 563 where the last request was for
parameter 639? i am missing the remaining parameters! :-)
about the second weirdness: this can only be a problem on
the receivers side (alsa) as i gave the device i am sending
to more than enough time to answer before its "message
receive buffer" could ever be filled (see the usleeps after
every request). i would guess that some alsa side buffer is
filled up and alsa just drops the rest.
solutions would be:
1. call the midi_callback() thread more often
2. resize the alsa midi input buffer to something more big.
how would i do any of this, preferably 1.?
thank you,
Jan
6 Jun
6 Jun
4:32 p.m.
On Fri, Jun 06, 2008 at 07:30:49PM +0200, rdxesy(a)yahoo.de wrote:
now there are two things i dont understand:
first: why is the midi_callback() thread being called once
...
1. call the midi_callback() thread more often
...
I try to understand what's happening, but your terminology
is somewhat confusing...
Threads are run, or can be running or waiting, but they
are never 'called'. Functions are called.
So what is this 'midi callback' thing exactly ?
Is it a thread doing a blocking read() on a midi port,
and waking up when there is data for it ? If so what
does this trhead do with the data it receives ?
Or is it a function you call periodically ?
Or something else ?
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
4:47 p.m.
On Fri, Jun 06, 2008 at 20:22:44 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Fri, Jun 06, 2008 at 07:30:49PM +0200,
rdxesy(a)yahoo.de wrote:
Ciao,
sorry for being unprecise.
let me show you :)
...
pthread_create (&midi_listener, NULL, midi_listen, NULL);
...
static void
*midi_listen(void *ptr)
{
int seq_nfds, i;
struct pollfd *pfds;
seq_nfds = snd_seq_poll_descriptors_count(seq, POLLIN);
pfds = (struct pollfd *)alloca(sizeof(struct pollfd) * (seq_nfds));
snd_seq_poll_descriptors(seq, pfds, seq_nfds, POLLIN);
while (1)
{
if (poll (pfds, seq_nfds, 1000) > 0)
{
pmesg(100, "poll\n");
for (i = 0; i < seq_nfds; i++)
if (pfds[i].revents > 0)
midi_callback ();
}
}
}
static void
midi_callback(void)
{
pmesg(100, "midi midi_callback() ENTERING\n");
snd_seq_event_t *ev;
unsigned char *data = NULL;
int param, value, err;
do
{
err = snd_seq_event_input(seq, &ev);
if (err < 0)
return;
if (ev->type == SND_SEQ_EVENT_SYSEX)
{
data = ev->data.ext.ptr;
... set sliders and stuff eg:
if (param == VOLUME || param == PAN)
{
gdk_threads_enter ();
set_slider(param, value);
gdk_threads_leave ();
}
...
}
while (snd_seq_event_input_pending(seq, 0) > 0);
}
I guess this makes things clearer :)
While this thread is running i am requesting the parameters
as shown earlier.
Cheers,
Jan
now there are two things i dont understand:
first: why is the midi_callback() thread being called once
...
1. call the midi_callback() thread more often
...
I try to understand what's happening, but your terminology
is somewhat confusing...
Threads are run, or can be running or waiting, but they
are never 'called'. Functions are called.
So what is this 'midi callback' thing exactly ?
Is it a thread doing a blocking read() on a midi port,
and waking up when there is data for it ? If so what
does this trhead do with the data it receives ?
Or is it a function you call periodically ?
Or something else ?
Ciao,
5:04 p.m.
note: there is no
poll
output in my first email, because i added the following
line afterwards
pmesg(100, "poll\n");
Jan
6:38 p.m.
On Fri, Jun 06, 2008 at 08:47:27PM +0200, rdxesy(a)yahoo.de wrote:
I guess this makes things clearer :)
What is this midi_spinbutton() ??
Is there anything in the midi_callback() that can
block it ? A mutex or so reset after the parameter
request loops ?
There must be at least 10s of idle time in the
second loop (with the usleep()). So if the
midi receiver thread doesn't wake up during
this time then
- It could be blocked on something else and not
be waiting in poll(). The trace message you
added later should reveal this.
- There is no data to receive. This would indicate
some cramp in the device you're talking with that
somehow freezes while being flooded with parameter
requests.
- There is a bug in the alsa code handling this.
The really strange thing is that you *do* receive
all the replies for those requests that were sent
without a pause in between. It's the replies to
some of the slower ones that are missing. This
would suggest that, whatever goes wrong, the
damage is already done before you start the second
slower loop. You could try to decrease the
number of iterations in the first one and see
what happens, and if the results are repeatable.
Another thing you should do is verify if you
really need a separate request for each value.
The last two SYSEX protocols I used both allowed
to combine a number of requests in a single
message, also combining the replies in that
case. It would make sense for any device having
so many parameters to support this.
Another approach to avoid overflows in a system
without flow control is to use a 'sliding window'
system: for example you don't sent request #123
until you have received the answer for #113,
ensuring there are never more than 10 (in this
case) in the pipeline. It allows things to
work at maximum speed without flooding buffers.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
7:04 p.m.
On Fri, Jun 06, 2008 at 10:28:01PM +0200, Fons Adriaensen wrote:
- There is no data to receive. This would indicate
some cramp in the device you're talking with that
somehow freezes while being flooded with parameter
requests.
The simple way to check this is to receive the data
with a second computer. Or hang a scope on the midi
line. Or a headphone (in series with a 1k resistor)
and listen to it. Or input it to a line input on
of an audio card (with some attenuation in between).
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
8:20 p.m.
On Fri, Jun 06, 2008 at 22:28:01 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Fri, Jun 06, 2008 at 08:47:27PM +0200,
rdxesy(a)yahoo.de wrote:
it just sets a gtk spinbutton to a value. nothing else. no
mutexes or anything that blocks.
I guess this makes things clearer :)
What is this midi_spinbutton() ??
Is there anything in the midi_callback() that can
block it ? A mutex or so reset after the parameter
request loops ? There must be at least 10s of idle time in the
second loop (with the usleep()). So if the
midi receiver thread doesn't wake up during
this time then
- It could be blocked on something else and not
be waiting in poll(). The trace message you
added later should reveal this.
what follows is a trace of the request loop *without*
usleep but with the poll message:
midi get_channel_setup_settings()
midi param_request()
midi nibble(512, 1)
midi sysex_delivery()
midi param_request()
midi nibble(513, 1)
... (no poll until the last request, no wonder as there is
no more usleep)
midi param_request()
midi nibble(639, 1)
midi sysex_delivery()
poll
midi midi_callback() ENTERING
midi unibble(0, 4)
midi unibble(0, 0)
midi midi_callback() got param: 512, value: 0
midi set_spinbutton()
poll
midi midi_callback() ENTERING
midi unibble(1, 4)
midi unibble(1, 0)
midi midi_callback() got param: 513, value: 1
midi set_spinbutton()
midi unibble(2, 4)
midi unibble(2, 0)
midi midi_callback() got param: 514, value: 2
midi set_spinbutton()
midi unibble(3, 4)
midi unibble(3, 0)
midi midi_callback() got param: 515, value: 3
midi set_spinbutton()
midi unibble(4, 4)
midi unibble(4, 0)
midi midi_callback() got param: 516, value: 4
midi set_spinbutton()
midi unibble(5, 4)
midi unibble(5, 0)
midi midi_callback() got param: 517, value: 5
midi set_spinbutton()
midi unibble(6, 4)
midi unibble(6, 0)
midi midi_callback() got param: 518, value: 6
midi set_spinbutton()
midi unibble(7, 4)
midi unibble(7, 0)
midi midi_callback() got param: 519, value: 7
midi set_spinbutton()
midi unibble(8, 4)
midi unibble(8, 0)
midi midi_callback() got param: 520, value: 8
midi set_spinbutton()
midi unibble(9, 4)
midi unibble(9, 0)
midi midi_callback() got param: 521, value: 9
midi set_spinbutton()
midi unibble(10, 4)
midi unibble(10, 0)
midi midi_callback() got param: 522, value: 10
midi set_spinbutton()
midi unibble(11, 4)
midi unibble(11, 0)
midi midi_callback() got param: 523, value: 11
midi set_spinbutton()
midi unibble(12, 4)
midi unibble(12, 0)
midi midi_callback() got param: 524, value: 12
midi set_spinbutton()
midi unibble(13, 4)
midi unibble(13, 0)
midi midi_callback() got param: 525, value: 13
midi set_spinbutton()
midi unibble(14, 4)
midi unibble(14, 0)
midi midi_callback() got param: 526, value: 14
midi set_spinbutton()
midi unibble(15, 4)
midi unibble(15, 0)
midi midi_callback() got param: 527, value: 15
midi set_spinbutton()
midi unibble(16, 4)
midi unibble(16, 0)
midi midi_callback() got param: 528, value: 16
midi set_spinbutton()
midi unibble(17, 4)
midi unibble(17, 0)
midi midi_callback() got param: 529, value: 17
midi set_spinbutton()
midi unibble(18, 4)
midi unibble(18, 0)
midi midi_callback() got param: 530, value: 18
midi set_spinbutton()
midi unibble(19, 4)
midi unibble(19, 0)
midi midi_callback() got param: 531, value: 19
midi set_spinbutton()
midi unibble(20, 4)
midi unibble(20, 0)
midi midi_callback() got param: 532, value: 20
midi set_spinbutton()
midi unibble(21, 4)
midi unibble(21, 0)
midi midi_callback() got param: 533, value: 21
midi set_spinbutton()
midi unibble(22, 4)
midi unibble(22, 0)
midi midi_callback() got param: 534, value: 22
midi set_spinbutton()
midi unibble(23, 4)
midi unibble(23, 0)
midi midi_callback() got param: 535, value: 23
midi set_spinbutton()
midi unibble(24, 4)
midi unibble(24, 0)
midi midi_callback() got param: 536, value: 24
midi set_spinbutton()
midi unibble(25, 4)
midi unibble(25, 0)
midi midi_callback() got param: 537, value: 25
midi set_spinbutton()
midi unibble(26, 4)
midi unibble(26, 0)
midi midi_callback() got param: 538, value: 26
midi set_spinbutton()
midi unibble(27, 4)
midi unibble(27, 0)
midi midi_callback() got param: 539, value: 27
midi set_spinbutton()
midi unibble(28, 4)
midi unibble(28, 0)
midi midi_callback() got param: 540, value: 28
midi set_spinbutton()
midi unibble(29, 4)
midi unibble(29, 0)
midi midi_callback() got param: 541, value: 29
midi set_spinbutton()
midi unibble(30, 4)
midi unibble(30, 0)
midi midi_callback() got param: 542, value: 30
midi set_spinbutton()
midi unibble(31, 4)
midi unibble(31, 0)
midi midi_callback() got param: 543, value: 31
midi set_spinbutton()
midi unibble(32, 4)
midi unibble(32, 0)
midi midi_callback() got param: 544, value: 32
midi set_spinbutton()
poll
midi midi_callback() ENTERING
midi unibble(33, 4)
midi unibble(33, 0)
midi midi_callback() got param: 545, value: 33
midi set_spinbutton()
midi unibble(34, 4)
midi unibble(34, 0)
midi midi_callback() got param: 546, value: 34
midi set_spinbutton()
poll
midi midi_callback() ENTERING
midi unibble(35, 4)
midi unibble(35, 0)
midi midi_callback() got param: 547, value: 35
midi set_spinbutton()
poll
midi midi_callback() ENTERING
midi unibble(36, 4)
midi unibble(36, 0)
midi midi_callback() got param: 548, value: 36
midi set_spinbutton()
poll
midi midi_callback() ENTERING
midi unibble(37, 4)
midi unibble(37, 0)
midi midi_callback() got param: 549, value: 37
midi set_spinbutton()
poll
midi midi_callback() ENTERING
midi unibble(38, 4)
midi unibble(38, 0)
midi midi_callback() got param: 550, value: 38
midi set_spinbutton()
poll
midi midi_callback() ENTERING
midi unibble(39, 4)
midi unibble(39, 0)
midi midi_callback() got param: 551, value: 39
midi set_spinbutton()
poll
midi midi_callback() ENTERING
midi unibble(40, 4)
midi unibble(40, 0)
midi midi_callback() got param: 552, value: 40
midi set_spinbutton()
poll
midi midi_callback() ENTERING
midi unibble(41, 4)
midi unibble(41, 0)
midi midi_callback() got param: 553, value: 41
midi set_spinbutton()
midi unibble(42, 4)
midi unibble(42, 0)
midi midi_callback() got param: 554, value: 42
midi set_spinbutton()
midi unibble(43, 4)
midi unibble(43, 0)
midi midi_callback() got param: 555, value: 43
midi set_spinbutton()
midi unibble(44, 4)
midi unibble(44, 0)
midi midi_callback() got param: 556, value: 44
midi set_spinbutton()
midi unibble(45, 4)
midi unibble(45, 0)
midi midi_callback() got param: 557, value: 45
midi set_spinbutton()
midi unibble(46, 4)
midi unibble(46, 0)
midi midi_callback() got param: 558, value: 46
midi set_spinbutton()
midi unibble(47, 4)
midi unibble(47, 0)
midi midi_callback() got param: 559, value: 47
midi set_spinbutton()
######################################################
... more more more. at one point weirdness begins again:
######################################################
midi unibble(74, 4)
midi unibble(74, 0)
midi midi_callback() got param: 586, value: 74
midi set_spinbutton()
midi unibble(75, 4)
midi unibble(75, 0)
midi midi_callback() got param: 587, value: 75
midi set_spinbutton()
midi unibble(78, 4)
midi unibble(78, 0)
midi midi_callback() got param: 590, value: 78
midi set_spinbutton()
midi unibble(83, 4)
midi unibble(83, 0)
midi midi_callback() got param: 595, value: 83
midi set_spinbutton()
midi unibble(88, 4)
midi unibble(88, 0)
midi midi_callback() got param: 600, value: 88
midi set_spinbutton()
midi unibble(93, 4)
midi unibble(93, 0)
midi midi_callback() got param: 605, value: 93
midi set_spinbutton()
midi unibble(98, 4)
midi unibble(98, 0)
midi midi_callback() got param: 610, value: 98
midi set_spinbutton()
midi unibble(102, 4)
midi unibble(102, 0)
midi midi_callback() got param: 614, value: 102
midi set_spinbutton()
midi unibble(104, 4)
midi unibble(104, 0)
midi midi_callback() got param: 616, value: 104
midi set_spinbutton()
midi unibble(107, 4)
midi unibble(107, 0)
midi midi_callback() got param: 619, value: 107
midi set_spinbutton()
midi unibble(112, 4)
midi unibble(112, 0)
midi midi_callback() got param: 624, value: 112
midi set_spinbutton()
midi unibble(117, 4)
midi unibble(117, 0)
midi midi_callback() got param: 629, value: 117
midi set_spinbutton()
midi unibble(122, 4)
midi unibble(122, 0)
midi midi_callback() got param: 634, value: 122
midi set_spinbutton()
midi unibble(127, 4)
midi unibble(127, 0)
midi midi_callback() got param: 639, value: 127
midi set_spinbutton()
note that this just asks for params 512-639 (the first loop
of the previous posting is commented)
so, after receiving param 590 i receive only every fifth or
fourth param, the rest is gone void.
this is repeatable, everytime. i receive every single param
correctly until and including param 590, then i receive
params with jumps in between, 4 or five params big.
when i add back usleep(10000); to the request loop, i get
all params in correct order but only up and including to
param 612. repeatable, always.
i always request 128 parameters. with usleep enabled in the
request-loop i get exactly 101 answers, always. without the
sleep, the received params vary from 88 to 90.
also (even with usleep enabled requests) there is no
polling except the one in the beginning, because
midi_callback blocks here:
if (param == VOLUME || param == PAN)
{
-> gdk_threads_enter ();
set_slider(param, value);
gdk_threads_leave ();
}
that is why there is no more polling after the first. so,
the problem is that alsa receives receives receives, and no
event gets out of the queue. it overflows.
- There is no data to receive. This would indicate
some cramp in the device you're talking with that
somehow freezes while being flooded with parameter
requests.
this is not the case, for sure.
- There is a bug in the alsa code handling this.
i doubt it, i just think that the receive buffer is too
small.
The really strange thing is that you *do* receive
all the replies for those requests that were sent
without a pause in between. It's the replies to
some of the slower ones that are missing. This
would suggest that, whatever goes wrong, the
damage is already done before you start the second
slower loop. You could try to decrease the
number of iterations in the first one and see
what happens, and if the results are repeatable.
the loop was commented.
Another thing you should do is verify if you
really need a separate request for each value.
The last two SYSEX protocols I used both allowed
to combine a number of requests in a single
message, also combining the replies in that
case. It would make sense for any device having
so many parameters to support this.
hmm, well, let me check...oops! BINGO. there is a program
map request command! lol :-)
well, we could just stop talking right now, should we?
heh...no, please not!
there are other areas where i have to receive more than
alsa handles and loose params.
probably, if there is such an option, i should just resize
the input queue?
Jan
7 Jun
7 Jun
9:24 a.m.
On Sat, Jun 07, 2008 at 12:20:23AM +0200, rdxesy(a)yahoo.de wrote:
...
note that this just asks for params 512-639 (the first loop
of the previous posting is commented)
so, after receiving param 590 i receive only every fifth or
fourth param, the rest is gone void.
this is repeatable, everytime. i receive every single param
correctly until and including param 590, then i receive
params with jumps in between, 4 or five params big.
This could be either the request or the reply
getting lost. The way to find out is to check
the replies using a completely separate receiver
or any other way to monitor a physical midi stream.
when i add back usleep(10000); to the request loop, i
get
all params in correct order but only up and including to
param 612. repeatable, always.
This could well be due to entirely different causes as the
first problem.
I'd first try to get the version with the usleep() working,
and then attack the other problem.
Could you try to remove *all* interaction with gtk in
midi_callback(). Just print the received events with
printf() and run your app from a terminal.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
9 Jun
9 Jun
10:53 p.m.
On Sat, Jun 07, 2008 at 13:14:34 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
This could well be due to entirely different causes as
the
first problem.
I'd first try to get the version with the usleep() working,
and then attack the other problem.
Could you try to remove *all* interaction with gtk in
midi_callback(). Just print the received events with
printf() and run your app from a terminal.
hey there,
i wrote an extra routine for requesting some special
parameters so that there are never too many parameters
requested at once.
its not good to just resize the alsa queue. its not really
a solution.
i am sure that, when i remove the mutexes and gtk stuff
from the midi_callback, the thread wont block.
but what can i do? i want the gui to update as quickly as
possible.
write another queue which is used by the midi_callback to
push data into it and add another thread that reads from
it?
6045
days inactive
6048
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
2 participants
participants (2)
-
Fons Adriaensen -
rdxesy＠yahoo.de