Open stevenpitts opened 4 years ago
Interesting. I'm very confident this is the same issue as in #30
Could you verify this by checking your pulseaudio log (e.g. journalctl -b /usr/bin/pulseaudio
) and check for a line like
W: [pulseaudio] module-loopback.c: Cannot set requested sink latency of 9223372036854742,00 ms, adjusting to 2000,00 ms
If so, then yep, you hit a pulseaudio bug, and that's why NoiseTorch marks your input device as possibly incompatible.
The interesting bit is that is seems to otherwise work fine for you, apart from the latency, while for others it doesn't seem to work.
Now, the good news is, there's a pulseaudio patch available that I think could fix your issue, the patch is here: https://github.com/lawl/NoiseTorch/issues/30#issuecomment-661193314 and I've written a bit on how to apply it here: https://github.com/lawl/NoiseTorch/issues/30#issuecomment-666756311
If you're comfortable with compiling pulseaudio from source, it would be very nice if you could test this patch so we can get this issue fixed in pulseaudio.
Just saw the mostly in mostly fine. Can you elaborate on the mostly part? It might be important to completely figure out this issue.
➜ ~ journalctl -b /usr/bin/pulseaudio | grep "sink latency"
Aug 08 20:45:12 makudesktop pulseaudio[3653]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 20:47:28 makudesktop pulseaudio[125653]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 20:47:29 makudesktop pulseaudio[125653]: Cannot set requested sink latency of 19.50 ms, adjusting to 99.95 ms
Aug 08 20:47:37 makudesktop pulseaudio[125653]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 20:48:58 makudesktop pulseaudio[129670]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 20:49:48 makudesktop pulseaudio[129670]: Cannot set requested sink latency of 55.85 ms, adjusting to 99.95 ms
Aug 08 20:49:59 makudesktop pulseaudio[129670]: Cannot set requested sink latency of 2.25 ms, adjusting to 2.50 ms
Aug 08 20:50:01 makudesktop pulseaudio[129670]: Cannot set requested sink latency of 55.85 ms, adjusting to 99.95 ms
Aug 08 20:52:14 makudesktop pulseaudio[139664]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 20:55:00 makudesktop pulseaudio[139664]: Cannot set requested sink latency of 19.50 ms, adjusting to 99.95 ms
Aug 08 20:55:54 makudesktop pulseaudio[139664]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 20:56:06 makudesktop pulseaudio[139664]: Cannot set requested sink latency of 19.50 ms, adjusting to 99.95 ms
Aug 08 20:56:13 makudesktop pulseaudio[139664]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 20:57:57 makudesktop pulseaudio[139664]: Cannot set requested sink latency of 19.50 ms, adjusting to 99.95 ms
Aug 08 20:58:45 makudesktop pulseaudio[139664]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 21:00:57 makudesktop pulseaudio[139664]: Cannot set requested sink latency of 19.50 ms, adjusting to 99.95 ms
Aug 08 21:01:04 makudesktop pulseaudio[139664]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 21:10:05 makudesktop pulseaudio[196477]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 21:11:31 makudesktop pulseaudio[196477]: Cannot set requested sink latency of 19.50 ms, adjusting to 99.95 ms
Aug 08 21:11:37 makudesktop pulseaudio[196477]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 21:19:05 makudesktop pulseaudio[196477]: Cannot set requested sink latency of 19.50 ms, adjusting to 99.95 ms
Aug 08 21:19:49 makudesktop pulseaudio[196477]: Cannot set requested sink latency of 9223372036854742.00 ms, adjusting to 2000.00 ms
Aug 08 21:22:49 makudesktop pulseaudio[196477]: Cannot set requested sink latency of 19.50 ms, adjusting to 99.95 ms
Looks like you're right!
I'm not used to compiling from source, but I'll give it a try and let you know if it works!
As for the "mostly", it's because setting a voice activation threshold above 0 doesn't work great (my voice cuts out a lot), which is weird because my mic is a REALLY high end mic.
As for the "mostly", it's because setting a voice activation threshold above 0 doesn't work great (my voice cuts out a lot), which is weird because my mic is a REALLY high end mic.
Yeah, people that hit this PA bug report strange issues on the other thread too, and I've not heard that with devices that I don't flag orange. Possibly also a result of that bug, or another bug.
A Blue Yeti should certainly be more than good enough, I think, I don't have one. But my tests for "decent microphone" were basically not a crappy built in laptop microphone, still nothing super high end. Just not a terrible SNR and acceptable voice quality so the neural net realizes it's voice. Any crappy headset mic should be good enough to crank up the slider to 80+ easily and at like 50% anything should work.
After a long while of troubleshooting, I've finally got to the last line in the "HACKING" instructions, but I'm getting an error which seems to not matter?
➜ pulseaudio git:(master) ✗ ./src/pulseaudio -n -F src/default.pa -p $(pwd)/src/
N: [pulseaudio] daemon-conf.c: Detected that we are run from the build tree, fixing search path.
E: [pulseaudio] stdin-util.c: Unable to read or parse data from client.
E: [pulseaudio] module.c: Failed to load module "module-gsettings" (argument: ""): initialization failed.
However, sound seems to work normally with that command running. (And yeah, I uninstalled apt's pulseaudio before doing all this stuff).
My mic is no longer detected as incompatible in NoiseTorch, and the issue is resolved!!!!!
I've had multiple people tell me that my voice sounds a tad robotic, but maybe that's just something everyone has to live with when using this?
Anyway, feel free to close this issue if you want, since it's PulseAudio's problem ^_^
Oh, one more note - a lot of the time, my words get cut off at the end (or sometimes beginning or middle) If I say "testing", only "testin" plays back, and sometimes only "tes" plays back. And that's at 0% voice activation threshold. Hmm
Hmm. Okay, now it's always really bad with cutting parts out, no matter what voice activation threshold it's at. And yet as I type that, now it's perfect. Is it learning, or something?
Maybe this is completely unrelated to this issue; I guess we should wait for the PulseAudio fix and see what happens then?
Okay this is even weirder, but maybe it has to do with me not understand what I did with the "HACKING" instructions?
After deleting the directory where I cloned PulseAudio and the patch and everything, and reinstalled PulseAudio via Apt, the fix is still applied. After restarts and everything. And if I apt purge PulseAudio, all audio is broken, which makes me think I'm not still running the fixed version somewhere hidden.
...???
After deleting the directory where I cloned PulseAudio and the patch and everything, and reinstalled PulseAudio via Apt, the fix is still applied. After restarts and everything. And if I apt purge PulseAudio, all audio is broken, which makes me think I'm not still running the fixed version somewhere hidden.
You probably were, but the issue is this
My mic is no longer detected as incompatible in NoiseTorch, and the issue is resolved!!!!!
Your device should still be detected as incompatible.
I believe what happened here is that your device wasn't incompatible, but your configuration forced all devices into this mode. When you apt purge
the old package, you reverted to the default config. My guess here is that one way the config sais
load-module module-udev-detect
and the other one it sais
load-module module-udev-detect tsched=0
in /etc/pulse/default.pa
tsched=0
forces all devices into "incompatible?" mode with NoiseTorch, but may be required to work around some other bugs in certain soundcards, as far as i understand.
Oh, you're entirely correct, that was the case! Oops.
I have the same problem. Downgrading to 0.5.1-beta fixed it for me (issue appeared after updating); @lawl, your fix might have broken it for users that weren't experiencing #30.
@AtilioA There is no fix for #30. I simply flag devices in the UI, no actual functionality is changed at all. Devices I think are affected are simply made orange.
Also I was just able to reproduce distorted sound by forcing my devices into this incompatible mode, then rebuilt the exact same pulseaudio commit later, and now can't reproduce it anymore.
It's some kind of Heisenbug and I believe 0.5.1 fixing it for you is a coincidence. There should be nothing in any of the commits that can affect this.
@lawl having messed a bit with it in the past weeks, it really is a weird bug. Most of the time I can make it work by setting the actual microphone as fallback in PulseAudio (if NoiseTorch output is silent) and by restarting it with systemctl --user restart pulseaudio.service
(if there is still any delay or no sound). This was on 0.7.0
.
Copying from #30:
Can anyone affected by these try the following?
Append
resample-method = trivial
to ~/.config/pulse/daemon.conf
(or create it if it doesn't exist). Then restart pulseaudio with pulseaudio -k
. Verify it was set correctly:
$ pulseaudio --dump-conf | grep resample
resample-method = trivial
And see if that changes anything when you use NoiseTorch with that pulseaudio setting?
Unfortunately I still cannot reproduce the issue. I could for a short while, and now I can't again :(
Hi there, I'm having a similar issue to this one. NoiseTorch worked fine for me in the first couple of releases, but somewhere along the line I reconfigured pulse so that my output devices would have significantly lower latency using these steps. So, it seems very possible that this change resulted in NoiseTorch no longer working properly for me.
Initially, starting NoiseTorch became much slower, and the audio from the virtual device created by NoiseTorch would be delayed by about 5 seconds. After one of the more recent updates, I can't use it at all anymore -- my microphone shows up as (incompatible?)
and a second or two after selecting it and clicking load, the GUI says "Connecting to pulseaudio..."
I've tried the resample-method
change as you suggested, but unfortunately it doesn't seem to have resolved the issue.
Same issue, 5 seconds latency, and device shows as incompatible. Fresh install
Same issue, massive distortion, only occurring on headset microphone plugged in via microphone port, flagged as incompatible?
, I have a separate USB one without the issue. Haven't been able to try any of the patches/config changes.
I realized that I have 2 seconds of latency on amd cpus (ryzen 1700, ryzen 3500u), but close to zero delay on intel based systems, even low end ones.
I realized that I have 2 seconds of latency on amd cpus (ryzen 1700, ryzen 3500u), but close to zero delay on intel based systems, even low end ones.
Mine was on an Intel system, but that's interesting
@cnmoro And the rest of the hardware/OS is identical? I have a hard time thinking of something where the CPU model could cause this.
@cnmoro And the rest of the hardware/OS is identical? I have a hard time thinking of something where the CPU model could cause this.
For the ryzen 1700 yes, the only things that changed were the motherboard and cpu. Same linux installation and ram. Yea it is weird. maybe something in the cpu architecture, who knows.
I indeed have a Ryzen CPU (a 3600X), but I can use NoiseTorch by following these steps.
Anyone willing to give this build a shot? I was developing some top secret new noisetorch stuff and came across an issue similar to this. So now I'm wondering if the fix ends up being the same.
Edit: or can anyone else confirm that setting noisetorch as a faolback in pavucontrol fixes things?
I tried out this build, still have ~5 seconds of latency. Should I try some particular PA config?
Edit: Setting the NoiseTorch input as fallback/default in pavucontrol
seems to fix the latency...
@aemino interesting, that's multiple people now reporting setting it as default/fallback to fix the issue.
Could you give me the following:
Output of:
pulseaudio --dump-conf | grep avoid
and the noisetorch log? Should be in /tmp/noisetorch_<timestamp>.log
avoid-resampling = no
that's multiple people now reporting setting it as default/fallback to fix the issue.
How does one do that?
In pavucontrol: I presume this is what they're talking about?
I presume this is what they're talking about?
Yes, this solves it, at least for me.
EDIT: the new build is working fine for me (even though my device is marked as incompatible), but I'll need to test it more.
This started happening to me after disabling timer-based scheduling, to improve audio quality on my setup.
My devices in NoiseTorch turned orange, got marked as (incompatible?) and I experience said delay.
With NoiseTorch disabled, or after removing tsched=0
again, everything works tho.
The fallback option did not fix this for me. I also did not test the different builds you linked here, I could give them a shot, but I'm unsure if that'll help. Perhaps this post still helps figuring out what causes the issue in the first place.
@NotSnowyy
Thanks. There's actually some progress on this. See #77 It seems to be a combination of the latency bug for which there's now a patch in upstream git and the second issue is that pulse doesn't adjust the latency fast enough.
Both may be work aroundable by chainloading another module in front.
Hello,
I'm experiencing this bug, with ~2s of latency only when using noisetorch (normal latency is <100ms).
I do have this Cannot set requested sink latency of 9223372036854742,00 ms, adjusting to 2000,00 ms
log message. It's an "incompatible device"
Full log:
Failed to load module "module-alsa-card" (argument: "device_id="0" name="pci-0000_09_00.1" card_name="alsa_card.pci-0000_09_00.1" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1""): initialization failed. ALSA woke us up to write new data to the device, but there was actually nothing to write. Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Configured latency of 1,00 ms is smaller than minimum latency, using minimum instead Cannot set requested sink latency of 9223372036854742,00 ms, adjusting to 2000,00 ms Cannot set requested source latency of 14,62 ms, adjusting to 100,14 ms No remapping configured, proceeding nonetheless! ALSA woke us up to read new data from the device, but there was actually nothing to read. Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. We were woken up with POLLIN set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Assertion 'PA_SINK_IS_LINKED(s->state)' failed at pulsecore/sink.c:924, function pa_sink_suspend(). Aborting. Stale PID file, overwriting. module-combine is deprecated: Please use module-combine-sink instead of module-combine! We will now load module-combine-sink. Please make sure to remove module-combine from your configuration.
(and then it repeats itself)
I'm using v.0.10.
Is this comment still valid ? https://github.com/lawl/NoiseTorch/issues/30#issuecomment-720840457
How can we help ?
The current state is that we made some progress on this here: https://github.com/lawl/NoiseTorch/issues/77
And this seems to be two issues at play here that both need to be fixed. At least one of those requires people to be comfortable building pulseaudio from source.
There is also a work around mentioned there that may or may not work for you that does not require building from source.
Thank you for your answer.
At least one of those requires people to be comfortable building pulseaudio from source.
Any chance this get fixed upstream at some point ?
There is also a work around mentioned there that may or may not work for you that does not require building from source.
I guess that's this workaround ? https://github.com/lawl/NoiseTorch/issues/77#issuecomment-766915589
Both of these questions are answered there.
There is a fix available for this now, but it requires building both PulseAudio and NoiseTorch from source. PulseAudio requires this patch which has been merged upstream a month ago to trickle down into distributions.
Additionally: We have another fix on our side which has been committed and will be is part of the next current NoiseTorch release.
Unless you are willing to build PulseAudio from source, there is currently nothing you can do, but wait.
Great, then it will be fixed, that's good :) Thank you for explaining that.
Hello, i had the latency issue which i fixed through the pulseaudio change, but now my voice sounds robotic through noisetorch? there are no more errors in pulse logs from what i see, but it is still strange
Nevermind, i can confirm the new commit fixes it!
When listening to my playback, it appears that there are two seconds of latency between speaking and hearing myself. My device is labeled (incompatible?), but it seems to work mostly fine aside from the 2 seconds latency. Ubuntu 20.04, Yeti microphone