[alsa-devel] Questions regarding workaround for VMware

[Bankim Bhavsar]

>> > The problem is that the irq timing emulated on vmware isn't always
>> > accurate.  The sound hardware is supposed to issue an irq at the
>> > programmed buffer period.  On VMware, this irq generation seems to be
>> > done based on the system timer (or alike), thus it's not generated
>> > at the accurate timing that the hardware should give.

For Linux guests virtual sound device generated 50 interrupts per sec.
This was leading to hw_ptr_base re-calculation in
snd_pcm_update_hw_ptr_interrupt() on every interrupt
after this commit
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=ed3da3d9a0ef13c6fe1414ec73c9c1be12747b62

We are fixing our sound card emulation for Linux guest OSes such that
interrupts are generated
at programmed buffer period. This helps improve playback quality with
2.6.31rc9+ kernels.

Thanks for the pointers, Takashi!

On a side-note there seems to be some change in PulseAudio bring
shipped with Ubuntu 9.10 over 9.04 that affects sound playback
quality.
With PulseAudio in 9.10, programmed DMA buffer is 64k and num_periods
is always 1 and thereby number of interrupts generated per sec is just
2 for 16-bit, 44Khz, stereo.
IMO the number interrupts is too low and this leads to under-runs.
Whats the reason for choosing always 1 period and having large
buffer/period size (power-savings?)?

If I disable PulseAudio in 9.10,  programmed DMA buffer is 64k with 16
periods each of size 4k and virtual sound device would generate 46-48
interrupts per sec. With this setting sound playback quality is good.

--Bankim.