2009/12/10 pl bossart bossart.nospam@gmail.com
- why PA use snd_pcm_hw_params_get_buffer_size_max() instead of
snd_pcm_hw_params_get_buffer_size() after snd_pcm_hw_params() ?
Precisely to use the maximum preallocated buffer size.
The driver only allocate 8K bytes for the substream when the application request 2 fragments and 64 Kbytes when the application request 16 fragments
It is wrong for PA to think that 371ms is the buffer size on pulseaudio 0.9.21
If the user select 8 fragements in deamon.conf , the pulseaudio-0.9.21 still calculated the wrong buffer time and wakeup time.
Do you know what is PA 's "hwbuf_unused_frames" ?
/* hw_params callback */ static int snd_vortex_pcm_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *hw_params) { vortex_t *chip = snd_pcm_substream_chip(substream); stream_t *stream = (stream_t *) (substream->runtime->private_data); int err;
// Alloc buffer memory. err = snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params));
I: module-alsa-sink.c: Using 2 fragments of size 4096 bytes, buffer time
is
46.44ms D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024
With small buffers like this, I don't see the point of the timer-based scheduling, you will have one interrupt every 23ms.
au8810, au8820 and au8830 were designed for those 3D sound game (low latency) and support multiple DMA connections (i.e. hardware mixing ) , they does not need any sound server (software mixing) at all.
- it seem bug in snd_pcm_sw_params_set_avail_min() since 4661 is larger
than the buffer size 2048 since PA still think that 371ms is the maximum buffer size
D: alsa-util.c: buffer_size : 2048 D: alsa-util.c: period_size : 1024 D: alsa-util.c: period_time : 23219 D: alsa-util.c: tstamp_mode : NONE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 4661
This doesn't make sense. But avail_min isn't really used with the timer-based scheduling
Are you sure ?
For pulseaudio-0.9.14 on Fedora 10
Man, you are using an old version here, the alsa sink code was changed several times already.
PA 0.9.14 run quite well with my au8830 with 2 fragements on Fedora 10 but PA 0.9.19 run badly on hypersonic 's au8830 on Karmic
It seem to be regression of PA
The possible reasons may be
1) PA 's 20ms process time may not enough for hyper_sonic 's CPU ( ICH2 or ICH4 since he is using intelx8x0) and I am a faster CPU since my motherboard is using HDA ( ICH8)
2) PA may only handle 1 or 2 periods or use the wrong buffer size in calculating the watermark
3) snd_pcm_rewindable() is returning a wrong value since au88x0 has FIFO buffer as described in the patent )
http://0pointer.de/blog/projects/pulse-glitch-free.html
The rewriting of the client buffers causing rewriting of the hardware buffer complicates the resampling/converting step immensly. In general the code to implement this model is more complex than for the traditional model. Also, ALSA has not really been designed with this design in mind, which makes some things very hard to get right and suboptimal.
The transfer of the audio data (48000Hz) only occur at ac97 link between AC97 codec and AC97 controller. The AC97 controller fetch audio from memory at the rate of PCI bus instead of the sampling rate of the audio. Therefore rewind the application pointer to hardware pointer and immediate rewrite is almost impossible
4) the default fragments in daemon.conf seem oboselte in PA 0.9.21 but there is no proper documentation