>> > 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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
