ALSA Loops Data Buffer Instead of Pausing


Recommended Posts

It's been a little while since I've posted, but I haven't been able to find a solution to this problem, and I look forward to any help you can provide!

Basically, whenever I'm sending a digital stream to my receiver (works perfectly with analogue streams), pressing pause causes a very loud clicking, which I've surmised to be ALSA not stopping the DMA engine when the output is told to pause.

I'm running Ubuntu Hardy, with kernel 2.6.24. My hardware is i686 based, and my sound card is a Turtle Beach Santa Cruz, which uses the Cirrus Logic CS4624 chip. I'm playing DVD disc images in .iso format from the local hard drive with XBMC's internal DVD player, and I've tested ac3 files with mplayer and the exact same bug occurs.

Has anyone ever had an audio bug that only occurs when something is paused? Once I press play on whatever software I'm testing, the sound resumes with perfect clarity. If I close the software, my system stops sending a signal to the receiver and there's silence.

I found this thread (http://www.nabble.com/looping-S-PDIF-data-td17573493.html) which details the same problem for another card. However, the patch listed there is for a different sound card, and I'm not at the skill level where I can simply figure out how to make a patch for mine. Thanks for any help!

Link to comment
Share on other sites

I tried to educate myself to Linux audio, so I could post some direction based on what I could surmise.

I read partway into this:

http://www.linux.com/feature/119926

then my brain started to hurt. :(

Maybe you can look into that and understand better what alternative modules to try than I could surmise.

But I think that Hardy uses Pulse Audio, which is fairly new to Linux (Hardy, I think, is the first *buntu release to include it). You might try removing Pulse Audio, or using an older version of Ubuntu (perhaps just as a LiveCD) to troubleshoot if the problem still exists without Pulse Audio?

Link to comment
Share on other sites

Thanks for that link, the information there is very clear. My next step was to try uninstalling/reinstalling things, but I was hoping to fix the problem with minimal changes.

The simplest option appears to be the patch I linked to (I'll reproduce it below).

diff --git a/sound/pci/trident/trident_main.c b/sound/pci/trident/trident_main.c
index bbcee2c..a69b420 100644
--- a/sound/pci/trident/trident_main.c
+++ b/sound/pci/trident/trident_main.c
@@ -1590,7 +1590,10 @@ static int snd_trident_trigger(struct snd_pcm_substream *substream,
		if (spdif_flag) {
				if (trident->device != TRIDENT_DEVICE_ID_SI7018) {
						outl(trident->spdif_pcm_bits, TRID_REG(trident, NX_SPCSTATUS));
-					   outb(trident->spdif_pcm_ctrl, TRID_REG(trident, NX_SPCTRL_SPCSO + 3));
+					   val = trident->spdif_pcm_ctrl;
+					   if (!go)
+							   val &= ~(0x28);
+					   outb(val, TRID_REG(trident, NX_SPCTRL_SPCSO + 3));
				} else {
						outl(trident->spdif_pcm_bits, TRID_REG(trident, SI_SPDIF_CS));
						val = inl(TRID_REG(trident, SI_SERIAL_INTF_CTRL)) | SPDIF_EN;

This patch does exactly what I need, but is for the Trident sound driver, not the cs46xx driver. If somebody knows how I can make this affect a different driver, I would be forever grateful!

Edited by T-Grey
Link to comment
Share on other sites

I just tested ac3 output after booting from the LiveCD, and the problem remains the same. I'm going to file a bug with ALSA's bugtracker, but hopefully some Neowin h4><0r will be able to assist.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.