Remote Player Audio Playback

[james-s]

What would cause broken or crackling playback through a Soundblaster3 connected to USB on a RPi Falcon Pi-Cap as a remote FPP player?  When connected to the standalone FPP player, no issues that I can tell. Just when I connect it to the remote player when audio degradation occurs.  Same audio file loaded to both.

Last year, the remote Pi-Cap was my only controller and I start only with an outdoor speaker.   This year going to jump into FM transmitter and hoping to use this Pi-Cap to connect to the transmitter. Maybe not doable but that's why I am here asking. 

Player:
RPi 4B 4 GB
FPP 7.1
No Controller

Remote:
RPi 4B 2 GB
FPP 7.1
Falcon Pi-Cap

[MikeKrebs]

 IIRC, I thought there have been issues with using remotes as sound sources. It is just memory of some questions on one of these forums but I did think that was a problem. So don't quote me but it is easy to fix if that is true.

As an experiment, change the roles of the two RPis.

[breese]

Do you currently have the remote near the transmitter?
Some transmitters have been known to interfere with the soundblaster.
Separate them by 10' and it should clear things up.

[algerdes]

The reason that using a remote to feed audio isn't too trustworthy is the "catch up/slow down" of the remote to stay in sync with the master unit.  Remotes will speed up if they are behind the master or slow down if they are ahead.

In testing, we found it to be visually negligible but audio wise it was quite noticeable.

With the updates and all (since we tried it) this may or may not still be the case.

[james-s]

Do you currently have the remote near the transmitter?
Some transmitters have been known to interfere with the soundblaster.
Separate them by 10' and it should clear things up.

Not using a transmitter just yet.  Just hooking up aux to a speaker for testing.  But will keep the 10' rule in mind when doing FM transmission.   Probably going to start with one of the small fm transmission boards before investing in boxed typed.

[james-s]

The reason that using a remote to feed audio isn't too trustworthy is the "catch up/slow down" of the remote to stay in sync with the master unit.  Remotes will speed up if they are behind the master or slow down if they are ahead.

In testing, we found it to be visually negligible but audio wise it was quite noticeable.

With the updates and all (since we tried it) this may or may not still be the case.

This make sense on remotes catching up or slowing down.   Maybe will need to run sound off the main show player but I was hoping to keep it in my house.  I would try putting a transmission wire inside but the wife won't let that happen. 

[james-s]

IIRC, I thought there have been issues with using remotes as sound sources. It is just memory of some questions on one of these forums but I did think that was a problem. So don't quote me but it is easy to fix if that is true.

As an experiment, change the roles of the two RPis.

Just found time to switch the player/remote roles on the two and the sound quality is the same from the Sound Blaster 3 to speaker connection as standalone.    I am not how much memory the RPi with the bad sound but I know it is a 4 B+.   May be only 2BM.   I do know the one that doesn't have the sound issue is a RPi 4B+ has 4 MB.    Could the issue be running a Falcon Pi-Cap on the one that has the bad sound?  Maybe asking too much of the processor?

[james-s]

Update:  

• Switched out the remote player Pi with an RPi 4B with 4MB - bad audio.
• Took off the Falcon Pi-Cap (Disabled Pi-Hat in the output configuration) - bad audio.

I cannot find any configuration where audio plays cleanly on a remote.  Not sure where to go from here other than rethinking where I can put the show player running as the conductor outside where I can place an outdoor speaker and  eventually a FM transmitter.  Maybe one of the developers will see this thread and/or try the Zoom Room.

[dkulp]

You could try turning on the "Ignore Media Sync Packets" setting (advanced mode UI, audio/video tab).   It may drift slightly from master though.  Not sure if it would be noticible. 

If the remote is wifi, you could also try changing from multicast for the sync packets to unicast.   Many low end access points handle. multicast rather poorly which can cause them to come at strange times affecting the audio. 

[tetleytealeaf]

Related, but I recently created another thread related to audio off of FPP remote.   I am simply not having any sync problems and am perfectly happy with it.   

My problem is, the scheduler won't seem to set the volume on the remote.  I can manually set the volume on the remote and it seems scheduling works fine when it's on the FPP master, but scheduling on the remote is getting ignored.  So I'm having to switch back a perfectly good audio off the remote and move it back to the master.

[james-s]

You could try turning on the "Ignore Media Sync Packets" setting (advanced mode UI, audio/video tab).  It may drift slightly from master though.  Not sure if it would be noticible.

If the remote is wifi, you could also try changing from multicast for the sync packets to unicast.  Many low end access points handle. multicast rather poorly which can cause them to come at strange times affecting the audio.

@dkulp - I tried the "Ignore Media Sync Packets" and the audio did shift from the light sequencing.  

I noticed there is a setting that allows a remote +/- adjustment with the master which I take to allow for differences in potential differences for a remote versus another remote to keep them all in sync with the master.

As an enhancement, is it possible to allow a similar adjustment between audio and and the start of the sequencing playback?   Just thinking there may be scenarios like this where the audio is just not right in step with the sequencing during playback.  I can see where anything from networking, controller, FPP processor, speaker/fm transmission lag and who knows what can make a difference between what was sequenced in xLights versus what audio is heard.   This adjustment could start early or delay the playback of audio to when the pixel outputs begin by a +/- in microseconds.  Just an idea.