Possibly new audio issue

[bobthechemist]

I'm having problems with audio which are similar to #2 however I am using the mirroring feature, not the airplay feature.

Apple device is iPad 6th gen running iOS 13.7. RPi is a B+ running stretch. Screen mirroring works fine. Audio played during screen mirroring (tested the voice memo app, VLC, and some random youtube videos through Safari) is severely distorted (but it is playing).

A copy of the log file written while distorted sound is playing is attached. I do not know how to debug further.

log1.txt

[pallas]

Are you running in low-latency mode or sync mode? Have you given the process higher priority, e.g. nice -n -10 rpiplay ...?

[bobthechemist]

I don't notice a difference in the (poor) audio performance w/ and w/o low latency mode. Changing the niceness doesn't improve the performance either.

[matrixhaj]

Bump. Compiled RPiPlay again yesterday and I have same issue.

[FD-]

What Pi model are you using? Does rolling back to commit 576c5a66800e38afaa0f87bc3f5a9e59cea0d50b fix the issue?

[matrixhaj]

Iam noob, dont know how to undue that commit.

What I can say is that Iam using Pi 4b+, and it seems to be buggy ramdomly. If I kill the process few times and start it again, it randomly works/doesnt work(works ok/does crackling sounds/no sound)

By the way, I tried Rpiplay on my desktop with linux mint few days ago and it worked 100%. But Pi has seriously some audio issues. Dont know if its some new commit, Pi 4b+ problem or Raspbian OS.

[bobthechemist]

Rolling back to https://github.com/FD-/RPiPlay/commit/6514932aab7e2d60e9d9170a0cbe0c1eb8f19e77 changes the issue to one of poor quality sound at low volume, but the sound is no longer distorted. It looks like the issue was introduced by this commit https://github.com/FD-/RPiPlay/commit/2479ebd9fb7940c857a3d71a9f18ad532cd763e3.

[pallas]

Ooops, thanks. That free is in the wrong branch.

[pallas]

