Hi,
I’d like to develope an application which generate NICAM sound, for this reason I need a tick size timer of 31microseconds.
The problem is that smallest timer I can set in QNX is 500microseconds 
.
Do you know if there is a possibility to set a smallest tick?
Thanks a lot;
Albert(Spain)
That is a very harsh way to do it. One normally would use some sort of hardware buffering that handles the PCM output. Your code then refills the buffer at a more leisurely pace. Not only do you get to do the processing in blocks but the output is far more stable. Even on a fast PC you can expect several microseconds of jitter in executing an ISR.
But, if you really need to set a higher rate, QNX 6.2.0 and above support clocktick sizes right down to 10 usecs.
Fist of all thanks for the reply.
I known it’s not the best way making a periodic task that is activated every 31usec, but it’s required by the specification of my problem becouse I’ve to use a DAC(and sometimes pc-speaker) without buffer.
I spect use sound blaster in a future.
I’d try use qnx_ticksize() with 31usec today, but do you know if a speedy CPU is required?
(Now I’m using and old Piii-450)
Thanks for the answers.
umm, ClockPeriod() is the function to call. Are you using QNX 4.x?
I’m using QNX 6.2.1.
Now the issue is if use clockperiod() as you mention or qnx_ticksize(). I don’t know which function let me reach 31usecs.
Where did you read QNX 6.2 tick could set less than 500usec? I loocked for it and I didn’t find any documentation.
qnx_ticksize() is not a listed in the help docs. The ClockPeriod() documentation lists the fastest setting.
31us will required a very fast machine, what you might want to look at possibly using SMP machine and have the programing handling the 31us stuff do busy loop. Machine will go from handling 100 interrupts a seconds (tick size at 10ms) to 32500 interrupt a seconds (31ms). And there will DEFINITIVELY be LOTS of jitters,
I have generated NICAM sound (31usecs) with RTlinux on a pentium133Mhz. I see QNX has a heaviest kernel and it could not work as fast as RTlinux.
Despite this problem I’ll carry on trying it (it’s part of my end degree project).
Other possibility is reduce sound quality to 8Khz=>125usec.
I’ll comment how it works
That not really because of kernel. From what I know of RTLinux it runs below everything else (or at higher priority if you will). Hence RTLinux will for example run it’s own stuff at higher priority then interrupt for networking or disk. Whatever the kernel, 32500 interrupts per second is high and is an extremly “expensive” way of generating sound.
If your really want to test the performance of the kernel set ticksize to 31us, run your sound program, then run another program that will act as benchmark. My guess is under QNX, that benchmark program will run faster then under Linux.
One of the way to reduce/eleminate the jitter would be to set the timer interrupt to be the highest but unfortunately that can’t be done unless you rebuild the startup code. (I’m guessing RTLinux does that by default)
Not using the system timer will help too. The RTC can generate 8192 Hz on IRQ#8.