[alsa-devel] Disabling buffer fill level preprocessing by ALSA

Lennart Poettering mznyfn at 0pointer.de
Tue Jan 8 01:03:02 CET 2008

On Mon, 07.01.08 22:34, James Courtier-Dutton (James at superbug.co.uk) wrote:

> Are you going to be at FOMS. It might be easier to explain to you there.
> You are making assumptions about sound cards that might be wrong. E.g. 
> 2secs hw buffer for instance.

Yes, I will be at FOMS.

I ask for 2s of hw buffer, I take whatever ALSA gives me. If ALSA
cannot fulfil this request I am happy and take whatever I get. 

Also, if clock_getres() tells me that hrtimers are not available, or
when I cannot enable mmap mode for a device, I don't do
system-timer-based scheduling at all, instead I fall back to use a fixed
period size, the way ALSA suggests it.

I am not aware that I make any assumptions of the ALSA API that are not documented, besides:

- That I can fully (as in "what is in the hw buf and still unplayed")
  rewind a playback buffer from the front:0,
  surround40:, surround50:, surround41:, surround51: and surround71:
  devices when I managed to open them in mmap mode.

- That snd_pcm_sw_params_set_stop_threshold(.. , (snd_pcm_uframes_t) -1))
  disables automatic starting of the device.

- That snd_pcm_sw_params_set_start_threshold(.. , (snd_pcm_uframes_t) -1))
  disables automatic stopping on underrun.

- That snd_pcm_sw_params_set_avail_min(.. , INT_MAX) will never mark
  the PCM fd as ready in poll().

- That the mixer device for a device surround51:0 is called hw:0 

Which seem all pretty reasonable to me, and based on comments from
Takashi or Jaroslav on the ML, or by looking into the source code.

What other assumptions do you believe I am making that might be invalid?


Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

More information about the Alsa-devel mailing list