Er, I misread. The free is in the right place. Without it, the frame injection will leak. Can you please see if your audio problem persists on 2479ebd with the additional change changing if (type == 0) { to if (false) { on line 360 of renderers/video_renderer_rpi.c ?

[pallas]

And actually, I don't know why you're pointing at that commit in particular.. there are a bunch of commits between the two mentioned.

2479ebd renderers/video: do not leak h264_stream_t when injecting max_dec_frame_buffering
fa23823 renderers: reset timing on excessive delay
e9e7af9 renderers/audio: report audio delay
a26af86 renderers: do not block waiting for buffers
69f916c renderers/fdk-aac: clean up CMakeFile, only compile decoder
3545d5a cmake: replace included libplist with system library
c971cb1 lib/dnssdint: disable rotation support

[bobthechemist]

I've been "bubble sorting" trying to find which commit introduces the problem. That's how close I got before posting. I don't know if there's an easier way to sleuth the problem other than checkout, build, test, delete, repeat ad nauseum.

[pallas]

Ah, OK. Are you using git bisect or just doing it by hand? I'd suggest reverting fa23823 renderers: reset timing on excessive delay as I think that's the most likely culprit, since it intentionally fast-forwards the audio stream when it's out of sync with the video and vice versa.

[bobthechemist]

Thank you for mentioning git bisect. I was unaware of that feature. The issue was introduced in https://github.com/FD-/RPiPlay/commit/a26af869ca47c69d4aa8e5f9c8caf63803a036e3.

[FD-]

Does increasing the GPU split in raspi-config make any difference?

[pallas]

If you're out of buffers at that point in the code, switching it to blocking mode won't help since you're not going to be able to render anything anyway until a new buffer is available.

[bobthechemist]

I've been testing with a 128 split. 256 results in null pointers and a big old mess. No noticeable difference with a 64 split. Making the following change allows audio to be cast. It's reverting the change in https://github.com/FD-/RPiPlay/commit/a26af869ca47c69d4aa8e5f9c8caf63803a036e3. There is still a problem with volume, but I think that's a separate issue.

index bad51bc..d1fe489 100644
--- a/renderers/audio_renderer_rpi.c
+++ b/renderers/audio_renderer_rpi.c
@@ -328,9 +328,7 @@ static void audio_renderer_rpi_render_buffer(audio_renderer_t *renderer, raop_nt
         if (audio_delay > 100000)
             r->first_packet_time = 0;

-        OMX_BUFFERHEADERTYPE *buffer = ilclient_get_input_buffer(r->audio_renderer, 100, 0);
-        if (!buffer)
-            break;
+        OMX_BUFFERHEADERTYPE *buffer = ilclient_get_input_buffer(r->audio_renderer, 100, 1);

         int chunk_size = MIN(time_data_size - offset, buffer->nAllocLen);
         memcpy(buffer->pBuffer, p_time_data, chunk_size);

[surjikal]

@bobthechemist reverting did not work for me. I still have glitchy audio after your patch, and even after reverting fa23823.

Regarding the low volume, it's a bit silly, but double check your device audio level. My MacBook always connects with very low volume, I have to bump the volume manually after connecting.

[pallas]

My MBA does that as well.. I always have to mash the volume up button after connecting, but am not sure why yet.

[dogaoz]

I have sound glitch here too with iOS 14 and the latest RpiPlay build. Does reverting any of these older commits fix the problem?

[surjikal]

@dogaoz it didn't for me, at least not with the commits suggested in this issue. The -l flags fixes the audio but it won't be in perfect sync with the video.

[bobthechemist]

I have not tried with iOS 14. Further, I suspect my proposed solution “works” because my Raspian distro is upgraded from earlier versions (Jessie to Buster) and the RPi foundation has been moving away from ALSA during this time to exclusively PulseAudio.

Bottom line: I think this issue is very sensitive to your RPi environment, and the most recent changes to the OS (using exclusively PulseAudio) may render the original issue moot.

[FD-]

RPiPlay talks directly to the hardware on the Pi (that’s why external DACs are not supported), so ALSA vs. PulseAudio should not play a role here.

[bodenlaman]

It still happens to me on iOS 14 @bobthechemist.

[bobthechemist]

I can confirm that a fresh (as of today) image of Raspbian OS on a RPi 4 and iOS 14.2 are not working nicely with audio. Video streaming works fine. Audio works fine from the RPi (both the audio jack and an attached BT speaker) but audio playing on an iPad does not play on either the jack or BT speaker.

This is true for both the latest build and as well as the rolled back version I mentioned earlier in this thread.

At this point, I am at a loss as to how one should proceed.

[jscoba]

I have just tried making this work on the latest raspbian image (January 2021). With the rpi audio renderer it doesn't work but I have managed to install gstreamer1.0 and compile RPiPlay with the gstreamer renderer and it works perfectly with RPi 4 and iOS 14.

Just install the packages required for desktop building on the rpi and compile as usual, you have to get gstreamer working with pulseaudio. I've installed gstreamer1.0-tools and gstreamer1.0-pulseaudio and run the program with -ar gstreamer

It seems the rpi renderer is broken in the new raspbian but the gstreamer alternative for audio just works. Hope this can help you.

[hubertwang]

I have just tried making this work on the latest raspbian image (January 2021). With the rpi audio renderer it doesn't work but I have managed to install gstreamer1.0 and compile RPiPlay with the gstreamer renderer and it works perfectly with RPi 4 and iOS 14.

Just install the packages required for desktop building on the rpi and compile as usual, you have to get gstreamer working with pulseaudio. I've installed gstreamer1.0-tools and gstreamer1.0-pulseaudio and run the program with -ar gstreamer

It seems the rpi renderer is broken in the new raspbian but the gstreamer alternative for audio just works. Hope this can help you.

Hi @jscoba ,

Does it need to some extra steps to make it work? There's a error said cannot locate gstreamer audio renderer

Thank you

[hubertwang]

Ah, I found that after I turn on low latency, everything works.

[nine9797]

Hi, I installed gstreamer1.0-tools and gstreamer1.0-pulseaudio according to the instructions above, but I still get an error, what should I do?

./rpiplay -l -n AppleTV -a hdmi -ar gstreamer Error: Unable to locate audio renderer "gstreamer".

[catalinescu-sudo]

Hi, I installed gstreamer1.0-tools and gstreamer1.0-pulseaudio according to the instructions above, but I still get an error, what should I do?

./rpiplay -l -n AppleTV -a hdmi -ar gstreamer Error: Unable to locate audio renderer "gstreamer".

Hi,

any succes solving the issue with gstreamer?

[jscoba]

I had to recompile the project after installing the packages. Try running again cmake .. and make on a clean build folder.

[catalinescu-sudo]

I had to recompile the project after installing the packages. Try running again cmake .. and make on a clean build folder.

I have deleted the RPiPlay folder then I run again all the commands from the install instructions. Still gstreamer not found:(

[catalinescu-sudo]

Hi again.

I have poor knowledges in ssh / rasbian commands. I have done the following: Installing gstreamer1.0-tools and gstreamer1.0-pulseaudio with sudo apt-get install Then I followed install instructions for rpiplay git clone https://github.com/FD-/RPiPlay.git cd RPiPlay sudo apt-get install cmake sudo apt-get install libavahi-compat-libdnssd-dev sudo apt-get install libplist-dev sudo apt-get install libssl-dev mkdir build cd build cmake .. make -j sudo make install And when i try to run "rpiplay -ar gstreamer" I get the error with Unable to locate audio renderer "gstreamer".

My setup is : raspberry pi 4 with Raspberry Pi OS Lite - openmediavault 5 / docker / homeassistant etc...

What I am doing wrong?

Thank you!

[pallas]

Did you install libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev, &c.?

[catalinescu-sudo]

Did you install libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev, &c.?

Nope.

So after installing all of then and reinstall rpiplay now is working smooth.

Many thanks!