>This is my personal preference. In this model the only service ALSA has to
>supply are:
>
>1. initial configuration/start/stop.
>2. mmapable DMA buffer
>3. fact and precise ioctl telling the current HW pointer in the buffer. If the
>card is not queried each time, then the "last period interrupt" timestamp
>should be included.
ALSA supplies all 3 of these. You can use them by themselves without
the rest of the API if you want. The only problem arises with hardware
that cannot give you accurate h/w pointer positions.
>Please stop the complication of "available/delay" etc. Just the raw
>pointer. Each application knows where its application pointer is, so
>it can easily calculate delay/available and decide for itself whether
>there was an overrun or not.
actually, it can't. if the user space application is delayed for
precisely 1 buffer's worth of data, it will see the pointer at what
appears to the the right place and believe that no xrun has
occured. the only way around this is to provide either:
* h/w pointer position as a steadily incrementing value
* h/w pointer position *plus* interrupt count
i favor the latter since it provides for a longer time before wrapping
becomes an issue (ULONG_MAX interrupts).
>Each application/thread should not just copy the data to DMA buffer, but _add_
>to it - in this way we get very efficient mixing (zero copy). Of course here I
>assume that "add" operations on volatile buffers are atomic vs. context
>switches - probably not on all architectures - we may need mutexes.
they are not atomic on any architecture that i know of.
>I was able to achieve about 20 ms delay (analog-to-analog) when
>transmitting 10 ms RTP packets of data over the LAN with no
>overruns! OK, I have used HZ=2000 and low latency patches+soft RT.
for the record, i've used this approach (inspired by someone from
poland whose name i forget) with an ISA card (no PCI burst size
issues) to achieve <10 sample processing latency. i scribbled a
special bit pattern into the hardware buffer, then looped over it
watching to see where the audio interface was and writing/reading data
directly ahead of it or behind it. it works, but of course it burns
CPU cycles like crazy (there is no wait for the device or anything
else, its just a continuous while loop).
>Callbacks are not the most efficient there. If the data arrives 1 ms
>too late I would loose the whole 10 ms period. If I still add it to
>the buffer, I will loose only 1 ms and the card will play the
>remaining 9 ms of sound.
this isn't a function of callbacks. its a function of the response of
the callback system to the delay. if the system notices that its
running late but goes ahead and executes anyway, the results are just
the same as you suggest for your approach. however, since there is
still a glitch in the audio stream (1ms of data is repeated/lost), a
system like JACK considers this an error.
--p
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
