Reading alsa midi-data inside the jack client process thread

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Reading alsa midi-data inside the jack client process thread

Kjetil Matheussen

Is this legal (ie. non-blocking)?

int process (jack_nframes_t nframes, void *arg){
  snd_seq_event_t *event;
  if(snd_seq_event_input_pending(seq,1)){
    snd_seq_event_input(seq, &event);
  ....
}





-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reading alsa midi-data inside the jack client process thread

Alfons Adriaensen
On Fri, Jul 08, 2005 at 12:36:40PM +0200, Kjetil Svalastog Matheussen <[hidden email]> wrote:
 
> Is this legal (ie. non-blocking)?
>
> int process (jack_nframes_t nframes, void *arg){
>   snd_seq_event_t *event;
>   if(snd_seq_event_input_pending(seq,1)){
>     snd_seq_event_input(seq, &event);


Don't have the sources at hand here, but ISTR that
what I do in Aeolus is something like:


  if (snd_seq_event_input_pending (seq,1))
  {
      do
      {
          snd_seq_event_input(seq, &event);
          ...
      }
      while (snd_seq_event_input_pending (seq,0));
  }


It has never blocked AFAICT. It may not be the best
method if you use very short periods - a separate
MIDI thread linked with a lock-free ringbuffer is to
be preferred in that case.


--
FA



-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reading alsa midi-data inside the jack client process thread

Kjetil Matheussen
> On Fri, Jul 08, 2005 at 12:36:40PM +0200, Kjetil Svalastog Matheussen
> <[hidden email]> wrote:
>
>> Is this legal (ie. non-blocking)?
>>
>> int process (jack_nframes_t nframes, void *arg){
>>   snd_seq_event_t *event;
>>   if(snd_seq_event_input_pending(seq,1)){
>>     snd_seq_event_input(seq, &event);
>
>
> Don't have the sources at hand here, but ISTR that
> what I do in Aeolus is something like:
>
>
>   if (snd_seq_event_input_pending (seq,1))
>   {
>       do
>       {
>           snd_seq_event_input(seq, &event);
>           ...
>       }
>       while (snd_seq_event_input_pending (seq,0));
>   }
>
>

Thanks, reading your source, thats correct. (But I don't understand what
the fetch_sequencer argument for snd_seq_event_input_pending does though:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_event.html#a7
)

I also wonder whats the difference between your code above and this:

if (snd_seq_event_input_pending (seq,1)) {
  while(snd_seq_event_input(seq,&event);
      ....
   }
}

which I think should do the same... Guess I just have to read the source. :-)





-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Alsa-devel] Reading alsa midi-data inside the jack client process thread

Clemens Ladisch
In reply to this post by Kjetil Matheussen
Kjetil Svalastog Matheussen <[hidden email]> wrote:
> Is this legal (ie. non-blocking)?
>
> int process (jack_nframes_t nframes, void *arg){
>   snd_seq_event_t *event;
>   if(snd_seq_event_input_pending(seq,1)){
>     snd_seq_event_input(seq, &event);
>   ....
> }

snd_seq_event_input_pending() will not block (it may call poll(), but
with a timeout of zero), and snd_seq_event_input() will not block if
snd_seq_event_input_pending() has returned a value greater than zero.


HTH
Clemens



-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reading alsa midi-data inside the jack client process thread

Alfons Adriaensen
In reply to this post by Kjetil Matheussen
On Fri, Jul 08, 2005 at 02:30:27PM +0200, Kjetil Svalastog Matheussen <[hidden email]> wrote:

> Thanks, reading your source, thats correct. (But I don't understand what
> the fetch_sequencer argument for snd_seq_event_input_pending does though:
>

IIRC, if the second argument of snd_seq_event_input_pending () is
1, it will do a transfer of all available MIDI data from a system
space buffer to user space. If it is zero, it examines only the user
space buffer.

> I also wonder whats the difference between your code above and this:
>
> if (snd_seq_event_input_pending (seq,1)) {
>   while(snd_seq_event_input(seq,&event);
>       ....
>    }
> }

The code as in Aeolus will do one system to user space transfer only,
while if you put your code into a loop, it will do this every time.
The rationale for doing it only once is that
1. it's a system call, and probably relatively expensive,
2. in the short time required to handle the MIDI events arrived
during the past period, it is unlikely that anything new will
arrive anyway.

Point 1. is why you'd probably prefer a separate thread if your
period size could be very small (64, 32, 16). The minimum for
Aeolus is 64 anyway, so I didn't bother. This will change in the
next release, which will handle OSC as well.


--
FA







-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reading alsa midi-data inside the jack client process thread

Kjetil Matheussen
> On Fri, Jul 08, 2005 at 02:30:27PM +0200, Kjetil Svalastog Matheussen
> <[hidden email]> wrote:
>
>> Thanks, reading your source, thats correct. (But I don't understand what
>> the fetch_sequencer argument for snd_seq_event_input_pending does
>> though:
>>
>
> IIRC, if the second argument of snd_seq_event_input_pending () is
> 1, it will do a transfer of all available MIDI data from a system
> space buffer to user space. If it is zero, it examines only the user
> space buffer.
>
>> I also wonder whats the difference between your code above and this:
>>
>> if (snd_seq_event_input_pending (seq,1)) {
>>   while(snd_seq_event_input(seq,&event);
>>       ....
>>    }
>> }
>
> The code as in Aeolus will do one system to user space transfer only,
> while if you put your code into a loop, it will do this every time.
> The rationale for doing it only once is that
> 1. it's a system call, and probably relatively expensive,
> 2. in the short time required to handle the MIDI events arrived
> during the past period, it is unlikely that anything new will
> arrive anyway.
>
> Point 1. is why you'd probably prefer a separate thread if your
> period size could be very small (64, 32, 16). The minimum for
> Aeolus is 64 anyway, so I didn't bother. This will change in the
> next release, which will handle OSC as well.
>
>

Clemens Ladisch:
>snd_seq_event_input_pending() will not block (it may call poll(), but
>with a timeout of zero), and snd_seq_event_input() will not block if
>snd_seq_event_input_pending() has returned a value greater than zero.



Thank you both for the clear and understandable expanations. Everything is
understood. Back to coding. :-)






-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Reading alsa midi-data inside the jack client process thread

Fons Adriaensen
In reply to this post by Kjetil Matheussen
On Fri, Jul 08, 2005 at 02:30:27PM +0200, Kjetil Svalastog Matheussen <[hidden email]> wrote:

> if (snd_seq_event_input_pending (seq,1)) {
>   while(snd_seq_event_input(seq,&event);
>
> which I think should do the same... Guess I just have to read the source. :-)

OOPS, I didn't see the 'while' when commenting on this.
AFAICT it will do the same as my code, if you set the seq
to non-blocking mode.

Happy coding !

--
FA




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel