I get a frequent very, very, very loud hiss from mythfrontend when any of the following occur: 1. fast-forward 2. rewind 3. commercial skip I can fix it but pressing fast-forward or rewind, sometimes 2 or 3 times, but the next time there's a commercial skip, the hiss will be back. This is a recent phenomenon (started happening about 2 weeks ago) that I cannot correlate with an exact upgrade. Version-Release number of selected component (if applicable): 0.9.22-5.fc15 How reproducible: intermittent but often Steps to Reproduce: 1. Play back a recording with mythfrontend 2. Press the right or left arrow Actual results: After a commercial skip or after the first or second or third press, a very loud hiss will replace the audio that should accompany the recording. In the debug output attached, the "Pool Full" and "events suppressed" messages only roughly correlate in time to the noise. There doesn't seem to be an exact message from the output of pulseaudio -vvv that can be correlated exactly to the noise.
Created attachment 52871 [details] pulseaudio -vvv This is the output of PULSE_NO_SIMD=1 pulseaudio -vvv as I reproduce the hiss. My stereo is set to -38dB but the hiss sounds much louder than than the sound of the recording when it comes through clearly.
How is the stereo amplifier connected? From the log it looks like a USB headset. There's no resampling or channel remap going on, so the main candidates are sample conversion (float->s16le) and software volume adjustment. There was a bug in the volume code, but you shouldn't hit that with PULSE_NO_SIMD=1 set. Can you verify that the problem also occurs with pulseaudio 1.1 or git master? The other thing to try would be to have both sink-input and sink volumes at 100%, so no software volume adjustments are done.
The machine that does this is in my living room. I cannot reboot it will nor install too much stuff on it, the Wife Acceptance Factor goes way down when the machine is unavailable. I don't dare install things that are in -testing or -experimental. I worked around this by choosing an ALSA sound device in my mythtv frontend settings. Nothing else I've tried works. The volume is always set to 100% because the sound goes to my stereo that controls the volume. I didn't try changing the volume with paman by hand. With this workaround in place, I'm reluctant to try changing sound settings now. The on-board sound didn't work for me when I assembled this machine so I'm using a USB dongle which has worked flawlessly so far. Since this bug received _no_ attention on bugzilla.redhat.com and none here until you posted, I'd given up hope that anyone even cared. I'm glad you posted, but I still feel pessimistic that this will get any attention. In case you care, have a look at all the NEW bugs on fedora's bugzilla for just pulseaudio: https://bugzilla.redhat.com/buglist.cgi?product=Fedora&bug_status=__open__&component=pulseaudio A mythtv machine isn't that hard to set up. I would enthusiastically help you get one running if you were willing to go to the trouble of installing fedora 16 and mythtv.
I've have this issue as well. I'm using the hdmi port on an nvidia card with the snd-hda-intel driver. I've changed Pulseaudio's default sample rate to 48000hz, and it seems to have helped, but it's still too early to discern whether the problem is cured for good. Output from lspci: 01:00.1 Audio device: nVidia Corporation GF108 High Definition Audio Controller (rev a1)
(In reply to comment #4) > I've have this issue as well. I'm using the hdmi port on an nvidia card with > the snd-hda-intel driver. I've changed Pulseaudio's default sample rate to > 48000hz, and it seems to have helped, but it's still too early to discern > whether the problem is cured for good. The sound played fine (that is it didn't sound skewed), but with a hiss, and this was fixed by setting default-sample-rate to 48000?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/458.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.