FD-
Garbled Audio Using Synced Mode
Hi, thanks for all the work on this project - I got it up and running yesterday and it's really exiting to be able to use my Pi to cast seamlessly to my TV!
I'm seeing an issue though, where unless I use low-latency mode (-l flag), the audio is garbled and choppy.
I saw that this was discussed in #128, but the suggestion there is to use low-latency mode. This only works up to a point: it's not pleasant to watch films or TV in that mode since the audio is not synced to the video.
Rather than re-opening that issue, I'm hoping to raise this as a new feature request to fix the synced mode.
I'm running on a Pi 4B 2G.
I'm running a Pi3B+ and I see synced audio with no drops.
- Are you running rpiplay at high priority, e.g.
nice -n -15 rpiplay ... - Do you have GPU memory set high, e.g. 128MB or 256MB?
- Did you compile rpiplay as Release or as Debug, or something else? (one of the recent commits defaults it to Release, but you have to erase CMakeCache.txt and rebuild from scratch)
- What audio subsystem are you using?
Re: subsystems, it has been a (really) long time since I set this up, but in the shipped setup I'd often get garbled audio. It looks like I'm using alsa-oss with the BCM2835 driver, if aplay -l is telling the truth: card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]. Does lsmod | grep snd_bcm2835 show that this module is loaded? Prior to launching, my xinit script does modprobe snd_bcm2835 and then attempts to play a test sound aplay /usr/share/sounds/alsa/Noise.wav to make sure the audio is activated.
The other thing about my setup is that I'm dynamically loading @jemalloc via env LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libjemalloc.so.2 ...
And to be clear about the audio stuff: I could be totally wrong here.. I have no idea how I set it up now, I just remember it being bad and moving to something based on some guide and the status quo works. My gut says that 80% of the audio quality problems reported to rpiplay are actually platform problems, but YMMV.
I'm also running pianobar under aoss, and I SIGSTOP it when rpiplay gets a connection. I don't know if that makes a difference.
Unless I missed something, RPiPlay should still talk to the audio hardware directly via OpenMAX, without involvement of ALSA and the like (that is, if you’re using the default OMX audio renderer on Pi, which you should).
Yes, but I'm worried that the bcm2835 driver (or other system configuration) pokes the hardware in some way that affects omx.