Re: Uninterrupted Audio tone generation

> 
> 
> >RTLinux will not allow you to allocate more than 100% CPU - so the simple
> >answer is - if there is any time left between the two audio outputs or if
> >you can allw other tasks to run between two audio samples then the
> user-space
> >process will advance - how much depends on the actuall CPU time left.
> 
> Thanks for your answer.My sampling frequency is 8kHz so i would need to send
> a sample every 0.125 millisecond to the codec. I have no idea how much of
> this will be eaten up in processing my interrupt and actually sending the
> next sample out of the buffer to the audio-card. i read that for my platform
> rtlinux can give me worst case 50-60 microseconds interrupt processing
> latency. so i guess i could ger about 50-60 microseconds between samples.

60 microseconds sounds wrong - don't have a system around that shows such
bad numbers - but off course there is hardware that will do that kind of thing
but then you should switch hardware - on the system I test on I would say you
can reach stable 10us even under heavy load on some systems even less.

Not also that for Linux to survive it is not the worst case that counts, but
the average. The worst case is the criteria for the rt-side to not miss a 
deadline - for linux it is sufficient if there is enough processing time left
on average and if the system has a worst case of 10us then the average will
most likely be around 2-3 us leving enough time for Linux.

On AMD XP 2400+ I have run testcases of 100kHz with about 1 out of 10E7 samples
above 10us and the average being below 1us (scheduling jitter of a task that is
but as this is coupled to the timer interrupt that is also a valid indication
of interrupt latency).

8kHz will be no problem if the execution time of the processing routine is
not excessive - so let it run with the tracer on and you will quickly see if
you are going for troubles or not.

> 
> Would this amount of CPU time allow my data-collection task to run in a
> manner that seems to be continuous? This task needs to read requests from a
> serial port and do some simple rpocessing involving copying of received data
> to several buffers.

I can only speculate as you can naturally toast any system by doing too much
in the ISR/DSR, but the data volume on a serial line is generally not to wild
so from the pure data-volume you should not be in trouble - serial conections
however are not to optimal especially when it comes to interrupt load.

hofrat
_______________________________________________
Rtl mailing list
[email protected]
http://www2.fsmlabs.com/mailman/listinfo/rtl