Ticket #374 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

Recording from PulseAudio produces noise and very low quality sound

Reported by: turl Owned by: lennart
Milestone: Component: module-alsa-*
Keywords: Cc: msettenvini@…

Description

When you record audio using a native pulse application (GNOME Sound Recorder, for example), the sound you get is crappy and unusable. Using raw alsa output (no pulseaudio) works fine, also, if you use pulse's OSS emulation, the sound is OK.

I think this is not a hardware problem, as I can also reproduce this using virtual inputs (Captures)

libpulsecore5: 0.9.12-0ubuntu1~ppa1 libpulse0: 0.9.12-0ubuntu1~ppa5 pulseaudio: 0.9.12-0ubuntu1~ppa5

If you need more information, do not hesiate to ask for it. I attach a sound sample for you to listen to it and see what the problem might be.

Attachments

recordedsound.oga (17.2 kB) - added by turl 3 years ago.
Recorded Sound Sample

Change History

Changed 3 years ago by turl

Recorded Sound Sample

in reply to: ↑ description   Changed 3 years ago by kalaleq

I'm having the same problem. I had a hell of a time upgrading from 0.9.10 to 0.9.11/0.9.12, but finally got 0.9.12 (more or less) working. However, recording a sound from the gnome sound recorder app gives me the same result. It sounds like only random snatches of the sound are actually being recorded, with cut-outs between them (not silence - the snatches of sound are contiguous with no audible gaps between them). The app's counter of how many seconds of sound have been recorded also increments much more slowly than once per second.

My sound card is, per lspci -v:

00:14.2 Audio device: ATI Technologies Inc SB600 Azalia

Subsystem: ASUSTeK Computer Inc. Device 8230 Flags: bus master, slow devsel, latency 64, IRQ 16 Memory at fbcf4000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel

  Changed 3 years ago by dtatukea

This happened to me while using the following config: F10 with virtualbox. PA version is 0.9.13 (F9 uses 0.9.10) The emulated card is an ICH AC97. My real card is Intel 82801H (ICH8 family). It happens only when recording in Virtualbox. Recording sound normally works.

  Changed 3 years ago by jeckhart

I get similar results on pulseaudio-0.9.14 on a gentoo amd64 system. Using pulse as an audio source (i.e. recording from pulse) produces a similar result whether I record for mumble, gnome sound recorder, etc.

If I use the raw alsa source, it works fine (albeit a little quirky because it tends to lock the ALSA source and then pulse, wine, etc. start to act up). A suggested workaround that enabled pulse would be ideal, so I could push everything through pulse instead.

Thanks!!

  Changed 3 years ago by tchernobog

  • cc msettenvini@… added

The same here on Ubuntu Jaunty. Especially Ekiga and gnome-sound-recorder are completely unusable (I'd like to ditch Skype, thanks)!

However, I can record something using directly:

gst-launch pulsesrc ! vorbisenc ! oggmux ! filesink location="me.oga"

It's passably clear (low quality microphone, anyway). The strange thing is, sometimes it does record me correctly, sometimes (especially if it's the first time you run this command) it gives me a lot of errors like:

WARNING: from element /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0: Can't record audio at an adequate rate Additional debug info: gstbaseaudiosrc.c(805): gst_base_audio_src_create (): /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0: dropped 2205 samples

After 8-10 minutes of recording it hangs, though.

00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 01)

Subsystem: IBM Device [1014:0542] Control: I/O+ Mem+ BusMaster?+ SpecCycle?- MemWINV- VGASnoop- ParErr?- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr?- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin B routed to IRQ 11 Region 0: I/O ports at 1c00 [size=256] Region 1: I/O ports at 18c0 [size=64] Region 2: Memory at d0100c00 (32-bit, non-prefetchable) [size=512] Region 3: Memory at d0100800 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2

Flags: PMEClk- DSI- D1- D2- AuxCurrent?=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Kernel driver in use: Intel ICH Kernel modules: snd-intel8x0

  Changed 3 years ago by jeckhart

  • priority changed from high to highest

Actually, after some experimentation, I stumbled upon a silly but effective workaround. If I have the PulseAudio volume control open, my recording works fine, as soon as I close the volume control, the audio gets choppy and unusable again. Hopefully this helps point to the real problem.

  Changed 3 years ago by coling

  • priority changed from highest to normal
  • severity changed from critical to normal

This kind of behaviour has been mentioned before. Very odd, but probably with a perfectly sensible reason. Sadly I'm not in a position to look into it myself but hopefully lennart will be able to have some insight and a quick fix!

Resetting Severity and Priority to normal as there doesn't appear to be any reason why this issue is more important or severe than any other one! (no kittens are killed etc. etc.)

  Changed 2 years ago by lennart

  • status changed from new to closed
  • resolution set to fixed
  • component changed from daemon to module-alsa-*

We have recently made some changes to the pa plugin for gst and the timing code in PA, so i am pretty confident that with the recent code most probs should be gone. If you can reproduce with 0.9.16 and a very recent gst version, feel free to reopen.

Note: See TracTickets for help on using tickets.