Bug 505953 - Microphone input in Mumble is severely choppy
Microphone input in Mumble is severely choppy
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mumble (Show other bugs)
11
All Linux
low Severity high
: ---
: ---
Assigned To: Igor Jurišković
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-14 19:02 EDT by Casey Bennett
Modified: 2010-11-14 23:07 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 09:00:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Casey Bennett 2009-06-14 19:02:16 EDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b4) Gecko/20090427 Fedora/3.5-0.20.beta4.fc11 Firefox/3.5b4

Microphone input in Mumble seems to be polling at roughly a rate of 1 Hz--far too slowly to be coherent. However, opening a mic capture program and hitting "Record" causes Mumble to get the mic data at a normal rate.

Reproducible: Always

Steps to Reproduce:
1. Plug in microphone and open Mumble
2. Cancel the server connect window and go to Settings > Audio Wizard
3. Set the options on the device settings screen to what is appropriate; on my system, it's PulseAudio and the default input and output.
4. Go forward two screens to Device Tuning; while on this screen, Mumble pipes the mic to the speakers.
5. Speak into the mic; observe the choppy sound.
6. Open a mic capture program (I've tested this on gnome-sound-recorder and Audacity) and press "Record" in it.
7. Speak into the mic again.
Actual Results:  
At step 5, while Mumble is piping its mic input to the speakers, its output is choppy and incoherent. At step 7, it's normal.

Expected Results:  
Mumble's output should be normal regardless of if other programs are recording the mic input or not.

Using mumble-1.1.8-13.fc11. Both the x86_64 version on an x86_64 system, and the i586 version on an i586 system exhibit the same behavior.
Comment 1 Ville-Pekka Vainio 2009-06-18 10:21:07 EDT
I can confirm this problem, I've managed to "fix" it by keeping GNOME's Sound Preferences window open while using Mumble.
Comment 2 Igor Jurišković 2009-06-22 07:01:53 EDT
This problem only appears in pulseaudio above 0.9.10. Same thing appears on Gentoo with pulseaudio above 0.9.10. Can any of you confirm this?

Looks like pulseaudio bug.
Comment 3 Ville-Pekka Vainio 2009-07-03 14:08:39 EDT
I've assigned this bug to pulseaudio in hopes that some pulseaudio developer could comment on the issue.
Comment 4 Michael Wiktowy 2009-07-13 13:32:39 EDT
I see this also.

You can also see the effect by switching the Configuration interface to Expert in the User Interface tab, Switching to a Local Loopback test in the Audio Output tab and then opening up the Gnome Sound Preferences. The loopback test won't work until you open up GSP. Then the VU meter becomes active and you can hear the loopback through the speakers.
Comment 5 Michael Scherer 2009-08-05 17:38:16 EDT
Just for the record, this is also seen on mandriva 2009.1.
Comment 6 Lennart Poettering 2009-08-19 11:23:06 EDT
The pa backend for mumble is very racy and lacks any kind of proper locking. Reassigning to mumble.

(Also it never does any kind of error checking. Evil)
Comment 7 Thorvald Natvig 2009-08-30 20:38:09 EDT
Pre-0.9.11 Pulse, you could request a low latency buffer by setting fragsize to your desired "chunk" size, and maxlength to the maximum latency you desired.

0.9.11 introduced PA_STREAM_ADJUST_LATENCY, and without this flag, the latency of the source is not adjusted. Sometime post-0.9.10,  the aforementioned buffer settings became interpreted as "every 2 seconds, send me maxlength data". In practice, this means every 2 seconds, 160ms of audio is received, and the rest is thrown away.

If you start the VU meter, that does adjust the source latency, and hence things work again.

As I understand it, Pulse doesn't have a frozen API yet, so things like this is to be expected from time to time. I wish it was slightly better at backward compatibility, but I don't really expect that until a post-1.0.0 release.

Current git of mumble has the above change. It makes it incompatible with pre-0.9.11 Pulse, but I don't think any current distribution is using that old a version. I recommend you simply pull the relevant changeset from git, which is what we did for Debian/Ubuntu.
Comment 8 Lennart Poettering 2009-08-31 14:11:25 EDT
(In reply to comment #7)
> Pre-0.9.11 Pulse, you could request a low latency buffer by setting fragsize to
> your desired "chunk" size, and maxlength to the maximum latency you desired.

That is not true. The fragsize should be the latency. And maxlength is mostly a security/resource limit feature which does not (and never did) influence the latency.

> 0.9.11 introduced PA_STREAM_ADJUST_LATENCY, and without this flag, the latency
> of the source is not adjusted. Sometime post-0.9.10,  the aforementioned buffer
> settings became interpreted as "every 2 seconds, send me maxlength data". In
> practice, this means every 2 seconds, 160ms of audio is received, and the rest
> is thrown away.

That is a misconception. In versions before .11 the latency was never adjusted on client requests. However in those times teh kernel artificially set stronger limits on the he buffer size, and so the overall latency could never become that large.

> 
> If you start the VU meter, that does adjust the source latency, and hence
> things work again.
> 
> As I understand it, Pulse doesn't have a frozen API yet, so things like this is
> to be expected from time to time. I wish it was slightly better at backward
> compatibility, but I don't really expect that until a post-1.0.0 release.

Hmpf. Not sure what you mean by "frozen". I actually do believe we have been pretty good with keeping compat. I must admit that I do not do regular compat testing, but I still believe we#re not that bad.

> Current git of mumble has the above change. It makes it incompatible with
> pre-0.9.11 Pulse, but I don't think any current distribution is using that old
> a version. I recommend you simply pull the relevant changeset from git, which
> is what we did for Debian/Ubuntu.  

Did you fix the races?
Comment 9 Thorvald Natvig 2009-08-31 14:55:38 EDT
> That is not true. The fragsize should be the latency. And maxlength is mostly a
> security/resource limit feature which does not (and never did) influence the
> latency.

It worked, though, and it was the advice I got when asking for help (though I don't remember who from anymore).

The fact that you can fill in '-1' for maxlength is "new". There was no mention of this in earlier documentation, and it used to be somewhat confusing exactly what was meant for the different buffer parameters. The current documentation on this is much clearer.

Unless I'm really the only one who interpreted it that way, it might be an idea to have the client library or server print a big fat warning if the application asks for a maxlength that is less than the current processing interval; data will be lost, which is almost certainly not what the application author intended :)

> > As I understand it, Pulse doesn't have a frozen API yet, so things like this is
> > to be expected from time to time. I wish it was slightly better at backward
> > compatibility, but I don't really expect that until a post-1.0.0 release.
> 
> Hmpf. Not sure what you mean by "frozen". I actually do believe we have been
> pretty good with keeping compat. I must admit that I do not do regular compat
> testing, but I still believe we#re not that bad.

The code still compiles, it just doesn't give the same results that it used to. As I said, though, I can deal with the API changes; I'd rather see continued work on improving new and existing features in Pulse than spending a lot of time on applications coded for older versions of the API.

> Did you fix the races?  

The only functions that were called outside the dedicated pulse thread were pa_mainloop_wakeup() and api->defer_enable(), which were only called when the user changed the input or output device.
While I never saw any races from this, they can technically happen, so I changed it to use the threaded api.
Comment 10 Stefano Cavallari 2009-08-31 19:14:20 EDT
I have the same problem (1 hz data bursts) with mumble (I'm on a fully updated Fedora 11, ATI Technologies Inc SBx00 Azalia (Intel HDA) )
Mumble works well when using OSS emulation (so it's not a alsa defect). I'm beginning to think it's a Pulseaudio problem instead.
Try to run
pavumeter --record
alone. It has the same problem of receiving data every ~1sec (at least here :) ).
Or maybe both pavumeter and mumble misuse the API in the same way.
Same thing when looking at pavucontrol with an application recording.

I can't try any of the "fixes" above, I'm using KDE.
I tried running arecord+mumble at the same time but nothing changes.
Comment 11 Bug Zapper 2010-04-27 10:55:42 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Bug Zapper 2010-06-28 09:00:57 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 13 Michael Wiktowy 2010-07-11 10:49:41 EDT
This bug still exists in Fedora 13 with mumble.i686 1.1.8-16.fc13 and
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
04:00.1 Audio device: ATI Technologies Inc HD48x0 audio
internal audio hardware.
I don't seem to have the ability to reassign to F13 and reopen though.
Comment 14 Michael Wiktowy 2010-11-14 23:07:28 EST
With my system with audio devices:

00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
	Subsystem: ASUSTeK Computer Inc. Device 8357
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64, Cache Line Size: 64 bytes
	Interrupt: pin ? routed to IRQ 16
	Region 0: Memory at fbcf8000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel

04:00.1 Audio device: ATI Technologies Inc HD48x0 audio
	Subsystem: ATI Technologies Inc HD48x0 audio
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 45
	Region 0: Memory at fbffc000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee0200c  Data: 4189
	Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel

Creating
/etc/modprobe.d/alsa-base.conf

with *only* the following line:

options snd-hda-intel position_fix=1 enable=yes

fixes the long standing capture issue with Skype/Audacity/etc. for me.

I have yet to test it with Mumble since the local loop back echo test doesn't seem to work for me and I don't have a test server. However, as soon as I created this file and rebooted, the VU meter in mumble and volume control came to life and the spectrum display in mumble looks much more sane.

Note You need to log in before you can comment on or make changes to this bug.