start_threshold having no effect

start_threshold having no effect

[Johan Bilien]

Hi,

I am trying to build an application using ALSA, and which requires low
playback delays.

My first idea was to have a small hardware buffer to limit the playout
delays. But then if for some reason the buffer gets full, the card stops,
and the next writei will block for about one second.

My second idea was to have a rather big hw buffer (500ms), and then set
the start_threshold to a low value (32 frames for instance). But whatever
my parameters were, I always got a playout delay of about the hw buffer
size.

I think the best way is the second one, but I can't figure out what I
did wrong. Here are the parameters I'm using:

20/10 18:56 /proc/asound/card0/pcm0p/sub0% cat hw_params 
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 1
rate: 8000 (8000/1)
period_size: 32
buffer_size: 4000
tick_time: 1000

20/10 19:12 /proc/asound/card0/pcm0p/sub0% cat sw_params 
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 16
xfer_align: 32
start_threshold: 32
stop_threshold: 4000
silence_threshold: 0
silence_size: 0
boundary: 2097152000

I am using a 2.6.0-test3 kernel (preemptive) with the 0.9.6 libasound.
My soundcard is a USB Plantronics Headset. The card is open both in
PLAYBACK and CAPTURE mode.

Thanks,
-- 
Jobi


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: start_threshold having no effect

[Paul Davis]

>My second idea was to have a rather big hw buffer (500ms), and then set
>the start_threshold to a low value (32 frames for instance). But whatever
>my parameters were, I always got a playout delay of about the hw buffer
>size.

the output latency is always roughly the size of the hardware
buffer. there is no way to avoid this. the best you could ever do
would be one period, where there are two periods per buffer (i.e half
the buffer size). when i say "the best you could do", the truth is
that you probably can't do it. the very first sample you deliver to
the hardware will have a delay of 1 period, each subsequent sample has
a steadily increasing delay all the way up to the last sample, which
is delayed by the length of the entire hardware buffer (2
periods). this assumes that delivery is basically instaneous:
obviously, if you take time to deliver it, the delay drops, but the
total delay (from when you could have written to when the sound is
audible) is the same.

i don't know what you're doing, but you might to investigate JACK,
which does precisely what you're hoping for, supports the lowest
latencies of any supported hardware (with an appropriate kernel), but
also bundles it all up in an easy to use API. jackit.sf.net. 
if nothing else, you can study JACK's ALSA code to see how it does
it. its not simple.

--p


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: start_threshold having no effect

[Johan Bilien]

On Mon, Oct 20, 2003, Paul Davis wrote:
> the output latency is always roughly the size of the hardware
> buffer. there is no way to avoid this. the best you could ever do
> would be one period, where there are two periods per buffer (i.e half
> the buffer size). when i say "the best you could do", the truth is
> that you probably can't do it. the very first sample you deliver to
> the hardware will have a delay of 1 period, each subsequent sample has
> a steadily increasing delay all the way up to the last sample, which
> is delayed by the length of the entire hardware buffer (2
> periods). this assumes that delivery is basically instaneous:
> obviously, if you take time to deliver it, the delay drops, but the
> total delay (from when you could have written to when the sound is
> audible) is the same.

I am working on a voice over IP application. We would like delays from
the write to soundcard to the actual playout lower than 50ms. Do you
think it is impossible with ALSA ? With OSS free the delay we got were
quite good, without any tweaking. But ALSA is said to have better
support for full-duplex.

Maybe using a small buffer on the sound card should then be a better
solution ? I tried with a buffer of 50 ms, and the playout is fine until
for some reason the buffer gets full. At that point I get an EPIPE error
on the next write, I then do a snd_pcm_prepare, can write again, but
after that both reading and writing give a lot of errors, and after a
very short while a write will block for more than one second. Are those
ALSA related problems, or hardware ones ?

Thanks,
-- 
Jobi
Please excuse me for the dupplicate previous e-mail


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: start_threshold having no effect

[Jaroslav Kysela]

On Tue, 21 Oct 2003, Johan Bilien wrote:

> On Mon, Oct 20, 2003, Paul Davis wrote:
> > the output latency is always roughly the size of the hardware
> > buffer. there is no way to avoid this. the best you could ever do
> > would be one period, where there are two periods per buffer (i.e half
> > the buffer size). when i say "the best you could do", the truth is
> > that you probably can't do it. the very first sample you deliver to
> > the hardware will have a delay of 1 period, each subsequent sample has
> > a steadily increasing delay all the way up to the last sample, which
> > is delayed by the length of the entire hardware buffer (2
> > periods). this assumes that delivery is basically instaneous:
> > obviously, if you take time to deliver it, the delay drops, but the
> > total delay (from when you could have written to when the sound is
> > audible) is the same.
>
> I am working on a voice over IP application. We would like delays from
> the write to soundcard to the actual playout lower than 50ms. Do you
> think it is impossible with ALSA ? With OSS free the delay we got were
> quite good, without any tweaking. But ALSA is said to have better
> support for full-duplex.

Comparing to OSS: OSS does not have any xrun detection (overrun/underrun).

> Maybe using a small buffer on the sound card should then be a better
> solution ? I tried with a buffer of 50 ms, and the playout is fine until
> for some reason the buffer gets full. At that point I get an EPIPE error

If you get EPIPE error, then the buffer is empty and you've reached an
underrun.

> on the next write, I then do a snd_pcm_prepare, can write again, but
> after that both reading and writing give a lot of errors, and after a

Sure. You need to resync here for full duplex. At this point, you have
much more data captured than played, so you need to flush also the capture
buffer.

> very short while a write will block for more than one second. Are those
> ALSA related problems, or hardware ones ?

You said that you're using an USB device. It might be a problem with our
USB driver. Also, USB devices are working with 1ms periods at the physical
level, so transferring 32 frames does not make probably sense anyway.

For a voice IP applications, it probably make sense to work without over
and underrun detection (yes, if CPU is busy, there will be some scratches,
but you'll avoid resyncing). Simply set stop_threshold to boundary for
the no-xrun detection.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: start_threshold having no effect

[Takashi Iwai]

At Tue, 21 Oct 2003 13:32:10 +0200 (CEST),
Jaroslav wrote:
> 
> > very short while a write will block for more than one second. Are those
> > ALSA related problems, or hardware ones ?
> 
> You said that you're using an USB device. It might be a problem with our
> USB driver. Also, USB devices are working with 1ms periods at the physical
> level, so transferring 32 frames does not make probably sense anyway.

this should be ok, since the sample rate is 8k Hz (although
RT-scheduling would be needed for 4ms periods.)

but 1ms period alignment is important:  if you want a RT process with
the USB audio device, choose the sample rate with multiple of 1000.
for example, avoid 44.1kHz, but use 48k instead.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: start_threshold having no effect

[Johan Bilien]

On Tue, Oct 21, 2003, Jaroslav Kysela wrote:
> For a voice IP applications, it probably make sense to work without over
> and underrun detection (yes, if CPU is busy, there will be some scratches,
> but you'll avoid resyncing). Simply set stop_threshold to boundary for
> the no-xrun detection.

Thanks a lot, I did this and was then able to run the application with
delays of about 10 ms.

-- 
Jobi


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: start_threshold having no effect

[Paul Davis]

>I am working on a voice over IP application. We would like delays from
>the write to soundcard to the actual playout lower than 50ms. Do you
>think it is impossible with ALSA ? With OSS free the delay we got were
>quite good, without any tweaking. But ALSA is said to have better
>support for full-duplex.

JACK routinely works with 5ms latency on low latency kernels, and 20ms
on regular kernels. its easy, as long as you understand how to write
software correctly.

>Maybe using a small buffer on the sound card should then be a better
>solution ? I tried with a buffer of 50 ms, and the playout is fine until
>for some reason the buffer gets full. At that point I get an EPIPE error
>on the next write, I then do a snd_pcm_prepare, can write again, but
>after that both reading and writing give a lot of errors, and after a
>very short while a write will block for more than one second. Are those
>ALSA related problems, or hardware ones ?

OSS has *NO* xrun detection. ALSA has it, and its turned on by
default. you need to set the stop threshold to -1, so that ALSA never
stops for xruns and never reports them. 

But please note: if you get EPIPE, it means there was an xrun, which
in turn means that your application was *not keeping up with the audio
interface*. you will normally never know this under OSS, whereas ALSA
offers you the chance to find out.


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54