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.
I can confirm this problem, I've managed to "fix" it by keeping GNOME's Sound Preferences window open while using Mumble.
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.
I've assigned this bug to pulseaudio in hopes that some pulseaudio developer could comment on the issue.
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.
Just for the record, this is also seen on mandriva 2009.1.
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)
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.
(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?
> 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.
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.
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
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.
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.
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.