[alsa-devel] usleep() and nanosleep() timings seem inaccurate using ALSA

[Carlo Florendo]

Takashi Iwai wrote:
> At Fri, 30 Mar 2007 09:53:33 +0800,
> Carlo Florendo wrote:
>> Takashi Iwai wrote:
>>> At Thu, 29 Mar 2007 17:46:38 +0800,
>>> Carlo Florendo wrote:
>>>> Good Day!
>>>>
>>>> After studying the intricacies of MIDI, I ended up writing an 
>>>> implementation of the MIDI protocol and file format.
>>>>
>>>> I then studied the ALSA sequencer API to be able to control a synthesizer 
>>>> keyboard and play MIDI files.  I've used aplaymidi, aconnect, arecordmidi, 
>>>> and all those great ALSA utilities.  They're very good!
>>>>
>>>> However, I wanted to have a simple ncurses based, command line MIDI 
>>>> sequencer meant for small Linux distributions such as DSL or Trustix so I 
>>>> began to write a command line sequencer using ALSA.  I've encountered one 
>>>> problem about using usleep() and nanosleep() especially in 2.4 kernels.
>>> You cannot get a small sleep usually on user-space processes.
>>> Usually, usleep() is implemented with select/poll and its timeslice is
>>> defined by HZ in kernel config.  In most cases, it's HZ=100, 250 or
>>> 1000 while 2.4-i386 kernel supports only HZ=100.  That is, the least
>>> sleep time is 10ms no matter what value you pass to usleep().
>>>
>>> This can be overcome by using a realtime schedule class and priority
>>> like JACK does.
>> Ok. I will take that seriously.  I've heard about JACK and know it's 
>> popular but I've never used it.
> 
> Well, I don't mean JACK handles the MIDI in that way but as an example
> of real-time (audio) application.  Basically you have to just set
> process scehduler class to SCHED_FIFO and raise the priority.  Then
> your process would get invoked as soon as triggered, such as return
> from poll() events.
> 
>> In any case, how does aplaymidi (or even timidity) produce the proper 
>> timings using ALSA?  (In other words, how does the queue output sounds with 
>> correct timings?)
> 
> The ALSA sequencer queue is implemented on kernel, so it can have and
> use more accurate timer sources.
> 

Clear enough :)  Thanks for the pointers.

Best Regards,

Carlo



-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp