This has been a plaguing issue for the Raspberry Pi install of Raspbian (Debian Wheezy) since it was first built. Talking directly to the Raspberry Pi foundation and the Raspbian team has given me no luck.
The issue itself is that the DAC doesn't initialize until it starts playing a song. It then will turn itself off when done, causing another pop. When using this for a pure music player it is infuriating to say the least, especially when the pop is loud.
I have heard this on VLC, MOCP and MPD. This has been covered in the Pi forums, but no answers are found: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=8783
I turn to you at Stack Overflow to see if there is a way to solve this issue. My idea is to initialize it at start-up so the pop only happens when it boots up, though I don't know how to control the ALSA to do that.
Hopefully a solution can be found.
Thanks!
I've experienced the same crackling and popping noises on the Raspberry Pi's analog output when using mpd. The problem is also discussed here: https://github.com/raspberrypi/linux/issues/128
Your idea of configuring the audio hardware to be initialized only once at boot time is exactly what I did to solve the problem. It's possible to do this using the PulseAudio sound system, which works as a proxy between the audio hardware and programs that want to output sound. For example, audio players like mpd can be configured to use PulseAudio as audio backend.
PulseAudio has a configuration option (module-suspend-on-idle) that configures audio hardware sleep. Disabling audio hardware sleep fixed all crackling and popping noises for me.
I've outlined the necessary steps in closer detail on my blog: http://dbader.org/blog/crackle-free-audio-on-the-raspberry-pi-with-mpd-and-pulseaudio
I have the same problem and resolution is to use either USB audio or HDMI audio output (however converting hdmi audio to analog audio is not easy, converter >40$). It is caused by broadcom firmware. They were saying on rpi forum that it is on the list, but no one knows when it will be really fixed ...
Update: I have tried Creative Play! USB audio, it is the same, however the "click" is not that loud. So it is not 100% solution, we have to wait for the fix.
By using the Aureon Dual USB sound card I got zero popping from my raspi. Before I had popping at every song.
I have read that using the Aureon is impossible without limiting the usb ports to version 1.1, but this was not the case for me. It worked out of the box. One slight problem remains, I cannot insert the sound card when the raspi is on, it will reboot. But that's not a problem for me, I never remove the sound card.
My raspi runs raspbian wheezy and plays music via mpd and an nfs share.
Related
I try to create a simple USB audio interface with audio IN and OUT on a custom board based on an STM32F412. The audio OUT (from host to target) is working, also with the help of the CubeMX setup for the audio device usb class. But somehow I can't figure out how the opposite way (from target to host) should work.
I see for audio out, AUDIO_PeriodicTC_FS gets called periodically (every 1ms) with the AUDIO_OUT_TC command. It never gets called with AUDIO_IN_TC. I tried to call HAL_PCD_EP_Transmit with some audio data, but the host doesn't get the input...
The descriptor should be right, at least I see both interfaces (in and out) show up on the host.
Is someone experienced in this or can provide some working examples?
Look here. Used and verified. It works. It may need some deeper modification if your chip doesn't have USB OTG
Ive created a simple USB headset on my stm32f4 discovery board. You can check it out, if you're interested:
https://github.com/ancher-bohdan/stm32_usb_interface
It is far from ideal, but it can play music from host and send recorded sound from analog mic to host
everybody!
I'm trying to connect my raspberry pi 3 bluetooth to my headset. However the sound bug. It's kind of intermittently cutting off quite randomly, which makes it sound terrible.
I'm using the Raspberry 3's built-in bluetooth with Pulseaudio on Raspberry Pi OS V4.19.
How do I fix it?
This sounds like the known issue. You might want to follow some of the issues that are open around this topic:
https://github.com/Arkq/bluez-alsa/issues/60
https://github.com/raspberrypi/linux/issues/1552
https://github.com/balenalabs/balena-sound/issues/62
I have a web application that displays video. I'm running this on Raspberry Pi 4, OS Raspbian Buster.
My app plays a video with 1080p resolution on the screen using Chromium. The video works smoothly in the VLC player. When the video runs on Chromium, it tears the video.
When I examine the processor status during tearing, CPU usage goes up to %80 - %90, resulting in poor performance. I couldn't solve this problem by doing hardware acceleration in chrome settings (chrome://flags)
I've had this problem in Raspberry Pi 3 before. I solved this problem by installing a codec pack. However, in Raspberry Pi 4, this codec support seems to be incompatible. So there is no codec pack.
Is this a general problem? I've been looking for ways to solve this problem for quite a long time. Is there a method you know? I am open to any kind of support that has previously encountered such a problem or can provide information about the solution.
I look forward to your suggestions and ideas.
Thank you in advance for support.
I'm reading Linux Documentation about UVC function. I'm struggling to understand an example that starts here and goes until here. What exactly is this going to do and where exactly do I create these files?
Any help is appreciated.
From your other posts I gather that you are attempting to implement a UVC gadget with a Xilinx device. Nonetheless, as Linux devices share the same opaque kernel documentation, the procedure is just as error-prone on the Raspberry Pi Zero and other OTG-enabled devices.
What exactly is this going to do
The idea of a UVC gadget is to build something that acts like a webcam. Once completed you could potentially connect that device into a Mac or PC and use it as your video for FaceTime or Skype.
Depending on your goals you could stream synthetic images, a recorded video, or passthrough video from an add-on like a MIPI CSI camera.
where exactly do I create these files?
Here's a great intro to ConfigFS: link. Again it's for Raspberry Pi Zero rather than your Xilinx device, but the same concepts apply.
While gadget-testing.txt is inconveniently curt, if you start off by running:
modprobe libcomposite
cd /sys/kernel/config/usb_gadget/
then you can proceed with the steps mkdir functions/uvc.usb0/control/header/h ...
Here is a more detailed post covering various caveats on Raspberry Pi Stack Exchange.
I am building a Bluetooth audio receiver as an embedded system with the CHIP sbc (single board computer) from getchip.com. Pretty similar to Raspberry Pi, runs Debian Jessie, too.
I am using the onboard 3.5mm jack as an audio output. I configured PulseAudio to receive the Bluetooth audio and redirect it to the ALSA sound driver.
Everything works flawlessly except for static noise on the output.
Directly after boot there is a medium loud sum in the few hundred Hz region.
It´s always in the background, even if I play something via bluetooth or locally via CLI.
The interesting part is that it disappears after exactly 10min and 10sec after powerup, so I think exactly 10min after the startup of PulseAudio or ALSA.
I couldn´t find a reason for it.
I tried the tsched=0 fix in /etc/pulse/system.pa
I unloaded the module suspend-on-idle in /etc/pulse/system.pa
And by the way, I´m running PulseAudio in system-mode, as I´m using it as an embedded system and not a multi-user configuration. I hope I get help from you anyway ;-)
Maybe you have an idea where this noise could come from?
It has to be some sort of software configuration issue, otherwise it wouldn´t disappear after exactly 10mins.
I´ll add the PulseAudio and ALSA configuration files later this day.
Thanks in advance!
Fortunately I solved the problem on my own:
The C.H.I.P. from NextThing has a 3.5mm TRRS jack, which does not only output stereo audio but component video as well.
Now if you plug in a standard 3.5mm jack, the ground pin does does interfere with the component video connector.
Thats why there was this humming noise on the audio output. And thats why it disappeared exactly after 10mins, because the screen idle time is 10min, I think.
So I have to admit, that it was indeed not a programming question as it was a connection issue. Thanks anyway for the quick answer!