Re: [linux-audio-dev] ALSA API

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

Subject: Re: [linux-audio-dev] ALSA API
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 01 2001 - 20:24:02 EEST


>> I can't tell you anything about the Maestro, but I routinely use a
>> period size of 64 frames (1.3ms) on my Hammerfall and Trident cards on
>> a dual PII-400. no dropouts.
>
>The question is, how can you actually the period time that low. I can't
>get alsa to set the period time lower than 5ms. Is that driver dependend
>or does alsa check for a low latency kernel?

its dependent on the h/w. its quite possible that the maestro can't go
that low. the SBLive can't, thats for sure. in ardour, i just
use snd_pcm_hw_params_set_period_size(), and it either works or it
doesn't. the SBLive is the only card I know of so far that doesn't go
down very far.

>> are you running a low-latency kernel? if not, forget going below 10ms.
>> if you are, are your IDE drivers properly tuned? this is a well known
>> problem area for low latency settings.
>
>Hmm, I not running a low latency kernel.

then forget going much below about 100ms on a UP system if you want
total reliability. on an SMP system with a "free" processor, you can
probably get down to 10-20ms or so with the regular kernel, proper disk
drivers, etc.

>> the usual qualifications about the application doing the right thing
>> (no system calls, no blocking calls of any kind) within the audio
>> thread all apply to. i would imagine that GLAME adheres to this, but
>> i don't have any basis for that imagination.
>
>Hmm, glame plugins communicate via sockets, each plugin in a thread.
>So we have some function calls to get buffers to process. But I don't
>see a way circumventing that :) And IMHO function calls take only
>a couple of museconds, so do you really think that's a problem.

functions calls that don't block take only a few microseconds, yes.
but function calls that do block can take hundreds of milliseconds, or
more. just about every POSIX system call has the potential to do this
on a Linux system. why does glame use sockets to communicate with an
in-process plugin (i.e. its in a thread)? or did you mean that they
run in their own process? if so, then you should be carefully
following the thread on LAAGA ...

>BTW: There are heaps of assert calls in the alsa lib, maybe that's
>the problem. But I didn't see a way to compile alsa lib without asserts.
>Do I have to set CFLAGS="-DNDEBUG" by hand?

No idea, sorry.

--p


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

This archive was generated by hypermail 2b28 : Tue May 01 2001 - 20:58:58 EEST