[CM] Fwd: Linux/Midi Test

[Kjetil S. Matheussen]

That's weird.

Firstly, it's strange that you get bad timing when setting
high priority (is that sched_fifo or sched_rr?).

Secondly, das_watchdog should never kill any process. If
the machine hangs, it just temporarily
turns off realtime priority for most processes to see
if that helps.
And I should know this since I actually wrote das_watchdog. ;-)



On Tue, 11 Aug 2009, lieven moors wrote:

> And another thing, when selecting high priority,
> I do hear sound initially, but it is totally fucked up (timingwise), and the 
> process gets killed
> finally by the watchdog.
>
> lieven moors wrote:
>> I tried the test program with a suprising result.
>> The timing sounds rock solid, with normal permissions, and with a duration 
>> of 62.5 ms.
>> 
>> P.S.
>> When I selected realtime permission, the process was killed by 
>> das_watchdog, and I heard nothing.
>> (das_watchdog guards for realtime processes that block the system)
>> 
>> William Andrew Burnson wrote:
>>> Here is my test program to play back notes in a single JUCE thread to help 
>>> detect jitter:
>>> http://williamburnson.com/midi-test.tar.gz
>>> 
>>> To use it, follow INSTRUCTIONS (basically, drop juce_amalgamated.cpp/h 
>>> into the folder and type make)
>>> 
>>> I tried using snd_seq_drain_output and I didn't notice any difference...
>>> 
>>> ---- Original message ----
>>> 
>>>> Date: Tue, 11 Aug 2009 15:43:31 +0200 (CEST)
>>>> From: "Kjetil S. Matheussen" <k.s.matheussen at notam02.no>  Subject: Re: 
>>>> [CM] Fwd: Linux/Midi Test  To: lieven moors <lievenmoors at gmail.com>
>>>> Cc: Heinrich Taube <taube at uiuc.edu>, cmdist at ccrma.Stanford.EDU, Andrew 
>>>> Burnson <burnson2 at uiuc.edu>
>>>> 
>>>> 
>>>> 
>>>> On Tue, 11 Aug 2009, lieven moors wrote:
>>>>
>>>> 
>>>>> I think I might know what the problem is with Juce. I had a look at the
>>>>> Juce code myself,
>>>>> and it looks like sendMessageNow() is not calling the
>>>>> snd_seq_drain_output().
>>>>> 
>>>> For what its worth, the one time I've written code which sends
>>>> midi via alsa, the code calls snd_seq_drain_output as last
>>>> operation. I don't remember what I did back then, but this
>>>> could definitely be the problem. It sounds likely, at least.
>>>> 
>>>> 
>>>> static void alsaseq_PutMidi(
>>>>                 struct MidiLink *midilink,
>>>>                 uint32_t msg
>>>>                 )
>>>> {
>>>>   unsigned int d3=(msg>>8)&0xff;
>>>>   unsigned int d2=(msg>>16)&0xff;
>>>>   unsigned int d1=(msg>>24)&0xff;
>>>>
>>>>   unsigned char buffer[3]={d1,d2,d3};
>>>>   snd_seq_event_t ev;
>>>>   snd_midi_event_t *midi_ev;
>>>>   snd_midi_event_new( 10, &midi_ev );
>>>>
>>>>   snd_seq_ev_clear( &ev );
>>>>   snd_midi_event_encode(midi_ev,
>>>>             buffer,
>>>>             3,
>>>>             &ev);
>>>>   snd_midi_event_free( midi_ev );
>>>>
>>>>   snd_seq_ev_set_source(&ev,midilink->port);
>>>>   snd_seq_ev_set_subs(&ev);
>>>>
>>>>   snd_seq_ev_schedule_tick( &ev, radium_queue, 1, 1);
>>>>
>>>>   snd_seq_event_output(radium_seq, &ev);
>>>>
>>>>   snd_seq_drain_output(radium_seq);
>>>> 
>>>> }
>>>>
>>>> 
>>>
>>> 
>> 
>> 
>
>