GNOME Bugzilla – Bug 314689
alsasink cracks with some dmix configurations
Last modified: 2006-01-27 14:24:49 UTC
Hi, In some ALSA dmix configurations, alsasink produces cracking sound. Only alsasink behaves as such, other ALSA apps are fine. Changing the ALSA dmix configuration with a newer sample one seems to fix the issue. This looks like a corner case in alsasink. This was reported in Debian by 4-5 persons in Debian bugs http://bugs.debian.org/323447 and http://bugs.debian.org/324163. These people have the problem on multiple machines, with very different audio hardware. Here's a sample problematic asoundrc: pcm.!default { type plug slave.pcm "dmixer" } ctl.!default { type plug slave.ctl "dmixer" } pcm.dmixer { type dmix ipc_key 1024 slave { pcm "hw:0,0" period_time 0 period_size 1024 buffer_size 4096 rate 44100 } bindings { 0 0 1 1 } } ctl.dmixer { type hw card 0 } Bye, Bye,
I've heard reports that increasing the period-size fixes this.
The default seems to be GST_ALSA_MAX_PERIOD_SZ, ie. 8192 the maximum, you mean increasing the maximum? To what order? (I don't reproduce, so I have no idea what makes sense here.)
[..] slave { pcm "hw:0,0" period_time 0 period_size 1024 <---------------------- buffer_size 4096 rate 44100 } [..]
Didn't solve my problems with the "stuttering rhythmbox". Downgrading to gst-plugins-alsa-0.8.8 worked tho'. A few Gentoo users are having this problem also: http://forums.gentoo.org/viewtopic-t-347016-highlight-gstreamer+sound.html
Another borken configuration (which doesn't set period_size at all): ####### pcm.snd_card { type hw card 0 } pcm.snd_dummy { type hw card 1 } ####### pcm.dmixed_card { ipc_key 1024 type dmix slave.pcm "snd_card" } pcm.dsnooped_card { ipc_key 2048 type dsnoop slave.pcm "snd_card" } pcm.dmixed_dummy { ipc_key 4096 type dmix slave.pcm "snd_dummy" } pcm.dsnooped_dummy { ipc_key 8192 type dsnoop slave.pcm "snd_dummy" } ####### pcm.asymed_card { type asym playback.pcm "dmixed_card" capture.pcm "dsnooped_card" } pcm.asymed_dummy { type asym playback.pcm "dmixed_dummy" capture.pcm "dsnooped_dummy" } ####### pcm.dsp0 { type plug slave.pcm "asymed_card" } pcm.dsp1 { type plug slave.pcm "asymed_dummy" } ctl.mixer0 { type hw card 0 } ctl.mixer1 { type hw card 1 } ####### pcm.multi { type multi slaves.a.pcm "asymed_card" slaves.a.channels 2 slaves.b.pcm "asymed_dummy" slaves.b.channels 2 bindings.0.slave a bindings.0.channel 0 bindings.1.slave a bindings.1.channel 1 bindings.2.slave b bindings.2.channel 0 bindings.3.slave b bindings.3.channel 1 } pcm.!default { type plug slave.pcm "asymed_card" }
Also having this problem. The only fix I've found so far is downgrading gst-plugins to 0.8.8 A fix would be nice. :)
Have a look at bug 315121. Using the default dmix conf block usually helps. Cheers,
I have the same problem unless I pass period-size=1024 to the alsasink plugin, which corresponds to my dmix configuration. Couldn't alsasink determine the period size from the playback PCM device?
This might hack been fixed with the recent changes on bug #315121. Can anyone try this with current 0.8 CVS and see if there are still issues?
On Debian side, with all CVS fixes for alsa and dmix, every submitter with a recent ALSA and the default config was happy. (However, I think that the problem can surface in non-default configs, but I believe it's either a configuration problem or an ALSA bug.)
Closing as fixed, milestone 0.8.12. Please reopen if the bug persists.