snd-emu* doesn't work

[brian_j_murrell]

My pulseaudio 0.9.10 installation has started to stutter quite severely and frequently. I don't see anything interesting in the -vvvv log to indicate why.

What additional information can I provide to help debug why this is?

[lennart]

Which sound card is this? Which driver do you use? Which application are you experiencing these problems with? What distribution are you using?

[brian_j_murrell]

Replying to lennart:

Which sound card is this? Which driver do you use? Which application are you experiencing these problems with? What distribution are you using?

Yes, indeed. Some more googling today and it has become apparent to me that at minimum the sound card is relevant. It's a

04:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)

Just about any sound application seems to be subject to the stutter, but of course, the most of them are quite transient in their nature (such as pidgin, which only chirps [NPI] for a brief moment when messages are sent/received) prevalent in use here is rhythmbox, which I have come to understand uses gstreamer. So for your query, gstreamer is probably the relevant application.

I did all kinds of twiddling with default-fragments and default-fragment-size-msec (which are configured in daemon.conf at 8 and 10 respectively on Ubuntu) but was unable to make things any better.

[lennart]

Sorry, but Creative sund cards are unfortunately not well supported on Linux. Creative is very uncooperative and doesn't supply Free Software developers with documentation. The result of this is that only the most basic support for emu10k is available and a lot of more advanced stuff that PA needs (like accurate timing) is broken/incomplete.

It is well known that PA doesn't work that well on Creative cards. Please blame Creative for that and don't make the mistake to buy Creative again.

[brian_j_murrell]

Replying to lennart:

Sorry, but Creative sund cards are unfortunately not well supported on Linux.

Interesting.

Creative is very uncooperative and doesn't supply Free Software developers with documentation.

I was not aware that Creative were amongst this crowd. Unfortunate.

The result of this is that only the most basic support for emu10k is available and a lot of more advanced stuff that PA needs (like accurate timing) is broken/incomplete.

I'm certainly not doubting you on this, but for the record of this ticket and anyone else who comes across it, why does it work so well with just plain ALSA driving it?

Please blame Creative for that and don't make the mistake to buy Creative again.

Well, I definitely make a point of not buying from companies that engage in these tactics and sound cards are cheap and plentiful, so that probably won't be difficult.

I guess in the meanwhile, I will swap my cards and relegate that EMU10k to being my (viop) headset soundcard driven by ALSA directly and use the:

00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)

as my main audio sound card. Will I have better luck with that device and PA?

[brian_j_murrell]

Replying to brian_j_murrell:

I guess in the meanwhile, I will swap my cards and relegate that EMU10k to being my (viop) headset soundcard driven by ALSA directly and use the: {{{ 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) }}} as my main audio sound card. Will I have better luck with that device and PA?

It seems not. It stutters (almost?) as badly, again with nothing logged on the output of pulseaudio -vvvv. The stuttering seems to correlate with periods of higher CPU activity.

Also it has other problems. Reducing the Output Device volume in the PA Volume Control to 50% or lower completely mutes the sound. :-(

[lennart]

Replying to brian_j_murrell:

I'm certainly not doubting you on this, but for the record of this ticket and anyone else who comes across it, why does it work so well with just plain ALSA driving it?

We schedule audio with timer interrupts, not with sound card interrupts -- which we disable as much as possible. That allows us to variably change the wakeup frequency to match what clients that come and go need. This kind of scheduling requires the sound driver to provide us with correct timing information so that we can properly estimate the wakeup times. This is broken in the emu10k driver which causes PA to miscalculate the wakeup times based on this wrong data and thus missing the deadlines which you can hear as dropouts.

As long as you only play MP3 music directly on the device and use the traditional sound card interrupt based wakeups the bogus timing information the sound drivers export doesn't matter. That's why you won't notice this issue without PA but it becomes very visible (or audible...) when PA is used.

as my main audio sound card. Will I have better luck with that device and PA?

HDA is pretty well supported. Docs are open. A lot of hw has bugs but those can usually be worked around. Usually support for HDA should be pretty good, and if it isn't it is quickly fixed.

[brian_j_murrell]

Just to further update...

It seems pretty good at the moment. I got rid of one application that was spiking the CPU for short periods and it seems much better. The application was "preload". I have been on the fence for a while about whether that application was worth it's cost.

I can't even seem to force stuttering now with something fairly heavy on both disk i/o and CPU such as:

find /usr -type f | xargs md5sum

I'd hate to think this is just working because I am currently still in the "sweet spot". Do you have any pet/particular torture tests you use to test for the sort of problem I am seeing here, even with the HDA controller? My find/md5sum does not seem torturous enough.

[coling]

Lennart. Brian seems to be using 0.9.10 now (in other tickets he was using 0.9.13). What you are describing here is glitch-free stuff AFAICT... (it's a nice description tho', which I'll copy when people ask me :))

[brian_j_murrell]

Replying to coling:

Lennart. Brian seems to be using 0.9.10 now (in other tickets he was using 0.9.13).

Yes, I flirted with 0.9.13 very briefly only to find it didn't solve my stuttering and was generally worse with ALSA underruns and so forth.

What you are describing here is glitch-free stuff AFAICT...

Are you referring to Lennart's description in comment #6?

(it's a nice description tho', which I'll copy when people ask me :))

I did think the description in comment #6 was pretty decent too.

[Quantum]

Replying to brian_j_murrell:

Replying to lennart:

I would also like to confirm this "behaviour" and, also, its annoyancy.

The sound card is:

SB Audigy 2[Unknown] (rev. 4)

which I believe is also run by EMU10k1. Motherboard is Asus A7N8X-E (comes along with nForce2 onboard sound controller).

Distribution is Fedora 10 and Pulseaudio version is 0.9.13.

Sound occasionally and randomly stutters during movie playing or normal MP3 listening, and I remember the sound worked perfectly on ALSA (back on FC6).

Being a novice linux user, I don't know (yet) how to get you any advanced diagnostics, but this is what I found: the sound stutters irrelevantly of the CPU load and re-niceing the process (e.g. VLC player) and/or changing the scheduling algorithms doesn't seem to have any effect.

I have also tried to "deprioritize" PA via Sound System Settings and putting it on the bottom of the sound system stack - also to no effect.

I've tried to remove PA altogether but that just left me with no sound so I installed it right back but the sound remained...'stutterous'.

I am aware that CL is very uncooperative regarding Free Software (a great shame) but is there anything more I could do (besides changing the sound card)? Also, if I can pull any log or any data for you to analyse, please just let me know and I'll get right on it.

If you feel this situation will not be resolved (due to CLs obstinacy) could you please explain how can to 'downgrade' to ALSA (since it seems to be working OK there)?

[coling]

Quantum edit your /etc/pulse/default.pa and add the tsched=1 option to hal-detect module to make pulse use the non-glitch free mode which should work around your CL problem albeit without all the glitch free goodness (which is clearly backfiring right now anyway!!) There are other tickets specifically about this issue and this ticket is not the same issue you are having so it's probably best to look for the correct ticket which concerns creative hardware. Hppe this helps.

[lennart]

Please help tracking this down by following what is written at the end of wiki:BrokenSoundDrivers.