[alsa-devel] MMAP + RTC excellent performance , 2.9ms latency during playback !

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [alsa-devel] MMAP + RTC excellent performance , 2.9ms latency during playback !
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ti maalis 07 2000 - 10:12:02 EST


Good news folks:
The results of my preliminary using ALSA MMAP mode + RTC tests look promising

For the tests I used my Celeron366 + SB Live! card
I am using 512 bytes buffesize at 44100kHz stereo ( 2.9ms buffer)
basically I am donig the following: (for now playback only)

mmap() the buffer into mem

use the RTC device to wake up the app using the blocking read()
the RTC freq is set to 1024 HZ
compute the number of "free" bytes in the 512 byte buffer,
using status.scount.
refill "freebytes" number of bytes into the mmapped buffer.

I get rock-solid behavoiur ( using a lowlatency kernel),
I am recording the time difference between between
two subsequent loops.

The nominal value should is about 1ms ( 1/ 1024HZ)
The upper bound I measured is about 2ms
(is seems that sometime,although very seldom,
an RTC irq gets lost, but that happens during
soundcard blocking writes too).

This is why I am stressing that we must use a higher than
half buffersize granularity.

In this case we use 1/3 buffersize ( 1ms ) granularity and it works
very well.

Look at the latency-diagram:
It was recorded while: (doing all simultaneously of course !)

- copying 500MB file around the disk
- kfract was rendering a fractal
- playing xboing while waiting for the finish of the 2minute test
- XMMS was playing an MP3 on the 2nd channel of the SB Live! (not run
SCHED_FIFO)

Here is the diagram:

http://www.gardena.net/benno/linux/alsa/mmap-rtc-stress.gif

Note that monitoring the CPU usage of the MMAP + RTC audio playing task
shows me a CPU usage of 1.5%. (playing audio from RAM)

Not that big if you consider you have an app which get woken up 1000 times per
second while polling the bufferpointers calling snd_pcm_channel_status().

opinions ?

The next step will be to analyze the fullduplex mode but, I still have many
uncertainities in this field:

- how can I starts playback and capture simultaneously ?
  is there something equivalent to OSS' s
  SNDCTL_DSP_SETTRIGGER : call the ioctl with PCM_ENABLE_OUTPUT |
PCM_ENABLE_INPUT to start both playback and capture

- Is there a guarantee that at least on the same soundcard , capture and
playback will always stay in sync ?

- what is the right procedure of the setup phase when wanting to
use the device in fullduplex mode ?

open playback and capture handle separately ?
(and in the mmap() case mmap() the buffers separately),
 
and use the two handles one for playback , the other for capture.

any advices ( sequence of operations, which ALSA calls to use in which sequence)

Anyway I think good fullduplex userspace code should not assume that playback
and
capture stays in sync , since this would allow to capture from one card while
doing playback on the other card.

I am confused because of these em10k sync problems on the alsa-devel mailing
list.
Is the out-of-sync the exception or the rule ?

PS: please don't ask for my RTC + MMAP code for now because it's PATENTED !
patents are modern these days :-)
just kidding !!
:-)

It's an ugly hack for now, my goals are to
- write some docs how to use high-performance realtime audio under ALSA
(of course with working examples)

- write a new version of latencytest (almost from scratch) which will support
 OSS , ALSA and the benchmarking of timers like RTC and others.

but that will take some time.

Anyway the proof of concept is here, hopefully eliminating any doubt from people
which is still sceptical that linux is not suitable for high-performance audio.

Benno.
------
To unsubscribe from <alsa-devel_AT_alsa-project.org> mailing list send message
'unsubscribe' in the body of message to <alsa-devel-request_AT_alsa-project.org>.
BUG/SMALL PATCH REPORTING SYSTEM: http://www.alsa-project.org/cgi-bin/bugs


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST