[CM] Fwd: Linux/Midi Test

William Andrew Burnson burnson2 at illinois.edu
Tue Aug 11 11:27:44 PDT 2009


I can confirm this, it does work! I'm using VirtualBox Ubuntu, and even still, swapping for those two lines does suddenly get rid of all jitter. It's rock solid as lieven says. I don't think process priority should be changed either as this isn't really a threading issue.

I will post this on the JUCE forum to let Jules know. In the meantime, if it's possible Rick, then the best approach would be to use sendMessageNow for all MIDI out and hack line 46989 in juce_amalgamated.cpp and change from:

snd_seq_event_output_direct(seqHandle, &event);

to

snd_seq_event_output (seqHandle, &event);
snd_seq_drain_output (seqHandle);


---- Original message ----
>Date: Tue, 11 Aug 2009 20:04:30 +0200
>From: lieven moors <lievenmoors at gmail.com>  
>Subject: Re: [CM] Fwd: Linux/Midi Test  
>To: "Kjetil S. Matheussen" <k.s.matheussen at notam02.no>, Heinrich Taube <taube at uiuc.edu>
>Cc: Andrew Burnson <burnson2 at uiuc.edu>, cmdist at ccrma.stanford.edu
>
>I'm sorry to confuse you, but when I said that timing sounded rock solid,
>I had forgotten that I had edited the juce_amalgamated.cpp file.
>When I reverted to the original version, the timing sounded worse again.
>
>I had edited the sendMessageNow funtion:
>
>changed
>
>    snd_seq_event_output_direct(seqHandle, &event);
>
>into
>    snd_seq_event_output (seqHandle, &event);
>    snd_seq_drain_output (seqHandle);
>
>Could somebody check this?
>
>
>Kjetil S. Matheussen wrote:
>>
>> 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);
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>



More information about the Cmdist mailing list