Very Computer

Hi all,

we are developing an application wich communicates
trough the Serial Port of the PC with an Cardreader-
Device.
It is important that we receive every byte as soon as it
arrives, but actualy Linux seems to buffer the stream from
the serial port and delivers a set of 10-16 Bytes instead
of single Bytes REQUESTED by the Programm.
We have tried the same on an older version of Suse Linux
(5.x) and it worked great. But on Red Hat 7.2 there is no
way to get the received bytes one by one.

Has anybody an Idea how to get arround this ?

Thanx
Andreas Jakob

There are two sources of the latency you observed.  

 1) The low level serial driver itself.  Try setting the low-latency flag
    using setserial or ioctl() will eliminate that.

 2) The receive FIFOs on the UARTs.  I'm not aware of any way to disable the
    FIFO without hacking on the driver.  You could try using setserial to tell
    the driver to treat the UART as a 16450.

--
Grant Edwards

[...]

Quote:> It is important that we receive every byte as soon as it
> arrives, but actualy Linux seems to buffer the stream from
> the serial port and delivers a set of 10-16 Bytes instead
> of single Bytes REQUESTED by the Programm.

[...]

Hello Andreas,

- The UART's FIFO will buffer a few characters. But there is a
  timeout (4 character lenghts IIRC), so this is probably not
  your problem.
- The serial driver buffers up to a few kilobytes until the next
  timer tick to avoid lots of context switches. If you are talking
  about delays in the range of a few milliseconds, this might be
  your problem. AFAIK you can solve it with setserial (low_latency
  option).
- The termios interface has lots of options. I assume you use
  non-canonical read. Be sure to set VMIN to 1 (man termios).

And please don't multipost.

HTH,
Peter

Quote:> I need to develop a real time audio signal processing application.

What exactly should it do? Read samples from the sound card,
lowpass-pass filter them or so and play them again? With what latency
should that happen? Also consider that sound cards have a small buffer
on the card itself (10 ms or so?).

Quote:> I'm trying to get clear about the os I should use for this. As far
> as I know I should be looking for an os that some how guarantees the
> time intervals between events.

What do you mean by "events"?

Quote:> My software must record/process/play audio samples from several
> channels at 48kHz rate. I already know that windows does not
> guarantee the time intervals so I am thinking about other os. Is all
> this possible under linux?

With Linux's so-called realtime scheduler (man sched_setscheduler),
you should get latencies less than 10 ms in 99.9% of all cases or
so. Typically, latencies are even less than 1 ms. But all that depends
on the kernel (look for "low latency patch" and "preemptive kernel" to
improve latency), the hardware and your load (disk access, network
access). So you have to try it out for yourself and see whether it
fits your needs.

Caveats:
- Linux does not _guarantee_ any latency.
  So you need much testing and recovery from overflow/underflow in the
  very seldom cases it happens.
- Scheduling granularity is 10 ms in kernel 2.4.x, e.g. nanosleep(15ms)
  awakens the process 15-20 ms after it's called. There is a patch to
  improve scheduling granularity to 1 ms (or better, if you want to
  experiment).

There are realtime extensions for Linux, but I have never tried one.

Quote:> The hardware I have is a professional multichannel sound card of
> 24bits and 96kHz sample rate.

Is there a driver for linux?
Does it work with full duplex?
Does it work properly?

Moritz

--
Dipl.-Phys. Moritz Franosch
http://Franosch.org